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 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.
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
>
>> 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
>> 192.168.0.1 is me, my neighbour is 192.168.0.2.
>
> So you are supplying your neighbour with internet access?
>
>> I want to make that any connection comes to 192.168.0.1 to go to ip
>> 193.xxx.yyy.2 using specific public ip 84.xx.yy.1
>
> comes to 192.168.0.1 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 192.168.0.1?
>
> 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 192.168.0.1 and sent to 192.168.0.2/or 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 192.168.0.1|-----|192.168.0.2
> | |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 10.0.1.1 from 10.0.1.2, so packet is 10.0.1.2 ->10.0.1.1
>>>> ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1
>>> if I have 10.0.1.1 in em1 no translation is done!
>>> if I delete it (and add a static arp entry in 10.0.1.2 for mac of
>>> 10.0.1.1)
>>> rule 1000 translates well and I get packet from 11.0.3.1->10.0.1.1
>>>
>>>> ipfw add 2000 nat 2 all from 11.0.3.1 to 10.0.1.1
>>> no translation is done at all!
>>>
>>> Sami
>>>
>>>> ipfw add 3000 nat 2 all from 11.0.4.2 to 11.0.3.1
>>>> ipfw add 4000 nat 1 all from 10.0.1.1 to 11.0.3.1
>>>>
>>>>
>>>> ipfw nat 1 config same_ports ureg_only ip 11.0.3.1
>>>> ipfw nat 1 config reverse same_ports ureg_only ip 11.0.4.2
>>>
>>>
>>> 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