DNAT in freebsd

Julian Elischer julian at freebsd.org
Wed Jul 3 03:59:49 UTC 2013

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 
(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 

NAT_ACTION is either "nat 1" or "divert ${INTERNAL_DIVER_PORT}

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} 

and the nat must be set up to leave unmapped packets alone.
so deny_incoming must NOT be set in the NAT configuration.

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 
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....


>> Here is the situation i want to handle:
>> My box is a router that handles several /24 behind.
>> One of my links (em0) is connected to a private network
>> is me, my neighbour is
> So you are supplying your neighbour with internet access?
>> I want to make that any connection comes to  to go to ip
>> 193.xxx.yyy.2 using specific public ip 84.xx.yy.1
> comes to from where? from your neighbour?
> Do you want to intercept all his packets that arrive at
> that interface or just packets that are addressed to
> Where is 193.xxx.yyy.2?  On one of your networks, or out on the 
> internet?
> IS it the interface marked "D" in the diagram below? or at [Q]?
> what is it? a proxy cache?
> Where is  84.xx.yy.1? Is it your interface "A" in the diagram below?
> (I assume so)
> By "using", do you mean that they
> arrive at 193.xxx.yyy.2 with a rewritten source address of 84.xx.yy.1
> or that they think they are going TO 84.xx.yy.1? Where do you want the
> reply packets to go, and what should they look like?
> By "go to" do you mean a rewritten destination address of 
> 193.xxx.yyy.2,
> or just routed to it with the original destination address untouched?
>> And packets coming to my public 84.xx.yy.1 ip to be trsnslated as came
>> from and sent to ant other ips
>> behind(192.168.1.xx/24).
> ALL packets that arrive at 84.xx.yy.1 or just some?
>> Hope that makes it clearer, and I appreciate any help.
> so let's draw a picture of what I think we know..
> ----------- [a]  ------------------------- [b] -------------
> internet B|------|84.xx.yy.1|-----|
>           |      |A   C            D     |     | neighbour
> -----------      -------------------------     --------------
>     |                 |            |
>    [Q]                |            |
>                 your networks      ?
> I think we know what normal packets at [a] and [b] look like
> but we still need to know what 'changed' packets want to look like.
>> Sami
>> בתאריך 1 ביול 2013 14:16, מאת "Sami Halabi" <sodynet1 at gmail.com>:
>>> Hi,
>>> I did ping from, so packet is ->
>>>> ipfw add 1000 nat 1 all from to
>>> if I have in em1 no translation is done!
>>> if I delete it (and add a static arp entry in for mac of
>>> rule 1000 translates well and I get packet from>
>>>> ipfw add 2000 nat 2 all from to
>>> no translation is done at all!
>>> Sami
>>>> ipfw add 3000 nat 2 all from to
>>>> ipfw add 4000 nat 1 all from to
>>>> ipfw nat 1 config same_ports ureg_only ip
>>>> ipfw nat 1 config reverse same_ports ureg_only ip
>>> On Mon, Jul 1, 2013 at 1:42 PM, Eugene Grosbein 
>>> <eugen at grosbein.net>wrote:
>>>> On 01.07.2013 17:05, Sami Halabi wrote:
>>>>> Hi,
>>>>> forgot to mention that but this sysctl is already set to 0.
>>>>> i see in the logs packets pass 1000 rule.
>>>> Use rules like 'ipfw add 1500 count log ip from any to any' to check
>>>> intermediate results of translation.
>>> -- 
>>> Sami Halabi
>>> Information Systems Engineer
>>> NMS Projects Expert
>>> FreeBSD SysAdmin Expert
>> _______________________________________________
>> freebsd-ipfw at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to 
>> "freebsd-ipfw-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"

More information about the freebsd-net mailing list