problem with setting nat

[olli hauer]

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