> Did you see this, yesterday? Yeah...got distracted while analizing & it got dropped...
> > The final problem is the fact that you can't do an snmpwalk from the > > firewall to the DMZ. Apparently, the SNMP query packets are transmitted, > > but no response is recieved. I still don't understand why this is > > happening, especially if you can do an snmpwalk from the internal network (I > > think I remember you saying you could...) > > > > Patch your ipfilter.conf, and see how much farther that gets you. If you > > still can't snmpwalk from the firewall, take tcpdumps at both the firewall > > (DMZ IF) and the DMZ system, while trying to snmpwalk from both the firewall > > and from an internal system. > > Following are dumps for snmpwalk failure between DCD and one of its dmz > hosts. I have tried to remove spurious data, like Unknown IPX packet > stuff ;< The rest I could not rule out -- can you? We'll see...are you actually running an IPX network? > [1] tcpdump on DCD, ostensibly pointing only to itself: > > tcpdump \ > -i eth1 \ > -l \ > -n \ > not port domain \ > and not port smtp \ > and not port ssh \ > and not port www Looks good... > 12:40:34.280871 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:35.290141 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:36.300099 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:37.310112 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:38.320089 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:39.280028 arp who-has w.x.y.66 tell w.x.y.65 > 12:40:39.280169 arp reply w.x.y.66 is-at 0:6:29:a8:1d:df > 12:40:39.330112 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] These are your SNMP queries, apparently going into never-never land (no respnoses). The arp query at least indicates both your .65 and .66 systems know each other's physical & logical address. > 12:40:58.557946 w.x.y.65.62737 > w.x.y.66.110: S > 2835461865:2835461865(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) > 12:40:58.558166 w.x.y.66.110 > w.x.y.65.62737: S > 1431617489:1431617489(0) ack 2835461866 win 6144 <mss 1460> (DF) This is pop traffic...the .66 machine must be doing e-mail (also supported by your "not port smtp" in the tcpdump filter. Further port 110 traffic deleted. > 12:41:05.346234 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:06.350100 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:07.360117 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:08.370085 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:09.380095 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:10.390114 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] More SNMP queries w/o any response... > [1] tcpdump on DCD, ostensibly pointing only to its dmz host: > > tcpdump \ > -i eth1 \ > -l \ > -n \ > host w.x.y.66 \ > and not port domain \ > and not port smtp \ > and not port ssh \ > and not port www > > 12:40:34.280871 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:35.290141 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:36.300099 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:37.310112 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:38.320089 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:40:39.280028 arp who-has w.x.y.66 tell w.x.y.65 > 12:40:39.280169 arp reply w.x.y.66 is-at 0:6:29:a8:1d:df > 12:40:39.330112 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:05.346234 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:06.350100 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:07.360117 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:08.370085 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:09.380095 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > 12:41:10.390114 w.x.y.65.4712 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] Looks like more of the same... > What do you think? I'm confused. I don't think the firewall rules on the .65 machine can be your problem, since you're seeing the request packets go out, and even if the replies were being dropped, tcpdump would see them at the interface. About the only thing that comes to mind is your snmp configuration on the .66 machine. Are you *SURE* you've allowed snmp queries from the firewall IP and you're not firewalling any traffic on the .66 system? Which version of SNMP are you running? If you can't find any problems with the configuration of the .66 machine, do a tcp dump on the DMZ IF of the the firewall while trying to snmpwalk from the firewall and from an internal network system (am I remembering correctly that you said internal systems could see the DMZ snmp server?). It would probalby also help if you provide the output of net ipfilter list and your snmp config file from the DMZ system... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
