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
<[email protected] <mailto:[email protected]>> 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.
_______________________________________________
[email protected] <mailto:[email protected]> mailing
list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"[email protected]
<mailto:[email protected]>"
_______________________________________________
[email protected] <mailto:[email protected]> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"[email protected]
<mailto:[email protected]>"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[email protected]"
