Date: Wed, 03 Jul 2013 12:06:52 +0800 From: Julian Elischer <julian@freebsd.org> To: Sami Halabi <sodynet1@gmail.com> Cc: freebsd-ipfw <freebsd-ipfw@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>, freebsd-net@freebsd.org Subject: Re: DNAT in freebsd Message-ID: <51D3A35C.8070305@freebsd.org> In-Reply-To: <51D3A1A0.8090904@freebsd.org> References: <CAEW%2BogYp61U2zjicksYekSdfmLLZh5g9QM3GUg4n16ZbudVZtg@mail.gmail.com> <20130629002959.GB20376@nat.myhome> <CAEW%2BogZ=a6LZavOtcb_egNWFQ8bJP0gzP6pc90tu1dcWC9K80A@mail.gmail.com> <51D006F6.6060809@grosbein.net> <CAEW%2Bogbx15KiayBHFJ7T1YVGQ2pwm1ArQaSrjUk6XUOBgVPggA@mail.gmail.com> <51D04FA8.8080900@grosbein.net> <CAEW%2BogZQ1bHOBNvxkLqnFRrR_b4=e%2BYx9wUjWC8YYr__QsBe3w@mail.gmail.com> <CAEW%2BogZmd4Rz7OgTKV-k=tnSLgG0Y0-4XO%2BxuELznsgVo0XZ%2BA@mail.gmail.com> <51D14930.1060502@grosbein.net> <CAEW%2BogYW9YWZr6TnzqZ%2BHv_e_fFo-MKW1hTdWfw7w=qaCFw3Yg@mail.gmail.com> <51D15D06.9030300@grosbein.net> <CAEW%2BogZB9m%2B5FLyB2NXFbp=uSpvCq6fn4SPVZe2W58yQ-S_z4w@mail.gmail.com> <CAEW%2BogYef6esFDkxRefht1z==zdr5bsYv6S-FPgTyZ36GPR_Mg@mail.gmail.com> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51D3A35C.8070305>