IP Tables Saga...:(

[scottwilkerson]

thanks XenoPhage

[arnab.roy]

Hi all,

After putting the log in

I get the following

Code: Select all

Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=27081 PROTO=UDP SPT=161 DPT=44658 LEN=103
Sep 13 13:56:28 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=18709 PROTO=UDP SPT=161 DPT=44658 LEN=103
Sep 13 13:56:29 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=703 PROTO=UDP SPT=161 DPT=44658 LEN=103
Sep 13 13:56:30 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=53106 PROTO=UDP SPT=161 DPT=44658 LEN=103
Sep 13 13:56:31 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=29844 PROTO=UDP SPT=161 DPT=44658 LEN=103
Sep 13 13:56:32 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=22993 PROTO=UDP SPT=161 DPT=44658 LEN=103

[CGraham]

Do you have any other types of connectivity across the router?

In other words, from the location that snmpwalk fails, try:

telnet [nagiosip] 80

Additionally, the Source IP in the logs is the .1 address. Are you testing directly from the router/firewall/gateway, or is it NAT'ing the ip?

[XenoPhage]

Code: Select all

Sep 13 13:56:28 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=18709 PROTO=UDP SPT=161 DPT=44658 LEN=103

You state in your initial post that you're sending snmp queries *from* somewhere else *to* this server, correct? Your input chain specifically states that you're allowing traffic destined for port 161 (SNMP) and the log entry above from the firewall clearly shows that the SOURCE port is 161. So iptables is blocking properly.

Let's try this. Two devices, A and B. A is the Nagios XI server, B is some other device. Are you attempting to query SNMP on the B device, or is B trying to send an SNMP query to A?

[arnab.roy]

Code: Select all

Sep 13 13:56:28 karma-rbht kernel: Firewall:IN=eth1 OUT= MAC=00:0c:29:92:8c:16:00:d0:95:8a:6e:6f:08:00 SRC=192.168.171.1                                                                              DST=192.168.11.254 LEN=123 TOS=0x00 PREC=0x00 TTL=62 ID=18709 PROTO=UDP SPT=161 DPT=44658 LEN=103

You state in your initial post that you're sending snmp queries *from* somewhere else *to* this server, correct? Your input chain specifically states that you're allowing traffic destined for port 161 (SNMP) and the log entry above from the firewall clearly shows that the SOURCE port is 161. So iptables is blocking properly.

Let's try this. Two devices, A and B. A is the Nagios XI server, B is some other device. Are you attempting to query SNMP on the B device, or is B trying to send an SNMP query to A?

Hi XenoPhage and Cgraham, A is sending to B ...what I just realised is 192.168.171.1 is actually not the IP of the end device it is in fact an IP of an intermiddiate router..so somehow by design or an undocument feature the packets are getting NAT'd....cant understand why the source port is 161 though.....

[arnab.roy]

Do you have any other types of connectivity across the router?

In other words, from the location that snmpwalk fails, try:

telnet [nagiosip] 80

Additionally, the Source IP in the logs is the .1 address. Are you testing directly from the router/firewall/gateway, or is it NAT'ing the ip?

Yes ssh and ping works fine....

[scottwilkerson]

you could just allow these port both ways until you can resolve the problem

Code: Select all

iptables -I INPUT -i eth0 -p udp --dport 161:162 --sport 161:162 -j ACCEPT

[XenoPhage]

Hi XenoPhage and Cgraham, A is sending to B ...what I just realised is 192.168.171.1 is actually not the IP of the end device it is in fact an IP of an intermiddiate router..so somehow by design or an undocument feature the packets are getting NAT'd....cant understand why the source port is 161 though.....

The source port is 161 because that's the port the traffic was destined to from side A. This is proper. It would appear that the issue is the NAT device which is rewriting packets and changing the IP.. I'm not much of a NAT user, so I'm not 100% sure if that's proper or not. I wouldn't think so, but I could be wrong.

[CGraham]

Hi XenoPhage and Cgraham, A is sending to B ...what I just realised is 192.168.171.1 is actually not the IP of the end device it is in fact an IP of an intermiddiate router..so somehow by design or an undocument feature the packets are getting NAT'd....cant understand why the source port is 161 though.....

The source port is 161 because that's the port the traffic was destined to from side A. This is proper. It would appear that the issue is the NAT device which is rewriting packets and changing the IP.. I'm not much of a NAT user, so I'm not 100% sure if that's proper or not. I wouldn't think so, but I could be wrong.

The source is 161 on side A but the destination should be 161 on side B, where the firewall is. So a destination 161 rule SHOULD work (and does work when not traversing the router). Normally you'd allow the destination port on incoming and the source port on outgoing. Regardless, looks like the router is causing some heart-ache. So you can open both directions (which you'll likely need for outbound snmp checks anyway) or work with the network team to configure the router differently.

[XenoPhage]

The source is 161 on side A but the destination should be 161 on side B, where the firewall is. So a destination 161 rule SHOULD work (and does work when not traversing the router). Normally you'd allow the destination port on incoming and the source port on outgoing. Regardless, looks like the router is causing some heart-ache. So you can open both directions (which you'll likely need for outbound snmp checks anyway) or work with the network team to configure the router differently.

When you make an SNMP query, the destination port is 161. So, side A sends a packet destined for port 161 on side B and uses an ephemeral port as it's source. So you'd have something like A:12345 -> B:161. The return traffic from that query must be sourced from port 161 and destined to the ephemeral port that A chose. So the return traffic is B:161 -> A:12345. This is what is happening, but whatever the device in the middle is seems to be rewriting the packet so the return traffic is, instead, C:161 -> A:12345. iptables has no idea what C:161 is since there was no pinhole opened for it, so it properly blocks it.