DNAT in freebsd

Sami Halabi sodynet1 at gmail.com
Wed Jul 3 11:06:33 UTC 2013

Hi Julian,

I appreciate your willing to help me.

My Situation in short is:

----------- [a]     ------------------------- [b] -------------
internet B |---BGP---|84.xx.yy.1|-----|
193.xx.yy.2|         |Aem1   Cem3      D  em0|  |  | neighbour
-----------         -------------------------   | --------------
    |                         |                 |
   [Q]                        |                 |
                        your networks        private network

I Have control only over the middle machine, so i cant establish a tunnel.
So I want it to act as MAN IN THE MIDDLE/ proxy.
every packet comes from private network to ie:
packet hdr: src: dst
should be translated as:
packet hdr: src: 84.xx.yy.1 dst 193.xx.yy.2
ports and data untouched.

and every packet from 193.xx.yy.2 (incoming/setup...) as:
packet hdr: src: 193.xx.yy.2 dst: 84.xx.yy.1
to be translated as:
packet hdr: src: dst

btw: any other packet from src other than 193.xx.yy.2  to dst 84.xx.yy.1
should be dropped.

Again thanks for you help, I hope I supplied all the info needed to help me.

On Wed, Jul 3, 2013 at 7:06 AM, Julian Elischer <julian at freebsd.org> wrote:

> 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 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:  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
>> 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 <>"
>> 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
>> 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

Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert

More information about the freebsd-net mailing list