[Leaf-user] DCD, proxy dmz, snmp & icmp ???
We have a DCD setup, including a proxy dmz. SNMP queries work everywhere, excepting systems residing on that dmz. Let me clarify that: snmp queries respond properly from clients inside the private network; but, *not* from the DCD firewall nor internet hosts. Running iptraf on the firewall, we see the snmp queries properly forwarded to the dmz host; but, *nothing* returns from that host. Instead, we see a flurry of these: ICMP; lo; 99 bytes; from bluetrout.private.network \ to bluetrout.private.network; dest unrch (port) Notice that bluetrout is the firewall. We're unclear as to why snmp queries have anything to do with icmp. What is going on here? What are possible solutions? 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
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
Charles Steinkuehler wrote: > > > We have a DCD setup, including a proxy dmz. > > > > SNMP queries work everywhere, excepting systems residing on that dmz. > > Let me clarify that: snmp queries respond properly from clients inside > > the private network; but, *not* from the DCD firewall nor internet > > hosts. > > > > Running iptraf on the firewall, we see the snmp queries properly > > forwarded to the dmz host; but, *nothing* returns from that host. > > Instead, we see a flurry of these: > > > > ICMP; lo; 99 bytes; from bluetrout.private.network \ > > to bluetrout.private.network; dest unrch (port) > > > > Notice that bluetrout is the firewall. > > > > We're unclear as to why snmp queries have anything to do with icmp. > > > > What is going on here? What are possible solutions? > > > > What do you think? > > Do you have SNMP_BLOCK and SNMP_MANAGER_IPS set properly? Yes -- that's how it works everywhere, excepting the dmz . . . > Since it sounds like the packets may actually be getting to the DMZ host, do > you maybe have a network configuration issue on that system? Actually, it is two (2) systems (netware ;<) on that dmz . . . > Your error report lacks enough detail for me to figure out exactly what's > happening...not only am I unfamiliar with iptraf output (more of a tcpdump > man), IP addresses would be more helpful (does the above really indacate > your firewall is pinging itself over the loopback interface, like I think it > does?), as well as other details (like details on the packets that you think > were OK and went through to the DMZ host). I was not certain what it is that you want to see -- see below. > If your local net can see SNMP services on the DMZ host (you indicate it > can), but the firewall cannot, something wierd is going on. The internal > snmp requests should be using the same query IP as the firewall, since the > internal net is masqueraded to the DMZ. Are your firewall rules blocking > anything? Did you remember to check (watch the byte/packet counts before > and after trying to access your non-working service)? tcpdump output, run on the local DCD : [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] 14:47:13.592798 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity GetNextRequest(17) [|snmp] 14:47:13.593156 w.x.z.157.64943 > a.b.c.d.64861: udp 107 14:47:13.621180 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 unreachable [tos 0xc0] 14:47:14.607662 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity GetNextRequest(17) [|snmp] 14:47:14.608002 w.x.z.157.64943 > a.b.c.d.64861: udp 107 14:47:14.629095 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 unreachable [tos 0xc0] 14:47:15.611646 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity GetNextRequest(17) [|snmp] 14:47:15.611993 w.x.z.157.64943 > a.b.c.d.64861: udp 107 14:47:15.630231 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 unreachable [tos 0xc0] 14:47:16.623665 a.b.c.d.64861 > w.x.y.66.161: C=privateCommunity GetNextRequest(17) [|snmp] 14:47:16.624025 w.x.z.157.64943 > a.b.c.d.64861: udp 107 14:47:16.647831 a.b.c.d > w.x.z.157: icmp: a.b.c.d udp port 64861 unreachable [tos 0xc0] [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] 14:50:07.689494 a.b.c.d.64919 > w.x.y.66.161: C=privateCommunity GetNextRequest(3)[|snmp] 14:50:07.689727 w.x.y.66.161 > a.b.c.d.64919: C=privateCommunity GetResponse(3)[|snmp] 14:50:07.707398 a.b.c.d > w.x.y.66: icmp: a.b.c.d udp port 64919 unreachable [tos 0xc0] 14:50:08.702497 a.b.c.d.64919 > w.x.y.66.161: C=privateCommunity GetNextRequest(3)[|snmp] 14:50:08.702724 w.x.y.66.161 > a.b.c.d.64919: C=privateCommunity GetResponse(3)[|snmp] 14:50:08.721155 a.b.c.d > w.x.y.66: icmp: a.b.c.d udp port 64919 unreachable [tos 0xc0] 14:50:09.712075 a.b.c.d.64919 > w.x.y.66.161: C=privateCommunity GetNextRequest(3)[|snmp] 14:50:09.712311 w.x.y.66.161 > a.b.c.d.64919: C=privateCommunity GetR
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
> We have a DCD setup, including a proxy dmz. > > SNMP queries work everywhere, excepting systems residing on that dmz. > Let me clarify that: snmp queries respond properly from clients inside > the private network; but, *not* from the DCD firewall nor internet > hosts. > > Running iptraf on the firewall, we see the snmp queries properly > forwarded to the dmz host; but, *nothing* returns from that host. > Instead, we see a flurry of these: > > ICMP; lo; 99 bytes; from bluetrout.private.network \ > to bluetrout.private.network; dest unrch (port) > > Notice that bluetrout is the firewall. > > We're unclear as to why snmp queries have anything to do with icmp. > > What is going on here? What are possible solutions? > > What do you think? Do you have SNMP_BLOCK and SNMP_MANAGER_IPS set properly? Since it sounds like the packets may actually be getting to the DMZ host, do you maybe have a network configuration issue on that system? Your error report lacks enough detail for me to figure out exactly what's happening...not only am I unfamiliar with iptraf output (more of a tcpdump man), IP addresses would be more helpful (does the above really indacate your firewall is pinging itself over the loopback interface, like I think it does?), as well as other details (like details on the packets that you think were OK and went through to the DMZ host). If your local net can see SNMP services on the DMZ host (you indicate it can), but the firewall cannot, something wierd is going on. The internal snmp requests should be using the same query IP as the firewall, since the internal net is masqueraded to the DMZ. Are your firewall rules blocking anything? Did you remember to check (watch the byte/packet counts before and after trying to access your non-working service)? 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
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
> 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] 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). 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?). 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] 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... 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] Here we've got nothing but the query packets...no response traffic at all. 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. Any interesting results when looking at the packet counts in your ipchains rules? 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
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
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] > > > 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] > > > 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] > > > 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, al
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
> 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
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
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 (DF) 12:40:58.558166 w.x.y.66.110 > w.x.y.65.62737: S 1431617489:1431617489(0) ack 2835461866 win 6144 (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)[|sn
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
> 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 (DF) > 12:40:58.558166 w.x.y.66.110 > w.x.y.65.62737: S > 1431617489:1431617489(0) ack 2835461866 win 6144 (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
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
Charles Steinkuehler wrote: > > > Did you see this, yesterday? > > Yeah...got distracted while analizing & it got dropped... OK, sorry for my impatience . . . > > > 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? Yes, and else, too ;> [ snip ] > 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? Join the club ;> w.x.y.66 is a netware v5.x box, a mail server running groupies, &c. It's not my environment, but an associate's. I know (next to) nothing about netware and he knows nearly nothing about snmp. I've queried snmp v1, 2c and 3 -- all same results. No, there is not any ip filtering on that box. > 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... Yes, I can snmpwalk w.x.y.66 *both* from a remote internet host _and_ from some moronic wintel box inside its internal network (notice, *not* on the dmz). This weekend, I will try to comply with your latest test . . . Follows, hopefully readable, is output of net ipfilter list from subject DCD: Chain input (policy DENY: 7 packets, 801 bytes): pkts bytes target prot opttosa tosx ifname mark outsize sourcedestination ports 0 0 DENY all -- 0xFF 0x00 wan1 0.0.0.0/0 255.255.255.255 n/a 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 5 -> * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 13 -> * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 14 -> * 0 0 DENY all l- 0xFF 0x00 wan1 0.0.0.0 0.0.0.0/0 n/a 143 DENY all l- 0xFF 0x00 wan1 255.255.255.255 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 127.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 224.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 10.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 172.16.0.0/12 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 192.168.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 0.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 128.0.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 191.255.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 192.0.0.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 223.255.255.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 wan1 240.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 w
Re: [Leaf-user] DCD, proxy dmz, snmp & icmp ???
"Michael D. Schleif" wrote: > > Charles Steinkuehler wrote: > > > [ snip ] > > > 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? > > Join the club ;> > > w.x.y.66 is a netware v5.x box, a mail server running groupies, &c. ^^^ groupwise Bad, bad, spellchecker ;< > It's not my environment, but an associate's. I know (next to) nothing > about netware and he knows nearly nothing about snmp. I've queried snmp > v1, 2c and 3 -- all same results. No, there is not any ip filtering on > that box. [ snip ] -- 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
