dhcpagent + ipfilter := delayed loss of IP functionality?
in [Solaris]
|
From: hume.spamfilter on 15 Jan 2010 19:42 Jeroen Scheerder <js(a)xs4all.nl> wrote: > Well, they've been working just fine for many moons without alteration, and > still do the first 24hrs after a reboot. But since you ask (sanitized): It's surprising to see that they've only started acting up recently. I don't see any rules allowing port 67/udp and 68/udp traffic through. My own box has: pass in proto udp from any to any port = 67 keep state group 125 # DHCP pass in proto udp from any to any port = 68 keep state group 125 # DHCP -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: Jeroen Scheerder on 16 Jan 2010 07:23 <hume.spamfilter(a)bofh.ca> wrote: > > Well, they've been working just fine for many moons without alteration, and > > still do the first 24hrs after a reboot. But since you ask (sanitized): > > It's surprising to see that they've only started acting up recently. I > don't see any rules allowing port 67/udp and 68/udp traffic through. > > My own box has: > > pass in proto udp from any to any port = 67 keep state group 125 # DHCP > pass in proto udp from any to any port = 68 keep state group 125 # DHCP I don't think that's an issue. I have a pass out quick on hme0 proto tcp/udp from any to any keep state which I think allows outgoing DHCP requests and introdes a pseudo-stateful layer on that UDP session, effectively allowing the corresponding return traffic. And DHCP works. As I wrote, initially: "" Since it's configured by DHCP with a lease time of 1 day, I naturally suspected that. So I ran DHCP in debug mode, with a screen session containing a tcpdump writing all UDP 67, 68 packets to a file. This showed valid DHCP lease extensions and a valid renewal. "" So I have both a packet capture, showing DHCP requests and responses, and the dhcpagent debug log both acknowledging that lease extensions and renewals occur and succeed. Why things fall down remains a mystery. FWIW, running without ipfilter the box has remained fully operational without so much as a glitch... -- J$
From: Canuck57 on 16 Jan 2010 10:07 On 14/01/2010 12:20 PM, Jeroen Scheerder wrote: > Somewhere early december my trusty Netra X1, running Solaris 10, > vanished. > > Unable to go on location, somebody powercycled it for me and sanity was > restored. However, exactly one day later it repeated. > > Since it's configured by DHCP with a lease time of 1 day, I naturally > suspected that. So I ran DHCP in debug mode, with a screen session > containing a tcpdump writing all UDP 67, 68 packets to a file. > > This showed valid DHCP lease extensions and a valid renewal. Yet all > communications ceased, without anything showing for it in > /var/adm/messages. > > Then I had some local help, with access to systems allowed to ping it; > the system, while offering no service at all still responded to ICMP > requests. Some further experiments confirmed that these ICMP replies > even transgressing layer 2 boundaries. > > So apparently there remained a valid IP stack, with working routing, but > not much else. > > This system has been running for years, with ipfilter in place. Every > powercycle restored sanity for a day, but after 24hr things were sure to > go haywire, with no evidence why whatsoever to be found. > > I had no reason to suspect it, but without anything close to a clue I > just wanted to throw things out of the loop, and see of somehow sanity > would be restored. > > Well, since disabling the ipfilter service the system has stayed > functional. For the first 24 hours after booting that means unchanged > functionality; with ipfilter active, everything runs as it should. > Obviously, a few moments later this means a world of change. > > And I'm at a loss as to why this is. I don't know why this started > early december (although Solaris updates were applied not long before), > and I don't have sufficient diagnostics. I think I would know more if I > had been able to access the system in its known bad state, but having > been able to access it only in the normal state after the ensuing > powercycle that has been impossible. > > So the only thing I think I've seen so far is that > * a DHCP lease of 24hs > * ipfilter active > results in total loss of IP functionality exactly 24hrs after booting. > > Perhaps anyone has ideas to share? Could be the DHCP network. Did they change the lease times? Add more PCs to cause it to recycle IPs? If the DHCP server is chanign the IP, some rules will fail. My big question here is why not give it a fixed IP?
From: Richard B. Gilbert on 16 Jan 2010 10:34 Jeroen Scheerder wrote: > <hume.spamfilter(a)bofh.ca> wrote: > >>> Well, they've been working just fine for many moons without alteration, and >>> still do the first 24hrs after a reboot. But since you ask (sanitized): >> It's surprising to see that they've only started acting up recently. I >> don't see any rules allowing port 67/udp and 68/udp traffic through. >> >> My own box has: >> >> pass in proto udp from any to any port = 67 keep state group 125 # DHCP >> pass in proto udp from any to any port = 68 keep state group 125 # DHCP > > I don't think that's an issue. I have a > > pass out quick on hme0 proto tcp/udp from any to any keep state > > which I think allows outgoing DHCP requests and introdes a > pseudo-stateful layer on that UDP session, effectively allowing the > corresponding return traffic. And DHCP works. As I wrote, initially: > > "" > Since it's configured by DHCP with a lease time of 1 day, I naturally > suspected that. So I ran DHCP in debug mode, with a screen session > containing a tcpdump writing all UDP 67, 68 packets to a file. > > This showed valid DHCP lease extensions and a valid renewal. > "" > > So I have both a packet capture, showing DHCP requests and responses, > and the dhcpagent debug log both acknowledging that lease extensions and > renewals occur and succeed. > > Why things fall down remains a mystery. FWIW, running without ipfilter > the box has remained fully operational without so much as a glitch... > > > -- J$ Do you really NEED ipfilter? My router, by default, will not allow any incoming packet to pass unless it is a response to outgoing traffic. It's simple, relatively cheap, and it works! (LinkSys BEFR81)
From: hume.spamfilter on 16 Jan 2010 12:33
Jeroen Scheerder <js(a)xs4all.nl> wrote: > suspected that. So I ran DHCP in debug mode, with a screen session > containing a tcpdump writing all UDP 67, 68 packets to a file. I missed that bit. Regardless, it might be worthwhile to try adding an explicit allow rule, just to see any difference. Also, you could add a "log" keyword to the block-in-all rule to see if IPfilter is aware that it's blocking DHCP (and why). -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/ |