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
_______________________________________________
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"
