problem with setting nat
Bartek W. aka Mastier
mistrzipan at gmail.com
Sun Aug 21 11:21:26 UTC 2011
W dniu 21.08.2011 12:10, Sara Khanchi pisze:
> 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?
>
Actually, I'm more familiar with *BSD and Linux system. AFAIK, Cisco
makes some magic (which is IMHO weird), like binding to listen to
address not attached to any interface, and the rest works as I
specified. I think it should be the address on the interface, because it
breaks network integrity. Imagine that some one puts a machine in
network with that address, because of not knowing that nat machines
replies on that address (maybe not, maybe only replies when the packet
is coming back in stateful firewall).
Now I do understand your situation. Actually I don't see any point in
giving the pool of nat addresses. Maybe for ISP it is convenient if
their clients are behind nat, and some of them messed something up and
address is locked down for sending spam etc. Then it might be excluded
from nat pool, which is cool. In my experience as a sysadmin, I suspect
it might be nice feature.
I haven't heard of convenient handling nat pool in *bsd and linux, sorry
:-) Maybe someone else will give you some tips. I would like to also
learn something from it.
>
> On Sun, Aug 21, 2011 at 1:39 PM, Bartek W. aka Mastier
> <mistrzipan at gmail.com <mailto:mistrzipan at 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 <http://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
> <http://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 at freebsd.org <mailto:freebsd-pf at freebsd.org> mailing
> list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to
> "freebsd-pf-unsubscribe at freebsd.org
> <mailto:freebsd-pf-unsubscribe at freebsd.org>"
>
>
> _______________________________________________
> freebsd-pf at freebsd.org <mailto:freebsd-pf at freebsd.org> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to
> "freebsd-pf-unsubscribe at freebsd.org
> <mailto:freebsd-pf-unsubscribe at freebsd.org>"
>
>
More information about the freebsd-pf
mailing list