Date: Fri, 29 Aug 2008 08:55:49 -0400 From: Adam McDougall <mcdouga9@egr.msu.edu> To: ben wilber <ben@desync.com>, freebsd-pf@freebsd.org Subject: Re: pf and mxge Message-ID: <20080829125549.GR64444@egr.msu.edu> In-Reply-To: <20080829110358.GA72503@icarus.home.lan> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 29, 2008 at 04:03:58AM -0700, Jeremy Chadwick wrote: On Fri, Aug 29, 2008 at 06:54:23AM -0400, ben wilber wrote: > I'm trying to use PF on a machine with an mxge(4) interface and am > having some difficulty. With my ruleset loaded, any TCP session that > gets a state grinds to a halt. > > For example, I can log in via SSH and issue commands that return a > couple lines, but the output from a command like dmesg(8) comes very > slowly and sometimes won't finish before SSH times out. MTU on the > interface is 1500 bytes. This doesn't happen unless states are created > (e.g., not with "pass no state"). > > The machine is running -CURRENT for amd64 as of Jul 18th compiled with > ALTQ, crypto and IPSEC, HZ=1000 and DEVICE_POLLING (though not enabled). > IP and IPv6 forwarding are enabled, as well as fastforwarding. Only > filtering; no bridges, ALTQ, NAT or scrubbing. > > Any insight? I've seen this problem on RELENG_6, although the SSH connections would not "time out" -- after a page or so of 'dmesg' output, they would immediately get disconnected/severed. I believe the problem was caused by my use of "modulate state" instead of "keep state" (since on RELENG_6 "keep state" is not implicit). Are you using "reassemble tcp", "synproxy state", or "modulate state" directives? Does disabling RFC1323 (see sysctl) make a difference at all? Are you blindly filtering all ICMP traffic and destroying PMTU negotiation? Can you provide your pf.conf? -- | Jeremy Chadwick jdc at parodius.com | Just for posterity, I had similar problems and ended up getting rid of floating state in favor of "set state-policy if-bound". If you run pfctl -x loud and watch the kernel output, you should be able to see a state mismatch when the ssh has a problem. Warning, I've had consoles lock up with too much output from pfctl -x loud, so if you care, don't run it too long or with too much traffic (pfctl -x none to disable).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080829125549.GR64444>