Date: Wed, 15 Mar 2017 17:28:34 +0900 From: "Kristof Provost" <kristof@sigsegv.be> To: "Mike Tancsa" <mike@sentex.net> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: pf bug with tun interfaces ? Message-ID: <AD6E6EB9-9FD8-4B9C-B401-2D750F17FA40@sigsegv.be> In-Reply-To: <e1679f63-247c-1da6-8f57-30c5dd23304e@sentex.net> References: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net> <e1679f63-247c-1da6-8f57-30c5dd23304e@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I don’t see any obvious reason why that would happen. Can you reduce this to a minimal test setup and include rc.conf, pf.conf, … with a bug report in bugzilla? Thanks, Kristof On 14 Mar 2017, at 2:56, Mike Tancsa wrote: > Just to add a bit more information, the problem appears solely with the > outbound nat via the tun interface. It doesnt matter the rdr is on a > regular nic or not, it still does not work when the nat statement is for > traffic on a tun interface. > So it appears its not possible to nat connections initiated TO openvpn > clients for some reason ? > > eg > > nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200) > > will not work. An IP address with a source address of 10.241.0.6 for > example, will not get natted as it travels to 10.211.1.28 on tun200 to > the client on OpenVPN > > ---Mike > > On 3/13/2017 9:52 AM, Mike Tancsa wrote: >> >> I am not sure if I have run into a bug or a limitation. Basically a rdr >> on one interface and then a nat on the outbound. It works fine when the >> interfaces are two physical network cards like an em and igb. But if >> both are tun interfaces, the nat doesnt work >> >> >> 2 servers and one router (all 3 freebsd) >> >> S1 and S2 and R1 >> >> s1 = 192.168.1.1 >> s2 = 10.0.0.1 >> >> R1 has >> 192.168.1.2 (igb0) and 10.0.0.2 (em0) >> >> if I connect from >> >> >> rdr pass log on igb0 proto tcp from 192.168.1.1 to 192.168.1.2 port 24 >> -> 10.0.0.1 port 22 >> nat pass log on em0 from 192.168.1.1 to any -> (em0) >> >> so from s1, if I do an >> ssh -b 192.168.1.1 -p 24 192.168.1.2 >> >> I land on the server 10.0.0.1 and the network connection/login is from >> 10.0.0.2. >> >> However, if the interfaces are tun0 and tun1 this does not work. The rdr >> works, but the nat never kicks in >> >> In the tun case, its two separate OpenVPN instances. A client (A) >> behind tun100 connects to the server's IP on tun100 on port X. The RDR >> rule does a redirect to port Y on a client's IP (B) on tun200. The RDR >> works, but the packet is not natted. Its the source address of client A >> that appears at client B and not the natted IP of tun200. >> >> The tun version looks like >> >> rdr pass log on tun100 proto tcp from 10.241.0.0/23 to self port 5023 -> >> 10.211.1.28 port 6901 >> nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200) >> >> In the above 2 lines, the target client, 10.211.1.28 sees a network >> connection attempt from 10.241.1.6 and not the IP of tun200 as I would >> expect. >> >> ---Mike >> >> > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD6E6EB9-9FD8-4B9C-B401-2D750F17FA40>