Charles Steinkuehler wrote: > > > I was not certain what it is that you want to see -- see below. > > > > tcpdump output, run on the local DCD : > > OK, this helps, but I'm still not sure what I'm looking at. Which interface > did you run the tcpdump on? I'm guessing from the packet traffic we're > looking at the upstream interface, and not the DMZ interface, but it's hard > to be sure... > > Your first case: > > > [1] Internet host (a.b.c.d) query -> dmz host (w.x.y.66) via DCD external > port (w.x.z.157) > > > > 14:47:11.577976 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity > GetNextRequest(17) [|snmp] > > 14:47:11.578411 w.x.z.157.64943 > a.b.c.d.64861: udp 107 > > 14:47:11.598985 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 > unreachable [tos 0xc0] > > 14:47:12.600050 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity > GetNextRequest(17) [|snmp] > > 14:47:12.600443 w.x.z.157.64943 > a.b.c.d.64861: udp 107 > > 14:47:12.686292 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 > unreachable [tos 0xc0] > <repeats> > > This is just wacky...looks like the remote system sends an SNMP query, > followed by your firewall sending a UDP query back to the remote system. > Finally, the remote system replies with a "destination unreachable" packet, > probalby meaning inbound UDP packets are firewalled (or connection tracked).
Hence, my confusion . . . > My best guess at this point is that your outbound UDP traffic is being > masqueraded, and the packet: > 14:47:11.578411 w.x.z.157.64943 > a.b.c.d.64861: udp 107 > is actually the SNMP response, being masqueraded by your firewall... > > NOTE: All UDP traffic (other than DNS) is masqueraded from the DMZ using > the default Dachstein firewall rules, which could explain the above traffic. > Even so, the difference between [1], above, and [2], below, has me > confused...something had to change between these two samples (or perhaps an > unnoted change in the test procedure?). Yes, same test; but, tcpdump on different interface -- see below. > Your second case: > > > [2] Internet host (a.b.c.d) query -> dmz host (w.x.y.66) via DCD dmz port > (w.x.z.157) > > > > 14:50:05.672129 a.b.c.d.64919 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > > 14:50:05.672360 w.x.y.66.161 > a.b.c.d.64919: C=privateCommunity > GetResponse(3)[|snmp] > > 14:50:05.692707 a.b.c.d > w.x.y.66: icmp: a.b.c.d udp port 64919 > unreachable [tos 0xc0] > > 14:50:06.682834 a.b.c.d.64919 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > > 14:50:06.683065 w.x.y.66.161 > a.b.c.d.64919: C=privateCommunity > GetResponse(3)[|snmp] > > 14:50:06.702159 a.b.c.d > w.x.y.66: icmp: a.b.c.d udp port 64919 > unreachable [tos 0xc0] > <repeats> > > This looks a bit more normal...what changed between this trace and the first > trace? Your description is identical. > > Here you're seeing the SNMP request, followed by an SNMP response, and > finally the ICMP "destination unreachable" message back from the remote > host. It sure looks like "a.b.c.d" is firewalling or otherwise dropping > your response packets... a.b.c.d is an internet address on the external IF of a remote DCD, behind which is the debian potato from which I tried to snmpwalk the subject dmz hosts. > Finally, we get to: > > > [3] DCD external port (w.x.y.65 - alias) query -> dmz host (w.x.y.66) via > DCD external port (w.x.z.157) > > > > 14:51:46.455695 w.x.y.65.4709 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > > 14:51:47.460138 w.x.y.65.4709 > w.x.y.66.161: C=privateCommunity > GetNextRequest(3)[|snmp] > <repeats> > > Here we've got nothing but the query packets...no response traffic at all. This is local DCD to local dmz attempted snmpwalk -- identical query to the previous, remote queries. > Without knowing which port you're running tcpdump on, and some more details > about your test, I can't help much more... > > Try to forget everything you know about your network architecture, and look > at line [3], above. To me, this is saying you're trying to access your > internal DMZ host via SNMP from the firewall's external port. For one, this > doesn't really even make sense...if the firewall's talking SNMP to the DMZ, > the traffic will be going out the DMZ interface, with a source IP of the > DMZ's primary address. I'm not even sure how you'd get snmpwalk or > something to use the external IP over the default interface IP. Not knowing > which interface the tcpdump came from is also kind of limiting. See ip addr and ip route output below. > Any interesting results when looking at the packet counts in your ipchains > rules? No -- nothing is logged and when I subtract the obvious: # ipchains -nvL | grep -v '\(ACCEPT\|-l-\)' there is nothing that I find interesting in remaining output. ===== I am sorry; but, I thought that I differentiated each of my examples. Is there away to get tcpdump to listen to more than one (1) interface at a time? -i any does *not* work . . . This is the invocation, all examples run from the local DCD: tcpdump \ -i $IF \ -l \ -n \ ip \ and not port domain \ and not port ssh \ and not port www Example [1]: IF=wan1, snmpwalk from internet host Example [2]: IF=eth1, snmpwalk from internet host Example [3]: IF=eth1, snmpwalk from local DCD # ip addr 1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: ipsec0: <NOARP,UP> mtu 16260 qdisc pfifo_fast qlen 10 link/ppp inet w.x.z.157 peer w.x.z.158/32 scope global ipsec0 3: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10 link/ipip 4: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10 link/ipip 5: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10 link/ipip 6: brg0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop link/ether fe:fd:0f:00:5b:d9 brd ff:ff:ff:ff:ff:ff 7: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 8: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff inet w.x.y.65/26 brd w.x.y.127 scope global eth1 27: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ppp inet w.x.z.157 peer w.x.z.158/32 scope global wan1 inet w.x.y.72/32 scope global wan1 # ip route w.x.z.158 dev wan1 proto kernel scope link src w.x.z.157 w.x.z.158 dev ipsec0 proto kernel scope link src w.x.z.157 w.x.y.64/26 dev eth1 scope link 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 192.168.123.0/24 via w.x.z.158 dev ipsec0 default via w.x.z.158 dev wan1 -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user