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