Date: Fri, 17 Mar 2017 23:13:19 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 217883] IPv6 with route_to broken with introduction of PF_FWD Message-ID: <bug-217883-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217883 Bug ID: 217883 Summary: IPv6 with route_to broken with introduction of PF_FWD Product: Base System Version: 11.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: vegeta@tuxpowered.net Introducing another direction "PF_FWD" broke possibility of forwarding IPv6 traffic if firewall has direction-matching rule on outgoing interface. In my case on public interface of a LoadBalancer has a rule witch catches the traffic and uses route_to to direct it to one of hosts inside network. Internal interface of this LoadBalancer has a rule "pass out quick on $if_intern_all keep state (tcp.first 5 tcp.opening 5)". Since this rule only passes direction PF_OUT, a IPv6 packet of direction PF_FWD won't match this rule. Traffic is then properly dropped on the last rule of my firewall. Observing dropped traffic on pflog0 shows that the direction PF_FWD is kept and even in the end show by tcpdump as "unk(3)". There are a few ways to solve it: 1. Teach tcpdump about PF_FWD, make pf_test_rule match packets with direction PF_FWD on rules with PF_OUT. https://github.com/innogames/freebsd/commit/581c3c88f460f6747c342f8a059d3cb92b8e155f https://github.com/innogames/freebsd/commit/7273dc2abac6c16ecaf28b63be69d3a1635a441f 2. Extend it even more, use PF_FWD for IPv4 too and teach pfctl to understand new direction "forward". That of course would break all firewall rules every written in the human history. 3. Or the simplest way: present direction PF_OUT to pf_test_rule no matter if PF_FWD was used or not: https://github.com/innogames/freebsd/commit/17a7601573372ac76f624e27d16936dbb80012e1 -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217883-8>
