IP Tables - Can't access devices when IP Tables are active

[DateMike]

No, OUPUT is set to accept, so everything should flow through there.

[TrevorH]

Then I guess it's a setting within snmpd.conf - you'll get that message if you try to use an invalid community but I don't know enough about snmpd.conf to know if you can restrict access to certain community strings by ip.

[jlehtone]

Did you try listening to the interface when the other machine makes an snmp query?

[DateMike]

How do I listen to the interface and do an snmp check from the server at the same time?

I only have the Centos Server and the devices which send snmp to the server in the network.

[TrevorH]

I think the idea was to fire up e.g. tcpdump udp and port 161 -n -nn -l -i any and watch to see if traffic arrived at your box and if anything responded.

[jlehtone]

Yes, except that we are interested in non-port-161 packets, as the firewall is supposedly open on 161.

How do I listen to the interface and do an snmp check from the server at the same time?

I did not realize that you run the 'snmpwalk' in the server, reaching out.
You do have a session in the server somehow. Is it console, GUI, or remote (ssh)?
In each case it is possible to have more than one simultaneous session.
However, a single session is sufficient.

Code: Select all

# start tcpdump as asynchronous background process
# and direct output to a file
tcpdump -n -nn -l -i any not port 22 > fw-snmp-test.log &
# run the test
snmpwalk -v 2c -c public 10.0.0.51
# bring the tcpdump back to foreground
fg
# quit tcpdump with Ctrl-c
# look at the traffic
less fw-snmp-test.log

[DateMike]

Hi jlehtone,

I have an SSH connection to server.

See Below entries in to Server:

Code: Select all

[root@SERVERDNS ~]# tcpdump -n -nn -l -i any not port 22 > fw-snmp-test.log &
[2] 1297
[root@SERVERDNS ~]# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
tcpdump -n -nn -l -i asnmpwalk -v 2c -c public 10.0.0.51
Timeout: No Response from 10.0.0.51
[root@SERVERDNS ~]# fg
tcpdump -n -nn -l -i any not port 22 > fw-snmp-test.log
^C7393 packets captured
13610 packets received by filter
149 packets dropped by kernel

See Below results of log file:

Code: Select all

less fw-snmp-test.log
09:40:12.866477 ARP, Request who-has SOME PUBLIC IP A tell SOME PUBLIC IP B, length 46
09:40:12.876934 ARP, Request who-has SOME PUBLIC IP C tell SOME PUBLIC IP B, length 46
09:40:12.898834 IP 10.13.0.98.137 > 10.13.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:40:12.899260 IP 10.13.0.98.55864 > 224.0.0.252.5355: UDP, length 24
09:40:12.899601 IP 192.168.0.198.137 > 192.168.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:40:12.899966 IP 192.168.0.198.50394 > 224.0.0.252.5355: UDP, length 24
09:40:12.900799 IP 10.13.0.98.137 > 10.13.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:40:12.901086 IP 10.13.0.98.53798 > 224.0.0.252.5355: UDP, length 24
09:40:12.901333 IP 192.168.0.198.137 > 192.168.0.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:40:12.901659 IP 192.168.0.198.60249 > 224.0.0.252.5355: UDP, length 24
09:40:12.914256 ARP, Request who-has SOME PUBLIC IP D tell SOME PUBLIC IP B, length 46
09:40:12.918157 ARP, Request who-has SOME PUBLIC IP E tell SOME PUBLIC IP B, length 46
09:40:12.959472 IP 127.0.0.1.48991 > 127.0.0.1.5432: Flags [P.], seq 2050600983:2050601040, ack 4111920964, win 1585, options [nop,nop,TS val 523888952 ecr 523887950], length 57

Regards,

[TrevorH]

I think you have some external firewall blocking udp port 161. It's the only port that needs to be open for snmp queries to work - tcp is not used as far as I know and I have 100+ boxes that all work perfectly with only udp port 161 open.

[DateMike]

But there can't be an external Firewall, when the IPTables service is off the SNMP works 100% a ok, when the service is on is when the SNMP doesn't work.

[TrevorH]

But tcpdump sees packets before they hit iptables and there are none in your output. If the packets were hitting your machine and being denied by iptables then you'd still see them in the tcpdump output.