Date: Mon, 22 Feb 2016 23:06:00 -0800 From: Julian Elischer <julian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: galtsev@kicp.uchicago.edu, freebsd-net@freebsd.org Subject: Re: gateway machine port redirect question Message-ID: <56CC04D8.6060206@freebsd.org> In-Reply-To: <20160222175549.L51785@sola.nimnet.asn.au> References: <43887.128.135.52.6.1456021321.squirrel@cosmo.uchicago.edu> <56CA5519.4080000@freebsd.org> <20160222175549.L51785@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56CC04D8.6060206>