From owner-freebsd-net@freebsd.org Wed Mar 15 08:28:47 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 7D52DD0BD62 for ; Wed, 15 Mar 2017 08:28:47 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 658ED191C for ; Wed, 15 Mar 2017 08:28:46 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from [192.168.8.218] (203.141.139.231.static.zoot.jp [203.141.139.231]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 566B71ED78; Wed, 15 Mar 2017 09:28:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1489566519; bh=Cnh06XgYf5Y/OzOpSV+4P/ArFIyRu9XiBI3b1qc1sUo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hc+tG0hPKcPlhrMH/B3fnySshOijrqGULPmdIDePA5CKmPEZoMzhbMfDCcIW0fnEt zd9dubV3kBfJ2u0z2pjHYaBLKI4C6kJqBfHO2+KFTD5W6MC93gW1tcPl2vSn5CFez6 aM9SS0Jf7pC59QTiwxsPgqB2nz7iSe6ZutFPyB2o= From: "Kristof Provost" To: "Mike Tancsa" Cc: "freebsd-net@freebsd.org" Subject: Re: pf bug with tun interfaces ? Date: Wed, 15 Mar 2017 17:28:34 +0900 Message-ID: In-Reply-To: References: <1b605589-9642-ee92-fb9b-9ff5b4798316@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6080) 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: Wed, 15 Mar 2017 08:28:47 -0000 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"