From owner-freebsd-net@freebsd.org Mon Mar 13 17:56:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E157D0A833 for ; Mon, 13 Mar 2017 17:56:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 03E621C0D for ; Mon, 13 Mar 2017 17:56:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v2DHuVu0045443 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 13 Mar 2017 13:56:31 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v2DHuTup058377 for ; Mon, 13 Mar 2017 13:56:29 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: pf bug with tun interfaces ? To: "freebsd-net@freebsd.org" References: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: Date: Mon, 13 Mar 2017 13:56:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:56:33 -0000 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/