From owner-freebsd-pf@FreeBSD.ORG Tue Aug 23 09:49:18 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 795CB1065672 for ; Tue, 23 Aug 2011 09:49:18 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7A08FC12 for ; Tue, 23 Aug 2011 09:49:18 +0000 (UTC) Received: by ywo32 with SMTP id 32so4625837ywo.13 for ; Tue, 23 Aug 2011 02:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jxYVOlMh/5z+iRiEXlWSyVhdZBEPdPjdBEBSIZIFNIc=; b=vuWL22K7ExhRA7sSoBx4nkq2GYC0aL7h/n5Dl6+8PKILcWx05rpL/7eq+5VvJCGAGY MulutRL7CCMFhn/P8MsOEHPVqaKYMMOqwiaYtWC1DvMaTVyGTxJeYl/WIvydA03Jrm6x MeTbKS+t2Py7dBTnrscxfZpxWWTRcFJ2V5Rlo= Received: by 10.142.13.3 with SMTP id 3mr44647wfm.19.1314092956981; Tue, 23 Aug 2011 02:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.30 with HTTP; Tue, 23 Aug 2011 02:48:55 -0700 (PDT) In-Reply-To: <4E5369DA.1030303@gmail.com> References: <4E510AF8.9090009@gmx.de> <4E533FB4.5050403@gmx.de> <4E5369DA.1030303@gmail.com> From: Sara Khanchi Date: Tue, 23 Aug 2011 14:18:55 +0430 Message-ID: To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: problem with setting nat X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 09:49:18 -0000 Sara Khanchi On Tue, Aug 23, 2011 at 1:20 PM, Bartek W. aka Mastier wrote: > W dniu 23.08.2011 08:36, Sara Khanchi pisze: > >> On Tue, Aug 23, 2011 at 10:20 AM, olli hauer wrote: >> >> On 2011-08-23 07:10, Sara Khanchi wrote: >>> >>>> On Sun, Aug 21, 2011 at 6:11 PM, olli hauer wrote: >>>> >>>> On 2011-08-21 09:48, h bagade wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am trying to use pf nat rules with pool support on FreeBsd 8.0, >>>>>> >>>>> working >>> >>>> together with ipfw as the main firewall. According to the natting >>>>>> >>>>> concepts i >>>>> >>>>>> faced in manuals and docs, nat concept is to map the source address to >>>>>> >>>>> the >>>>> >>>>>> natted address when sending the packets from that source and then map >>>>>> >>>>> the >>> >>>> destination address of the related reply packets. >>>>>> >>>>>> but when I define pf nat rules with a pool of IP addresses not >>>>>> >>>>> available >>> >>>> on >>>>> >>>>>> the outside interface ip addresses, the outgoing traffic is natted to >>>>>> >>>>> one >>> >>>> of >>>>> >>>>>> the pool addresses but the response is not received via that interface >>>>>> >>>>> so >>> >>>> the pf can map the destination address to the real one. here is one of >>>>>> >>>>> my >>> >>>> configs i used during my tests: >>>>>> >>>>>> *configurations:* >>>>>> *pf.conf:* >>>>>> nat on eth1 from { 11.11.11.0/24} to any -> >>>>>> {172.16.10.1,172.16.10.2,172. >>>>>> >>>>>> 16.10.3,172.16.10.4,172.16.10.**5,172.16.10.6,172.16.10.7,172.** >>> 16.10.8,172.16.10.9,172.16.10.**10} >>> >>>> main system configurations: >>>>>> eth0: 11.11.11.1 >>>>>> eth1: 172.16.10.64 >>>>>> >>>>>> system A: directly connected to eth0- 11.11.11.11 >>>>>> system B: directly connected to eth1- 172.16.10.65 >>>>>> >>>>>> in this configs the dafult route of system A and system B are the >>>>>> >>>>> middle >>> >>>> systems connected ip address. >>>>>> >>>>>> as mentioned, when systemA pings systemB, the ping requests are natted >>>>>> >>>>> to >>> >>>> 172.16.10.1 and received at systemB but systemB doesn't send icmp >>>>>> >>>>> replies >>> >>>> because it doesn't know to whom it should send the replies (no answer >>>>>> >>>>> to >>> >>>> system B 's ARP requests about who has the natted IP). >>>>>> >>>>>> now my question is, isn't it the pf nat responsibilty to manage this >>>>>> condition and send the ARP replies to SystemB? >>>>>> or, are my configs wrong? >>>>>> or i misunderstood the nat concepts? >>>>>> >>>>>> any ideas or helps are really appreciated as i have to set this nat on >>>>>> >>>>> my >>> >>>> main system, asap. >>>>>> Thanks in advance. >>>>>> >>>>> >>>>> Nothing magic, >>>>> >>>>> Professional Firefall products do offer mostly to create an automatic >>>>> proxy arp or do this without your notice. >>>>> >>>>> The better way is to create a route on the upstream router, this way >>>>> you get all the traffic without silly arp broadcasts. >>>>> >>>>> The following route on the peer should solve your problem >>>>> route add -net 172.16.10.1 gw 172.16.10.65 netmask 255.255.255.192 >>>>> >>>>> >>>>> >>>>> Defining route is not a proper way to handle this situation. I want to >>>> >>> setup >>> >>>> a nat router which every one works with it without need to adjust >>>> >>> additional >>> >>>> configurations on their system and works as the way cisco does. >>>> what should be done exactly to simulate cisco? Is there any way to proxy >>>> arp? Does ipfw support proxy arp? >>>> >>> >>> Hi Sara, >>> >>> ipfw even does not do proxy arp. >>> >>> If I read your top right it looks like this >>> >>> lan(11.11.11.0/24) --|switch|-- |(.??) gw (.65)| --|switch|-- >>> upstream(172.16.10.x/xx) >>> >>> Even with cisco as gw or router I place a static route to the upstream or >>> if can not control the upstream device to the switch between gw and >>> upstream. >>> I think last time I used proxy arp is now 10 years ago, reason I'm not >>> target for arp spoofing on this site of my equipment. >>> Think about the case where you route some public class C networks then >>> arp >>> is really unproductive. >>> >>> -- >>> olli >>> >>> The topology is like this: >> >> lan(11.11.11.0/24) --|switch|-- |(.1) gw (.64)| --|switch|-- >> upstream(172.16.10.x/16) >> nat pool address: 172.16.10.1-172.16.10.63 >> nat pool address is on the same network of upstream device. >> >> May be I don't understand you well. in your first post you've mentioned >> that >> I should define an static route on upstream device so it would send >> packets >> destined for natted address to the gw. In this post you've talked about >> defining static route on gw to the upstream? could you explain me more >> about >> your suggestion of using static routes instead of proxy-arp solution? >> >> however, in the above topology, there is no need to define a static route >> on >> upstream device (they are on the same network) in normal condition so it >> should be applicable when nat is used on gw, right? what's the solution >> then? >> ______________________________**_________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**freebsd.org >> " >> > I completely don't see the point of using arp-proxy at all. Can you enlight > me ? You need to connect two networks, also is there any point of using nat > also ? Instead of just to route traffic between them, unless one of them is > Internet or some MAN/WAN network. > > As Olli mentioned, you need to add route if you don't want put nat address > on the interface. I don't know any ARP proxy software for freebsd, because > I've never used. So, ok, if Olli was that kind to clear things out, seems to > have better experience in that matters. > > Btw. Sara, please, possibly use "Answer in list" instead of "Answer to me > with Cc to list" in your mail client :-) Or just send back to > freebsd-pf@freebsd.org. Thanks. > > > reebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**freebsd.org > " > > ______________________________**_________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**freebsd.org > " > I've just put an example in previous post to clarify my purpose. The gw system in the sample, is possibly a stub router connects a network to lets say, internet. What I actually want to figure out is that when I define nat on the stub router, without any need to define static routes on other systems, would it be possible to get nat works properly as what happens in cisco stub router using nat? According what is discussed here, I believe the only way is to use arp-proxy for the pool addresses. In this way, there is no difference for other systems that stub router is using nat or not? It's the duty of nat router to handle the consequences of natting (reply to responses to the natted addresses that are not available really). I think may be adding entries to arp table using arp command do the proxy-arping. As I understand and not sure my understanding is correct, Olli suggests to define static routes on upstream router to send packets destined for pool addresses to the gw. In this scenario, the nat process is not transparent any more and the upstream system should be aware of it and supports it by adding static routes which is undesirable. p.s. I've used the "reply all" button in gmail and it sets the to and cc fields itself. sorry if this bothers you. I will take care of it :)