From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 3 04:07:03 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D60DB254; Wed, 3 Jul 2013 04:07:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4301A2D; Wed, 3 Jul 2013 04:07:03 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r6346wPI084737 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 21:07:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D3A35C.8070305@freebsd.org> Date: Wed, 03 Jul 2013 12:06:52 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> In-Reply-To: <51D3A1A0.8090904@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw , Eugene Grosbein , freebsd-net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:07:03 -0000 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 > > > >