> 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 . . .
Run multiple instances of tcpdump, with each instance writing to a different
output log file...
> 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
Looks good....
> Example [1]: IF=wan1, snmpwalk from internet host
>
> Example [2]: IF=eth1, snmpwalk from internet host
>
> Example [3]: IF=eth1, snmpwalk from local DCD
Ah...this helps. I thought all dumps were from the same interface, which
was confusing me greatly...
OK, it looks like there are several potential problems. The first one is
the fact that outbound SNMP responses from your DMZ are being masqeraded by
the firewall rules. This is a problem with the standard firewall rules
folks have run into before, I just wasn't tuning into it somehow (the
previous problem was for a game server, not SNMP, but both are UDP traffic).
If you want to open UDP services to the outside world, an ALLOW rule for the
response packets needs to be generated, so the packets don't hit the "catch
all" UDP masqerade rule at the end of the DMZ rules in the forward chain
(which allows DMZ systems to do things like make NTP requests to the
internet w/o any additional setup). Anyway, you need to find the following
in /etc/ipfilter.conf...it starts around line 746 on my firewall:
for DEST in $DMZ_OPEN_DEST; do
$IPCH -A forward -j ACCEPT -p `echoProto $DEST` \
-d `echoIpPort $DEST` -i $DMZ_IF
done; unset DEST
You need to add a case statment to generate the return-packet rule for any
UDP traffic, like so:
for DEST in $DMZ_OPEN_DEST; do
$IPCH -A forward -j ACCEPT -p `echoProto $DEST` \
-d `echoIpPort $DEST` -i $DMZ_IF
case "$DEST" in
UDP_*|udp_*|17_*)
$IPCH -A forward -j ACCEPT -p `echoProto $DEST` \
-s `echoIpPort $DEST` -i $EXTERN_IF ;;
esac
done; unset DEST
That should get you over the first hurdle. The next potential problem is
the remote system firewalling inbound SNMP traffic (the ICMP unreachable
messages), but I think this is due to the response packets coming from the
wrong IP. If you still get ICMP messages after fixing ipfilter.conf, you'll
need to examine the configuration on the remote firewall.
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.
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
