Hi,
Any hope?
Thanks in advance,
Sami
בתאריך 3 ביול 2013 14:06, מאת "Sami Halabi" <sodyn...@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 <jul...@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
>
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
