PDA

View Full Version : sles 11 firewall and vMA 5.0



jmcg
26-Feb-2013, 21:35
I have installed VMware's vMA 5.0 on one of my esxi servers. I was hoping to use it to run a script and shutdown the host when it is running on battery and the battery reaches a certain level. I have a tripplite smnp card in the ups and the documentation I have from tripplite is for vMA version 4.0. According to VMware vima (as vMA is called) 4.0 was built on a RedHat kernel. The Version 5.0 that I have is built on a sles 11 kernel. I know the script will run on the vima manually, but it doesn't get the message from the card. From packet traces I can see the packet sent by the card (an snmp trap to port 160) but the script never runs. Also, the snmp card is supppose to register with server but never does. From all indications it seems that the vima 5.0 has a firewall on it that is blocking packets. However, when I investigate the vima, I see that SUSEfirewall2 is not installed (I launch yast>Securityand Users> firewall) so this seems to imply that there is no firewall on it. Yet the packets don't get to the server or from the server.

Does anyone have a clue on what I need to do to get this working? Is there another type of firewall on the vima 5.0?

jmozdzen
27-Feb-2013, 18:42
Hi jmcg,

> However, when I investigate the vima, I see that SUSEfirewall2

better check via "iptables -L -vn" to list all active firewall rules - SUSEfirewall2 is just a script to manage those rules, other scripts might be in effect doing this.

I have no experience with vima whatsoever, so pardon my questions: Seems you need some SNMP manager active on the machine, listening for SNMP traps. While SLES has it's own daemon for this, I don't know if vima brings its own service - but you might want to check the list of open ports via "lsof -i -P" and see if you have any program listening on 160/UDP. BTW, the standard port for SNMP traps would be 162/UDP - if the 160 is no typo, then either the sending side (UPS) is misconfigured or expecting a non-standard(-SNMP) receiver on the server side.

Once you know who is (or should be) listening for the UPS' notifications (or if the tripplite card is sending to the wrong port), you can go on from there to check why your script isn't run.

Regards,
Jens

jmcg
27-Feb-2013, 21:41
Jens,
first I did type 160 by mistake it is 161 is the port that the card should be written to by the service pasdad. Here is an output for sudo lsof -i -P

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
portmap 2400 bin 4u IPv4 5412 0t0 UDP *:111
portmap 2400 bin 5u IPv4 5413 0t0 TCP *:111 (LISTEN)
vami-ligh 2420 root 3u IPv6 5486 0t0 TCP *:5480 (LISTEN)
vami-sfcb 2442 root 135u IPv6 5655 0t0 TCP *:5489 (LISTEN)
vami-sfcb 2443 root 135u IPv6 5654 0t0 TCP *:5488 (LISTEN)
pasdad 2772 root 5u IPv4 7314 0t0 UDP *:3664
pasdad 2772 root 6u IPv4 7336 0t0 UDP *:55917
pasdad 2772 root 8u IPv4 7341 0t0 TCP *:705 (LISTEN)
pasdad 2772 root 9u IPv4 7337 0t0 UDP *:162
pasdad 2772 root 10u IPv4 8733 0t0 UDP *:38542
sendmail 2904 root 3u IPv4 7900 0t0 TCP localhost.localdom:25 (LISTEN)
sshd 2924 root 3u IPv4 7968 0t0 TCP *:22 (LISTEN)
sshd 2924 root 4u IPv6 7970 0t0 TCP *:22 (LISTEN)
sshd 6742 root 3r IPv4 1400431 0t0 TCP ehs226.sisnet.ssku.k12.ca.us:22->ehs11.sisnet.ssku.k12.ca.us:49698 (ESTABLISHED)
sshd 6744 vi-admin 3u IPv4 1400431 0t0 TCP ehs226.sisnet.ssku.k12.ca.us:22->ehs11.sisnet.ssku.k12.ca.us:49698 (ESTABLISHED)

Out put for the iptables is -L -vn is

vi-admin@localhost:~> sudo iptables -L -vn
vi-admin's password:
Chain INPUT (policy ACCEPT 211K packets, 24M bytes)
pkts bytes target prot opt in out source destination
54 3826 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:161 state NEW

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 16299 packets, 2078K bytes)
pkts bytes target prot opt in out source destination
vi-admin@localhost:~>

Here is the output for trying to turn off the firewall entirely.

vi-admin@localhost:~> sudo chkconfig iptables off
iptables: unknown service
vi-admin@localhost:~>


Also, I was mistaken that in that the service that is running on the srvr (pasdad) should write to the snmp webcard, this is is not happening. I was able to manual write to the card via gui. But clearly communication between service on the srvr and the snmp card is not occurring.

jmcg
27-Feb-2013, 21:55
Should I see iptables listed when I enter chkconfig --list at the terminal?

jmozdzen
27-Feb-2013, 22:03
Hi jmcg,


Jens,
first I did type 160 by mistake it is 161 is the port that the card should be written to by the service pasdad. Here is an output for sudo lsof -i -P

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
portmap 2400 bin 4u IPv4 5412 0t0 UDP *:111
portmap 2400 bin 5u IPv4 5413 0t0 TCP *:111 (LISTEN)
vami-ligh 2420 root 3u IPv6 5486 0t0 TCP *:5480 (LISTEN)
vami-sfcb 2442 root 135u IPv6 5655 0t0 TCP *:5489 (LISTEN)
vami-sfcb 2443 root 135u IPv6 5654 0t0 TCP *:5488 (LISTEN)
pasdad 2772 root 5u IPv4 7314 0t0 UDP *:3664
pasdad 2772 root 6u IPv4 7336 0t0 UDP *:55917
pasdad 2772 root 8u IPv4 7341 0t0 TCP *:705 (LISTEN)
pasdad 2772 root 9u IPv4 7337 0t0 UDP *:162
...which shows that pasdad is actually listening on 162, not 161.


pasdad 2772 root 10u IPv4 8733 0t0 UDP *:38542
[...]
Out put for the iptables is -L -vn is

vi-admin@localhost:~> sudo iptables -L -vn
vi-admin's password:
Chain INPUT (policy ACCEPT 211K packets, 24M bytes)
pkts bytes target prot opt in out source destination
54 3826 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:161 state NEW
which looks like an extra, unneeded entry (your only entry in the list is stating to accept specific packets in a chain that is per default accepting all packets). But it doesn't do any harm, either.


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 16299 packets, 2078K bytes)
pkts bytes target prot opt in out source destination
vi-admin@localhost:~>

Here is the output for trying to turn off the firewall entirely.

vi-admin@localhost:~> sudo chkconfig iptables off
iptables: unknown service
vi-admin@localhost:~>
Yes, "iptables" is the command line tool (not service) to control packet filtering in the kernel. You cannot disable it, nor would you need to.

If the SNMP traps coming from the management card are actually sent to port 161, then I'm not surprised no-one is reacting to them - there's no-one listening for them. Have them sent to port 162.

Regards,
Jens

jmcg
27-Feb-2013, 23:08
it is being sent to port 162, that was another one of my mistakes in understanding this issue. The following is the syntax Tripplite has used and says works but i can't get it to. When i even attempt any of the commands I get unknown service.

vi-admin@localhost:~> sudo chkconfig iptables off
vi-admin's password:
iptables: unknown service
vi-admin@localhost:~> sudo service iptables save
service: no such service iptables
vi-admin@localhost:~> sudo service iptables stop
service: no such service iptables
vi-admin@localhost:~>



On VIMA, if you would prefer to disable the firewall:
[vi-admin@vima ~]$ sudo chkconfig iptables off
[vi-admin@vima ~]$ sudo service iptables save
[vi-admin@vima ~]$ sudo service iptables stop

Otherwise open the specific ports: 161, 162, 3664 and 3665.

[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 161 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 162 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 3664 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 3665 –m state -–state NEW –j ACCEPT
Finally, save the firewall configuration.
[vi-admin@vima ~]$ sudo /etc/init.d/iptables save

jmozdzen
27-Feb-2013, 23:54
it is being sent to port 162, that was another one of my mistakes in understanding this issue. The following is the syntax Tripplite has used and says works but i can't get it to. When i even attempt any of the commands I get unknown service.

vi-admin@localhost:~> sudo chkconfig iptables off
vi-admin's password:
iptables: unknown service
vi-admin@localhost:~> sudo service iptables save
service: no such service iptables
vi-admin@localhost:~> sudo service iptables stop
service: no such service iptables
vi-admin@localhost:~>



On VIMA, if you would prefer to disable the firewall:
[vi-admin@vima ~]$ sudo chkconfig iptables off
[vi-admin@vima ~]$ sudo service iptables save
[vi-admin@vima ~]$ sudo service iptables stop

Otherwise open the specific ports: 161, 162, 3664 and 3665.

[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 161 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 162 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 3664 –m state -–state NEW –j ACCEPT
[vi-admin@vima ~]$ sudo iptables –I INPUT –p UDP -–dport 3665 –m state -–state NEW –j ACCEPT
Finally, save the firewall configuration.
[vi-admin@vima ~]$ sudo /etc/init.d/iptables save

So according to that information, there ought to be a file /etc/init.d/iptables - which, supposedly, is in charge for such a service to init firewall rules... if it's not there, then the *information* may be specific for the former version, which was based on a different distro (as you wrote initially).

"opening the firewall" manually can be done by calling "iptables -F", which should flush all entries in the rule chains and get you to

vima:~ # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
"policy ACCEPT" means that if there are no rules in a chain, then all packets are accepted (it's actually "when a packet has passed all rules of a chain without being explicitly accepted or rejected", but as there are no rules...).

Does your network trace now show the packets coming in on port 162? If so, your next step would be to somehow debug what's happening inside that daemon ("pasdad").

I did some digging on the internet and found this: https://github.com/jim-brannon-lrcwe/tripplite-pasdad/blob/a33e1a95abf988ad919e5ff28fa99c30a54ef76b/paconfig.ini which implies that pasdad was at that time actually *polling* the remote device. Do you see a similar config file somewhere? The open port 162 indicates that your pasdad is actually listening for snmp traps. Had you added your script in that config file or is there any hint that this might be required? Does pasdad generate any logging?

Maybe it is easier to actually make pasdad poll the device, which would be over snmp (port 161 on the management card).

Regards,
Jens