Date: Wed, 09 Mar 2016 07:31:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207831] r293311 breaks OpenVPN routing using pf Message-ID: <bug-207831-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207831 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@FreeBSD.org Reporter: daniel.engberg.lists@pyret.net CC: freebsd-amd64@FreeBSD.org, melifaro@FreeBSD.org CC: freebsd-amd64@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 t= hat regard as a hub. This is setup using tunneling (tun interfaces). Upgrading to r295667 (including rebuilding everything) brakes this complete= ly (you cannot ping the other nodes either), so I decided to do some backtrack= ing 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 oth= er 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 interfac= es. 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 brok= en 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 --=20 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-207831-8>