Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jul 2013 10:47:33 +0300
From:      Sami Halabi <sodynet1@gmail.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        freebsd-net@freebsd.org, Eugene Grosbein <eugen@grosbein.net>, freebsd-ipfw <freebsd-ipfw@freebsd.org>
Subject:   Re: DNAT in freebsd
Message-ID:  <CAEW%2BogYCU43JdFFUxcUO_tSGupDZUgSC9Y=4n%2Br=AkOBz3dm-g@mail.gmail.com>
In-Reply-To: <CAEW%2BogY8A3javUR=g5pP5iqa3yYfEToHuRg0J-ihnV8EV2U9SA@mail.gmail.com>
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> <CAEW%2BogY8A3javUR=g5pP5iqa3yYfEToHuRg0J-ihnV8EV2U9SA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
Any hope?

Thanks in advance,
Sami
=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 3 =D7=91=D7=99=D7=95=D7=9C 2013 14:06,=
 =D7=9E=D7=90=D7=AA "Sami Halabi" <sodynet1@gmail.com>:

> 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 fro=
m
>>> 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, *addresse=
d
>>> 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=3D"192.168.0.**0/24 <http://192.168.0.0/24>"
>>> MY_NEIGHBOUR_IFACE=3D"em0"
>>>
>>> now you need a rule to match this one for retranslation of return packe=
ts
>>> 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 shoul=
d
>>> all be taken care of already if you have NAT enabled and you can ping t=
he
>>> 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%2BogYCU43JdFFUxcUO_tSGupDZUgSC9Y=4n%2Br=AkOBz3dm-g>