[Bug 207831] r293311 breaks OpenVPN routing using pf

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831

            Bug ID: 207831
           Summary: r293311 breaks OpenVPN routing using pf
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Keywords: regression
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: daniel.engberg.lists at pyret.net
                CC: freebsd-amd64 at FreeBSD.org, melifaro at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

Hi,

I have a box that acts as a firewall (pf), gateway and VPN gateway running
OpenVPN. Upgrading from -CURRENT r290676 to r295667 broke some of the
functionality namely the ability to route traffic from the VPN to other
networks.

The network setup looks like this:

Network A (AMD64) - 192.168.20.0/24 (VPN: 10.0.9.1)
Network B - 192.168.40.0/24 (VPN: 10.0.9.240)
Network C (AMD64) - 192.168.1.0/24 (VPN: 10.0.9.253)

Network B and C connects to Network A and accesses both devices on Network A
but also between each others network, Network A (the box itself) works in that
regard as a hub. This is setup using tunneling (tun interfaces).

Upgrading to r295667 (including rebuilding everything) brakes this completely
(you cannot ping the other nodes either), so I decided to do some backtracking
to see where it stopped working. This is tested using full rebuilds (world,
kernel, ports) no partial ones.

r290676 - OK
r290866 - OK
r291136 - OK
r291262 - OK
r291465 - OK
r291855 - OK
r292004 - OK
r292019 - OK
r292158 - OK
r292483 - OK
r292626 - OK
r293017 - OK
r293108 - OK
r293313 - Broken
The only related commit I can find is r293311 which seems very resonable.

However it's not completely broken as Network C (client) can connect to other
networks via VPN running r295667 which seems a bit weird to me (if the hub is
working that is). Network B is a Linux client which also works but I don't
think that's relevant in this case.

Both Network A and Network C have no blocking filtering on the tun interfaces.

pass in quick on tun0 all
pass out quick on tun0 all

Unfortunately I'm not a developer so I can't really tell what's really broken
but I'm willing to test patches etc.

If there's anything else you need or have questions just fire off a mail and
I'll try to respond as useful as possible.

Keep up the good work!

Best regards,
Daniel Engberg

-- 
You are receiving this mail because:
You are on the CC list for the bug.