[Bug 217883] IPv6 with route_to broken with introduction of PF_FWD

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Mar 17 23:13:19 UTC 2017


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 at FreeBSD.org
          Reporter: vegeta at 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.


More information about the freebsd-bugs mailing list