Date: Wed, 24 Aug 2011 13:43:39 +0430 From: Sara Khanchi <s.khanchi@gmail.com> To: freebsd-pf@freebsd.org Subject: Re: problem with setting nat Message-ID: <CAARSjE2%2BmJSC4h016Xs6cOBF1b3MfGdSwX13nY6i=D_S1kB5xw@mail.gmail.com> In-Reply-To: <4E537FB6.7000100@gmail.com> References: <CAARSjE09vm3yvevBhhdK_6XrRpnKD5cwgnZJPVjVTsH=03JCsg@mail.gmail.com> <4E510AF8.9090009@gmx.de> <CAARSjE2uxqzqr97Y1w%2B0tf5B0ZaMFHTRXRMMCoWwjvfVz67_%2Bg@mail.gmail.com> <4E533FB4.5050403@gmx.de> <CAARSjE31vX4NW80nsHgaTBFD84YoOYL=shPY_3oUNkVBCvGxbA@mail.gmail.com> <4E5369DA.1030303@gmail.com> <CAARSjE3U4vAS4L88r%2BEiaFSwNu8JudDWvqD1c1A4X0%2BEwXYfZA@mail.gmail.com> <4E537FB6.7000100@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 23, 2011 at 2:53 PM, Bartek W. aka Mastier <mistrzipan@gmail.com > wrote: > W dniu 23.08.2011 11:48, Sara Khanchi pisze: > >> 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<http://lists.freebsd.org/**mailman/listinfo/freebsd-pf>; >>>> <ht**tp://lists.freebsd.org/**mailman/listinfo/freebsd-pf<http://lists.freebsd.org/mailman/listinfo/freebsd-pf>; >>>> > >>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**free** >>>> bsd.org <http://freebsd.org><freebsd-pf-**unsubscribe@freebsd.org<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<http://lists.freebsd.org/**mailman/listinfo/freebsd-pf>; >>> <ht**tp://lists.freebsd.org/**mailman/listinfo/freebsd-pf<http://lists.freebsd.org/mailman/listinfo/freebsd-pf>; >>> > >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**free**bsd.org<http://freebsd.org>; >>> <freebsd-pf-**unsubscribe@freebsd.org<freebsd-pf-unsubscribe@freebsd.org> >>> > >>> >>> " >>> >>> ______________________________****_________________ >>> freebsd-pf@freebsd.org mailing list >>> http://lists.freebsd.org/****mailman/listinfo/freebsd-pf<http://lists.freebsd.org/**mailman/listinfo/freebsd-pf>; >>> <ht**tp://lists.freebsd.org/**mailman/listinfo/freebsd-pf<http://lists.freebsd.org/mailman/listinfo/freebsd-pf>; >>> > >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**free**bsd.org<http://freebsd.org>; >>> <freebsd-pf-**unsubscribe@freebsd.org<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? >> > > it seems that automatically makes arp proxy. But this is.. an extra. > Actually not necesarry, unless you badly want arping everyone and L2 access > between networks. Cisco is sooo pro. Don't be surprised that opensource word > doesn't have "out-of-the box features", which are provided by Cisco, to be > "more pro". > > > 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. >> > > if host ask for reverse arp, like, ok I got in my arp table address > xx:xx:xx:xx:xx:xx (hex symbols only ;) ). It came from different network, > but, I still got because there was some arp proxy magic. If not, the packet > got IP address from the right host and MAC from gateway. What a big deal ? > This is how it works. > For a purpose of network scanning/monitoring between two networks, of > course, arp proxy would be helpful, because in other way, you cannot > definitely say that host is on/off. But for that reason ICMP protocol was > created to make the hosts respond on layer 3. If hosts does not respond to > echo request, the nearest gateway/router can send ICMP packet back > "Destination host unreachable". Depending on router firewall behaviour. > For example, some "strange network operator", set static arp of router > (79.110.195.x ) for unused IP, here is the example. What happens then: > > $ ping 79.110.199.y > PING 79.110.199.y (79.110.199.y) 56(84) bytes of data. > From 79.110.195.x icmp_seq=1 Time to live exceeded > From 79.110.195.x icmp_seq=2 Time to live exceeded > From 79.110.195.x icmp_seq=3 Time to live exceeded > From 79.110.195.x icmp_seq=4 Time to live exceeded > > The packets are looped on router until TTL falls down to zero. > > It's a good point you mentioned. Lets go ahead through a scenario:) again the previous config: lan(11.11.11.0/24) --|switch|-- |(.1) stub-router (.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. the nat is defined on the stub-router with the arp-proxy for nat pool addresses (172.16.10.1-172.16.10.63). when the system inside (11.11.11.11) is pingging the system outside (172.16.10.65), the icmp packets are natted (172.16.10.1). In reply packets are send to (172.16.10.64) due to arp-proxy settings. My question here is that are the reply icmp packets received on stub router interface natted in reverse and receive on host (11.11.11.11)? or as you said they are responded "Destination host unreachable" by the stub router? > > 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. >> > > I don't think so, why NAT *must* be transparent ? Look at the Internet, how > do you know that some public IP address either PI or PA is gateway or the > leaf on the network tree. Unless you own/manage both sides of nat you make > them behave the most desired way. > > What I mean is that in the specific scenario discussed, it is not wise to define static route to the natted pool addresses (172.16.10.1-172.16.10.63) since they are on the same network of upstream router (172.16.10.65)! It could be done transparently so the stub router could respond as the non-available host and sends the packets to the original host after do the reverse nat. Isn't that true? In nat scenarios other than the discussed one (the nat pool address is on the same network of upstream), there should be defined static routes to reach the nat pool addresses with the gateway of stub-router. So when the packets reach the stub-router, they will be reverse natted and there is no problem. But when the nat pool address is on the same network of the upstream, the problem arises that upstream router is not sending reply packets to the stub router. In that case, packet replies never received on stub router to get natted in reverse which I think would be solved by proxy-arping. > > >> 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 :) >> > In mailing list, you just use answer, because everyone will get it, because > mailing list software will "spread the word" through all subscribed :-) I > don't use gmail webclient on daily basis, but I assumed that clicking > "Answer" to mail like mein now will add the "freebsd-pf@freebsd.org" > address (only!) as a receiver straight away. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAARSjE2%2BmJSC4h016Xs6cOBF1b3MfGdSwX13nY6i=D_S1kB5xw>