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
