DNAT in freebsd

[Julian Elischer]

On 7/3/13 11:59 AM, Julian Elischer wrote:
> On 7/3/13 10:47 AM, Julian Elischer wrote:
>> On 7/2/13 10:21 PM, Sami Halabi wrote:
>>> Hi again,
>>> So far no solution....
>>>
>>> Is there really no alternative in FreeBSD?
>>
>> oh I'm sure there are several solutions..
>> I looked at  the original email but have since deleted it..
>>
>> ah archives to the rescue....
>>
>> ok so your request is a bit short on information..
>
> thinking about your request I think what you want to do is to make 
> it look as if you have a web server or something at 192.168.0.1 to 
> your neighbour, but to in fact serve those requests from a machine 
> at 193.xxx.yyy.2. In addition, you need the requests to appear to 
> come from your external address, so that the responses can find 
> their way back to you.
>
> my next question is: Do you control 193.xxx.yyy.2? (is it FreeBSD?)
> because there are several ways you could solve that problem if you 
> do, and it is..
> basically by making a tunnel directly between that machine and you.
>
> if you want to not use a tunnel there are several steps on the way.
> we need to think abut what packets look like at each step.
>
> at em0, incoming
>
> packet A from neighbour, on the wire:
> To: 192.168.0.1  port 80
> From: 192.168.0.x  port MMM0
> we want to change this packet.
>
> packet B from neighbour, on the wire:
> To: www.google.com  port 80
> From: 192.168.0.x  port MMM1
> we want to leave this packet alone (for now)
>
> At this stage, (on the incoming packet A on em0)
> we need to change the DESTINATION address,
> so we need a regular NAT, acting as if it were accepting an incoming 
> connection.
> (which it is).
>
> so from the natd man page, the NAT 'rule' is:
>       redirect_address 193.xxx.yyy.2 192.168.0.1
>
> This must only happen on incoming packets from the neighbour, 
> *addressed to you* so
> ipfw has a rule:
> ipfw add xx ${NAT_ACTION} ip from ${NEIGHBOUR_NET} to 
> ${MY_NIGHBOUR_ADDR} in recv ${MY_NEIGHBOUR_IFACE}
>
> NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT}
> MY_NEIGHBOUR_ADDR="192.168.0.0/24"
> MY_NEIGHBOUR_IFACE="em0"
>
> now you need a rule to match this one for retranslation of return 
> packets
> so  on output you have:
> ipfw add yy ${NAT_ACTION} ip from 193.xxx.yyy.zzz to 
> ${NEIGHBOUR_NET} out xmit ${MY_NEIGHBOUR_IFACE}
>
> and the nat must be set up to leave unmapped packets alone.
> so deny_incoming must NOT be set in the NAT configuration.

I am talking all theoretically here as I don't have such a setup at 
the moment,
and I can't remember if the packet direction is given to natd/ipfw-nat
if so then you MAY need the 'reverse' setting, but I don't guarantee it.

If you use natd you will need  a separae instance, or natd. If you use 
ipfw internal nat
then you must use  a separate nat instance there too.
>
>
>
> so theoretically this is the destination address taken care of (in 
> outgoing packets, source address on incoming packets).
>
> So then you need to take care of the source address of the outgoing 
> packets.
> this takes place on the INTERNET facing interface, and really, it 
> should all be taken care of already if you have NAT enabled and you 
> can ping the internet from the neighbour's net.
>
>
>   hope this helps....
>
> Julian
>
>
>
>