gateway machine port redirect question

[Julian Elischer]

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