Date: Mon, 13 Mar 2017 13:56:30 -0400 From: Mike Tancsa <mike@sentex.net> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: pf bug with tun interfaces ? Message-ID: <e1679f63-247c-1da6-8f57-30c5dd23304e@sentex.net> In-Reply-To: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net> References: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e1679f63-247c-1da6-8f57-30c5dd23304e>