Date: Wed, 31 Oct 2018 07:45:36 -0400 From: John Jasen <jjasen@gmail.com> To: FreeBSD PF <freebsd-pf@freebsd.org> Subject: NFSv4 connections and pf: BAD state stalling issues? Message-ID: <ddeb101d-82fc-ec45-1444-98c73b330eb9@gmail.com>
next in thread | raw e-mail | index | archive | help
We run pf-based firewalls between linux-based servers and linux-clients over NFSv4. Periodically, events we've not pinned down cause the connection to be blocked at the firewall, manifesting as stale NFS mounts on the clients. These blocks were not logged at normal levels in pflog. I need to double check to see if enabling verbose logging has helped. The only way we've found to unblock them is to manually flush the state between the offending clients and the server with pfctl -k server-ip -k client-ip Before flushing the state table, pfctl -x loud will show: kernel: pf: BAD state: TCP in wire: client-ip:priv-port server-ip:2049 stack: - [lo=3D1342594619 high=3D1342782267 win=3D38400 modulator=3D0 wsc= ale=3D11] [lo=3D905052699 high=3D982817819 win=3D733 modulator=3D0 wscale=3D8] 4:4 = S seq=3D4197460108 (4197460108) ack=3D905052699 len=3D0 ackskew=3D0 pkts=3D290647578:883730744 dir=3Din,fwd So, it looks to me like the client lost contact initially, and is attempting to re-establish the connection. Given its recycling the same source port and destination and its a new SYN, this drives pf to declare the state bad and drop it. Any ideas on how to address this? Or where to look for issues? Thanks in advance! -- John Jasen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ddeb101d-82fc-ec45-1444-98c73b330eb9>