From owner-freebsd-net@freebsd.org Tue Feb 23 07:06:18 2016 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 8C757AB1689 for ; Tue, 23 Feb 2016 07:06:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AA551EE7 for ; Tue, 23 Feb 2016 07:06:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u1N7668B007158 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Feb 2016 23:06:07 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: gateway machine port redirect question To: Ian Smith References: <43887.128.135.52.6.1456021321.squirrel@cosmo.uchicago.edu> <56CA5519.4080000@freebsd.org> <20160222175549.L51785@sola.nimnet.asn.au> Cc: galtsev@kicp.uchicago.edu, freebsd-net@freebsd.org From: Julian Elischer Message-ID: <56CC04D8.6060206@freebsd.org> Date: Mon, 22 Feb 2016 23:06:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160222175549.L51785@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 07:06:18 -0000 On 22/02/2016 4:03 AM, Ian Smith wrote: > On Sun, 21 Feb 2016 16:32:53 -0800, Julian Elischer wrote: > > On 20/02/2016 6:22 PM, Valeri Galtsev wrote: > > > Dear Experts, > > > > > > I'm one of Linux refugees who several years ago migrated majority of > > > servers from Linux to FreeBSD and is happy since. When recently I needed > > > to set up gateway (Firewall + NAT) machine, I set up FreeBSD 10.2 on it, > > > used ipwf and natd, and all works well, machines behind gateway on LAN can > > > happily reach real network. I hit one snag later though: When I tried to > > > redirect TCP traffic on some port to machine on internal private network > > > behind gateway, whatever I do doesn't work. > > > > > > Could somebody point to simple example (it doesn't matter which components > > > are involved, I don't feel married to ipfw and natd) for FreeBSD 10.2 that > > > makes the machine gateway, and one of the ports of traffic coming from > > > public network is redirected to machine on private network behind gateway. > > > Something I can reproduce that works, which I then will gradually convert > > > into what I need. Other way around: adding redirection to already working > > > (and a bit sophisticated) gateway I set up appears to be beyond my mental > > > abilities: a couple of weeks of frustration confirm it to me. > > > > > > I really do not want to go back to Linux to do this, even though I feel I > > > can do it based on Linux in a course of an hour or two - I've set up a few > > > of them in the past using Linux, that's the longest it took me in my > > > recollection. > > > > > > Thanks in advance for all your answers and pointers! > > > > > > Valeri > > > this CAN be done but it gets tricky. > > > > usually we do NAT on the external interface. the trouble is that you don't > > want that traffic to go through the external interface, but to get routed > > back in. > > Well if it's internal address to another internal address, if on the > same switch it may not need to even hit the router, and if on another > segment, the router will naturally route it internally anyway, as long > as you make sure you DON't perform NAT on those packets, neither from > client to (internal) server destination, nor on responses in return. > > > you really should add a special rule group that traps the packets as they > > come in on the internal interface and send them to nat if they are destined > > for the other internal machine. (and the return packets). > > Yes, but don't you rather mean only send them to nat if they are NOT > destined for the other (here server) internal machine/s? > > > I have never done this so when you work it out let us know :-) > > Paraphrasing an old maxim of yours, "Don't send packets to NAT that it > doesn't care about", ie don't gratuitously NAT every packet out from the > internal machines, unless they're definitely bound for the outside, > which can readily be done with something like, for outbound NAT: wow someone listened to something I said! :-) > > add skipto $pastnatrule ip4 from $server:$port to $internalnet out > add $natrule nat N ip4 from any to any out xmit $extif recv $intif > > whereby outbound packets are only NAT'd if routed to the $extif > (and in fact, on that basis, the first rule is likely redundant) > > Of course the ACLs for the internal server:port need to accept packets > from the internal network, and return packets sent by that server also > need to NOT do NAT on the way out, again best to specifically skip NAT > for packets clearly destined for the LAN, as above. I have done this. > > DNS may be an issue; if you need internal clients to be able to access > the internal, normally redirected address:port by its externally-known > name, eg www.myserver.net:port/ then you could use split DNS, like bind > views. If you don't control DNS, LAN clients may instead need an entry > in /etc/hosts, which may or may not be inconvenient, depending on scale. > > That said, I'n mot really sure I'm addressing the correct problem :) > > cheers, Ian I Believe the problem is as follows: there are two machines inside the NAT'd lan, A and B, (local addresses) . The NAT machine is X on the outside and Y on the inside. B is also visible to the outside world as the Nat'd address C (which may or may not be the same as X). A wants to be able to send a request to address C and have it bounce back to B, (with a source address of Y). The reply to Y should in turn be bounced back to A. This is quite complicated and while I am sure we could work out how it should be done I can't just rattle off an answer. It probably requires two instances of NAT a regular NAT on the external interface, and a reverse nat on the inside interface, triggering on outgoing packets. turning them around