Date: Wed, 3 Jul 2013 14:06:32 +0300 From: Sami Halabi <sodynet1@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-ipfw <freebsd-ipfw@freebsd.org>, Eugene Grosbein <eugen@grosbein.net>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: DNAT in freebsd Message-ID: <CAEW%2BogY8A3javUR=g5pP5iqa3yYfEToHuRg0J-ihnV8EV2U9SA@mail.gmail.com> In-Reply-To: <51D3A35C.8070305@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> <51D3A35C.8070305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julian,
I appreciate your willing to help me.
My Situation in short is:
----------- [a] ------------------------- [b] -------------
internet B |---BGP---|84.xx.yy.1 192.168.0.1|-----|192.168.0.2/24
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 192.168.0.1 ie:
packet hdr: src: 192.168.0.2 dst 192.168.0.1
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: 192.168.0.1 dst 192.168.0.2
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.
Sami
On Wed, Jul 3, 2013 at 7:06 AM, Julian Elischer <julian@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 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 <http://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
>>
>>
>>
>>
>>
>
--
Sami Halabi
Information Systems Engineer
NMS Projects Expert
FreeBSD SysAdmin Expert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEW%2BogY8A3javUR=g5pP5iqa3yYfEToHuRg0J-ihnV8EV2U9SA>