Re: Policy NAT and VPN

daniel · ‎01-10-2005

I'm trying to do a site-to-site VPN between a PIX 501 and a VPN Concentrator. PIX internal network is 192.168.1.0/24. Concentrator side is 10.0.0.0/8. Traffic coming from the PIX must be NATed to a different subnet(10.1.1.0/24) before it reaches the Concentrator side. Internet access also needs to function normally while the VPN is being used.

This is where I am running into problems. When a machine on the PIX side connects to a machine on the Concentrator side, VPN traffic works fine. I can look at the xlate table and see the correct mapping with the 192.168.1.X address being translated into a 10.1.1.X address. However as long as that machine is listed in the xlate table, it is no longer able to go on the Internet. I can look at the logs and see the PIX is NATing the machine to a 10.1.1.X address for Internet traffic as well. It's like the ACL on my static policy NAT entry is being ignored. As soon as I clear the xlate table, the machine is able to connect to the Internet normally. What am I doing wrong?

I've included the relevant PIX config snippet below:

access-list VPN-ACL permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.0.0.0

access-list ENCRYPT-ACL permit ip 10.1.1.0 255.255.255.0 10.0.0.0 255.0.0.0

ip address outside dhcp setroute

ip address inside 192.168.1.1 255.255.255.0

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 10.1.1.0 access-list VPN-ACL 0 0

crypto map VPN-MAP 10 match address ENCRYPT-ACL

sachinraja · ‎01-12-2005

Hi,

Can you please configure the following on your PIX and then try ?

nat (inside) 2 access-list IPSEC_TRAFFIC

global (outside) 2 10.1.1.1 - 10.1.1.254 netmask 255.255.255.0

access-list IPSEC_TRAFFIC permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.0.0.0

nat (inside) 3 0.0.0.0 0.0.0.0

global (outside) 3 interface

By doing this, traffic only to the IPSEC destination will be natted. all other traffic will match the nat 3 statement and get natted to the public IP.

hope this helps.. all the best..

raj

daniel · ‎01-12-2005

Thanks for your reply.

Unfortunately your changes had the same effect. As soon as there is a translation in the xlate table from 192.168.1.X to 10.1.1.X the PIX attempts to nat all traffic even Internet through this translation. Clearing the xlate table will allow Internet access to work again. It seems that once there is an active translation present, the PIX ignores any Policy NAT rules.

I also forgot to mention that we are using PIX Version 6.3(3) of the software.

Thanks

Daniel

sachinraja · ‎01-13-2005

Oops. yes. since the nat translation is already present with the old ip, a new translation will not occur, until the old one breaks. we normally do a clear xlate, in case we change any nat rules.

why do u want to nat the traffic for IPSEC ? if only for identification, u can still use the PIX outside NAT IP and use that for IPSEC and identification. Anyway I think the end subnets doesnt overlap, and you can work well without nat.

All the best..

Raj

daniel · ‎01-13-2005

The need for NAT has been dictated to us by the VPN Concentrator side which we have no control over. This is probably done to avoid subnet overlap on a segment of their network we don't see.

Traffic across the VPN will not be one-way. Their side of the network will need access to machines hosted by us. In the original config I posted, this worked great since all traffic from 192.168.1.X was automatically mapped to 10.1.1.X and vice-versa.

So are you saying that by design policy nat is ignored if there is an existing translation in the xlate table that matches the source IP?

Thanks for your help.

Daniel

daniel · ‎01-13-2005

I found the solution. I upgraded the PIX software from 6.3(3) to 6.3(4) and now my originally posted config works great. Must have been a bug.

Thanks for your help.

Daniel

sachinraja · ‎01-13-2005

great daniel.. thats a good info. please mark the post as solved one, so that it will be useful for others.. IOS troubleshooting is a big headache !!!