From owner-freebsd-net@FreeBSD.ORG Sat Jul 6 07:47:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5056991D; Sat, 6 Jul 2013 07:47:34 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1C31C56; Sat, 6 Jul 2013 07:47:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x11so2592678pdj.15 for ; Sat, 06 Jul 2013 00:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RI6yuqpvL3VTKhUkJaBcVu5ksaTSNsg8meWPuD3YTpg=; b=MIMXednR4oXN3d4qKFDe5aMdDDfsMEQusruaOfXa+wpC02soDPbF7shMcOF0jfY8zx 6X7YobpLCq/HZGHjrvCynlQAGGACaClbJtljgndYbXcGHCK9J4AhuFsi09qXi0RkcPIH Uvph1CrkWMWk3EHlYIsm2rcV4WdbLDHmVj6dM7lID9jKxWjc403i6OBHfTEurNPz2OZ3 cjfG2dPXvCdIraOZTuOssgI0McxYp/Edyhuq94cjScnE9SqoUIDcQhfMHFrm4wNjFH1b lMr4p50CQY4NpmDWZ5okB5oxQd9tr3oeB0+fMDbqkrBYdTI7OgluSjdWYQ4wd/GWaaN9 lBIg== MIME-Version: 1.0 X-Received: by 10.68.169.97 with SMTP id ad1mr12582108pbc.84.1373096853465; Sat, 06 Jul 2013 00:47:33 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Sat, 6 Jul 2013 00:47:33 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Sat, 6 Jul 2013 00:47:33 -0700 (PDT) In-Reply-To: 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> <51D3A35C.8070305@freebsd.org> Date: Sat, 6 Jul 2013 10:47:33 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Eugene Grosbein , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 07:47:34 -0000 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" : > 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 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 " >>> 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 >