Date: Sun, 21 Aug 2011 14:40:29 +0430 From: Sara Khanchi <s.khanchi@gmail.com> To: "Bartek W. aka Mastier" <mistrzipan@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: problem with setting nat Message-ID: <CAARSjE2Z5CnqzRRwR5av7UGyo%2B=EFr_p5yyNta5sVH61_ER9GQ@mail.gmail.com> In-Reply-To: <4E50CB38.1050204@gmail.com> References: <CAARSjE09vm3yvevBhhdK_6XrRpnKD5cwgnZJPVjVTsH=03JCsg@mail.gmail.com> <4E50CB38.1050204@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your detailed response. It solved my questions about how nat
works in pf. Based on your answer the nat pool addresses must be defined on
external interfaces and it is not the responsibility of nat itself to do
these assignments. It seems rational.
what makes me confused and made me to ask the question here, is that in
cisco configuration, there is no ip assigned to external interfaces and just
by defining the pool addresses and defining nat on inside source addresses
to the pool addresses, the nat works fine! I've put a sample of cisco
configs in the following.
*here is the cisco config:*
---------------------------------------------------------------------------
interface GigabitEthernet0/0
ip address 11.11.11.1 255.255.255.0
ip nat inside #inside interface
!
interface GigabitEthernet0/1
ip address 172.16.10.64 255.255.255.0
ip nat outside #outside interface
ip nat pool test 172.16.10.1 172.16.10.63 prefix-length 24 #define the pool
of addresses
ip nat inside source list 7 pool test #apply nat on access-list 7 ip
addresses
!
access-list 7 permit 11.11.11.0 0.0.0.31 #determine which ip addresses
should be natted on the way outside
---------------------------------------------------------------------------
As you see there is no ip assigned in the range 172.16.10.1-172.16.10.63 on
the outside interface but the traffic is natted on the way outside and the
responses are received on GigabitEthernet0/1 and the reverse nat is done.
Do you have any idea what happens in cisco natting process? what should I do
to simulate cisco nat procedure? Should I handle this situation manually
apart from pf nat routine?
On Sun, Aug 21, 2011 at 1:39 PM, Bartek W. aka Mastier <mistrzipan@gmail.com
> wrote:
> W dniu 21.08.2011 09:48, h bagade pisze:
>
> 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).
>>
>
> Man, ok, let's start from the beginning: these are your nat adresses
>
>
> {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}
>
> But none of them is set on your routing/natting system interface, come on
> :-D How can it receive response over link layer (L2) if doesn't have IP
> which is substited to make packets get back to. If you are doing nat to
> 172.16.10.1, you should have 172.16.10.1 on your auxiliary interface , not
> 172.16.10.64. Or propably you could make nat like i.e. .... -> {
> 172.16.10.0/24, ... } , but I have never tried it like that.
>
>
>> now my question is, isn't it the pf nat responsibilty to manage this
>> condition and send the ARP replies to SystemB?
>>
>
> Hell no, ARP replies ? man this is link layer, ARP is from link layer. To
> have ARP response (NOT PING, ping is layer 3, IP layer) both side must share
> the same network, natting can see the ARP from both sides , but systemA and
> SystemB between each other can't.
>
>
> or, are my configs wrong?
>> or i misunderstood the nat concepts?
>>
>
> You should have some reading, there are more than one, so called NAT
> techniques. In PF , in your situation, when packet is going out from systemA
> to systemB, the source address in switched to NAT machine's and , in case of
> port-enabled protocol, like TCP and UDP the random port is choosen and
> waiting for response on that port. When it comes from system B is rightaway
> redirected to systemA. I don't know how it works in ICMP (i.e. ping), it's
> in some way "remembered", who is waiting for response.
>
> any ideas or helps are really appreciated as i have to set this nat on my
>> main system, asap.
>> Thanks in advance.
>> ______________________________**_________________
>> freebsd-pf@freebsd.org mailing list
>> http://lists.freebsd.org/**mailman/listinfo/freebsd-pf<http://lists.freebsd.org/mailman/listinfo/freebsd-pf>;
>> To unsubscribe, send any mail to "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>;
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@**freebsd.org<freebsd-pf-unsubscribe@freebsd.org>
> "
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAARSjE2Z5CnqzRRwR5av7UGyo%2B=EFr_p5yyNta5sVH61_ER9GQ>