Date: Thu, 16 Apr 2015 22:46:31 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 199489] NAT with IPv6 and PF round robins between external address and link-local address Message-ID: <bug-199489-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199489 Bug ID: 199489 Summary: NAT with IPv6 and PF round robins between external address and link-local address Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: freebsd@monkeyspunk.net Using NAT with IPv6 round robins each tcp session between link-local and the actual external IP. My setup is using openconnect attached to tun1 to allow my local private network access over the VPN to our data centers. From the remote side I am getting both and IPv4 and an IPv6 address (single address in both instances). So in order for my local network to communicate with the remote side I have to NAT everything to the address that tun1 gets assigned. What I am observing is that every other connection using IPv6 and NAT works. The ones that work end up using the public IPv6 IP address. The ones that don't end up with a NAT of the link-local address. The pf.conf rule that is triggering this behavior is: nat on tun1 inet6 from fc00::c0a8:fa00/120 to any -> (tun1) The expected behavior would be to ignore the link-local address. Or better yet have (tun1:0) reference the routable IP and not link-local. I have found a reference in the email lists to this problem with a possible patch: http://lists.freebsd.org/pipermail/freebsd-pf/2014-September/007441.html -- 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-199489-8>