From owner-freebsd-net@FreeBSD.ORG Wed Jul 3 11:06:33 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 22937482; Wed, 3 Jul 2013 11:06:33 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id E18091DE2; Wed, 3 Jul 2013 11:06:32 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id 10so4541251pdc.33 for ; Wed, 03 Jul 2013 04:06:32 -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=8NAoVxZicruPIWNq47O7qvhtyQTDBA3c+i5Hnl7aP/Y=; b=vClhI67/novkjRPrieIre61mqK3BzLbwfv7EukBV/c1lRL4C+ZDxa23uDPqmbwFyz5 iTFEidLzC6ECb0r2IlXAJytux6AXRurRq/CqMe+3UbuJAh6S6QccWJSNpgiMpK5uNrD6 Ls27Ex7Eug47JqQK4kWO8A7JYJ5Eni7E1DfUCaccTgAIOHwMP+mu52CJz0ERrvY2KgoJ dqi6bNJY7FC9AbV6FxA2WvheyxwbDLVhaL8tWtJDUG6MveY1nUEKp+DKL8tz5iNEhaEs mJu/vqNJYxox/bkZy2rMP6j6ySs8rIGrOmqArqwpZwjMTyv5xNlY9NXdG1TwQ5q5i1qG cFtA== MIME-Version: 1.0 X-Received: by 10.68.171.99 with SMTP id at3mr369438pbc.64.1372849592649; Wed, 03 Jul 2013 04:06:32 -0700 (PDT) Received: by 10.70.71.7 with HTTP; Wed, 3 Jul 2013 04:06:32 -0700 (PDT) In-Reply-To: <51D3A35C.8070305@freebsd.org> 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: Wed, 3 Jul 2013 14:06:32 +0300 Message-ID: Subject: Re: DNAT in freebsd From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw , Eugene Grosbein , "freebsd-net@freebsd.org" 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: Wed, 03 Jul 2013 11:06:33 -0000 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 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 >> >> >> >> >> > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert