Charles Steinkuehler wrote:
>
[ snip ]
>
> 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
Bravo! This works for internet hosts to snmpwalk dmz hosts . . .
> 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.
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?
[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
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: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)
12:40:58.558464 w.x.y.65.62737 > w.x.y.66.110: . ack 1 win 64240 (DF)
12:40:58.559094 w.x.y.66.110 > w.x.y.65.62737: P 1:34(33) ack 1 win 6144
(DF)
12:40:58.559721 w.x.y.65.62737 > w.x.y.66.110: P 1:12(11) ack 34 win
64207 (DF)
12:40:58.559956 w.x.y.66.110 > w.x.y.65.62737: P 34:39(5) ack 12 win
6133 (DF)
12:40:58.560445 w.x.y.65.62737 > w.x.y.66.110: P 12:25(13) ack 39 win
64202 (DF)
12:40:58.560617 w.x.y.66.110 > w.x.y.65.62737: P 39:44(5) ack 25 win
6120 (DF)
12:40:58.561085 w.x.y.65.62737 > w.x.y.66.110: P 25:31(6) ack 44 win
64197 (DF)
12:40:58.658497 w.x.y.66.110 > w.x.y.65.62737: . ack 31 win 6114 (DF)
12:40:58.779543 w.x.y.66.110 > w.x.y.65.62737: P 44:53(9) ack 31 win
6114 (DF)
12:40:58.780089 w.x.y.65.62737 > w.x.y.66.110: P 31:37(6) ack 53 win
64188 (DF)
12:40:58.780343 w.x.y.66.110 > w.x.y.65.62737: P 53:92(39) ack 37 win
6108 (DF)
12:40:58.780857 w.x.y.65.62737 > w.x.y.66.110: F 37:37(0) ack 92 win
64149 (DF)
12:40:58.780842 w.x.y.66.110 > w.x.y.65.62737: FP 92:92(0) ack 37 win
6108 (DF)
12:40:58.781059 w.x.y.66.110 > w.x.y.65.62737: . ack 38 win 6107 (DF)
12:40:58.781183 w.x.y.65.62737 > w.x.y.66.110: . ack 93 win 64149 (DF)
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]
[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: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)
12:40:58.558464 w.x.y.65.62737 > w.x.y.66.110: . ack 1 win 64240 (DF)
12:40:58.559094 w.x.y.66.110 > w.x.y.65.62737: P 1:34(33) ack 1 win 6144
(DF)
12:40:58.559721 w.x.y.65.62737 > w.x.y.66.110: P 1:12(11) ack 34 win
64207 (DF)
12:40:58.559956 w.x.y.66.110 > w.x.y.65.62737: P 34:39(5) ack 12 win
6133 (DF)
12:40:58.560445 w.x.y.65.62737 > w.x.y.66.110: P 12:25(13) ack 39 win
64202 (DF)
12:40:58.560617 w.x.y.66.110 > w.x.y.65.62737: P 39:44(5) ack 25 win
6120 (DF)
12:40:58.561085 w.x.y.65.62737 > w.x.y.66.110: P 25:31(6) ack 44 win
64197 (DF)
12:40:58.658497 w.x.y.66.110 > w.x.y.65.62737: . ack 31 win 6114 (DF)
12:40:58.779543 w.x.y.66.110 > w.x.y.65.62737: P 44:53(9) ack 31 win
6114 (DF)
12:40:58.780089 w.x.y.65.62737 > w.x.y.66.110: P 31:37(6) ack 53 win
64188 (DF)
12:40:58.780343 w.x.y.66.110 > w.x.y.65.62737: P 53:92(39) ack 37 win
6108 (DF)
12:40:58.780857 w.x.y.65.62737 > w.x.y.66.110: F 37:37(0) ack 92 win
64149 (DF)
12:40:58.780842 w.x.y.66.110 > w.x.y.65.62737: FP 92:92(0) ack 37 win
6108 (DF)
12:40:58.781059 w.x.y.66.110 > w.x.y.65.62737: . ack 38 win 6107 (DF)
12:40:58.781183 w.x.y.65.62737 > w.x.y.66.110: . ack 93 win 64149 (DF)
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]
What do you think?
--
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
