pf and mxge

Adam McDougall mcdouga9 at
Fri Aug 29 13:13:44 UTC 2008

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
  Can you provide your pf.conf?
  | Jeremy Chadwick                                jdc at |

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).

More information about the freebsd-pf mailing list