dhcpagent + ipfilter := delayed loss of IP functionality?
in [Solaris]
|
From: Jeroen Scheerder on 16 Jan 2010 13:39 Chris Ridd <chrisridd(a)mac.com> wrote: > > 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). > > How long does ipfilter keep state for connection tracking? Has it changed? I haven't changed that, though a Solaris patch may have early december. The particular session is short-lived, though, and successful at that (as tcpdump and dhcpagent debug output prove). The session starts with the client request, and is answered by the server within milliseconds.
From: hume.spamfilter on 16 Jan 2010 14:05 Chris Ridd <chrisridd(a)mac.com> wrote: > How long does ipfilter keep state for connection tracking? Has it changed? Since it'd be his machine doing the DHCP renew, it should be sourcing the traffic and creating a new state... it'd only have to survive for a minute, if that. -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: Chris Ridd on 16 Jan 2010 14:10 On 2010-01-16 19:05:42 +0000, hume.spamfilter(a)bofh.ca said: > Chris Ridd <chrisridd(a)mac.com> wrote: >> How long does ipfilter keep state for connection tracking? Has it changed? > > Since it'd be his machine doing the DHCP renew, it should be sourcing the > traffic and creating a new state... it'd only have to survive for a minute, > if that. Yeah. I was wondering if the state had stuck for 24 hours and somehow banjaxed the next "connection". -- Chris
From: Oscar del Rio on 16 Jan 2010 15:01 Jeroen Scheerder 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): > # > pass out quick on hme0 proto icmp all keep state > pass out quick on hme0 proto tcp/udp from any to any keep state > # > # SSH, SMTP, HTTP, HTTPS, submission, IMAPS > pass in quick on hme0 proto tcp from any to any port = 22 keep state > pass in quick on hme0 proto tcp from any to any port = 25 keep state > pass in quick on hme0 proto tcp from any to any port = 80 keep state > pass in quick on hme0 proto tcp from any to any port = 443 keep state > pass in quick on hme0 proto tcp from any to any port = 587 keep state > pass in quick on hme0 proto tcp from any to any port = 993 keep state Your (TCP) "keep state" rules are missing the "FLAGS S" option. It's possible that the state tables are filling up because of this. See the IPFilter FAQ: http://www.phildev.net/ipf/IPFprob.html 2. I have to keep clearing the state table or IPF dies, why? Don't know why it was not a problem before but recent ipf patches might have made changes to the handling of the state tables.
From: Richard B. Gilbert on 16 Jan 2010 15:59
Jeroen Scheerder wrote: > Richard B. Gilbert <rgilbert88(a)comcast.net> wrote: > >> 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) > > No, I don't really need it. This is a very hardened installation, and I > do maintain software and am very cautious (up to the point of fullblown > paranoia) in service configurations. > > My paranoia also makes me want to block ports I'm not listening on > anyway, and drop traffic I'm sure not to need on ports I might be > listening on. > > FWIW, this system is quite near the Internet backbone. Fully routed, > with a full 100mbit Internet link - and nothing inbetween except layer 3 > routing. No NAT. No ACLs. Nothing. If you remove IPFILTER for testing purposes do things broken start working? If they still don't work you have eliminated IPFILTER as the "sole cause" of your problems. There is always the possibility that your problems have two or more causes. Two is less likely than one but it's possible. |