PIX Internet destined traffic not being NAT'd properly

[jkrawczyk]

Hello All;

I’m having a problem on my PIX 525 firewall. I made a change, which entails the addition of a VPN to a business partner. This tunnel came up fine, but I’ve found that after this change, all of my users on my LAN in segment 198.177.132.0/24 can no longer access the Internet. Users in my 172.31.10.0/24 VLAN have no problem. Strange, if I clear the XLATE tables, the affected users can access the Internet. However, after 10 minutes or so, I need to clear the XLATE tables once again.

If I do a show xlate, the mapping of these clients are translated to 172.31.8.128/25 addresses, thus these addresses are not Internet routable. What I’m trying to figure out is why are my inside addresses being translated improperly!

I’ve checked, rechecked, and re-rechecked my access lists, lost sleep, and are now here pushing my problem out to this discussion forum, in hope of finding a solution.

Your input is appreciated.

Here is a partial of my config.

object-group network SCRANTON

description SCRANTON internal IP range

network-object 198.177.132.0 255.255.255.0

network-object 172.31.10.0 255.255.255.0

network-object 172.31.8.128 255.255.255.128

object-group network COAL

description COAL addresses

network-object 10.138.0.0 255.255.0.0

network-object 10.139.3.0 255.255.255.0

network-object 168.161.0.0 255.255.0.0

object-group network HOOTERVILLE

description Green Acers CSR IP Range accessing PBS-BOM

network-object 10.139.131.0 255.255.255.0

object-group network CSIPBS

description PBS Server in CSI

network-object 166.228.21.21 255.255.255.255

object-group network XLATECSI

description Translated IP for access to CSI

network-object 63.110.75.195 255.255.255.255

object-group service CLIENTACCESS tcp

description AS400 Session ports

port-object eq telnet

port-object eq 446

port-object eq 449

port-object range 8470 8476

access-list GRESCR permit gre host 172.31.11.254 host 172.31.51.254

access-list GREHOO permit gre host 172.31.11.254 host 172.31.15.254

access-list GRETER permit gre host 172.31.11.254 host 172.31.75.254

access-list NONAT permit ip host 172.31.11.254 host 172.31.51.254

access-list NONAT permit ip host 172.31.11.254 host 172.31.15.254

access-list NONAT permit ip host 172.31.11.254 host 172.31.75.254

access-list NONAT permit ip 172.31.10.0 255.255.255.0 10.138.0.0 255.255.0.0

access-list NONAT permit ip 172.31.10.0 255.255.255.0 168.161.0.0 255.255.0.0

access-list NONAT permit ip 172.31.10.0 255.255.255.0 10.139.3.0 255.255.255.0

access-list BURBANK permit ip object-group SCRANTON object-group COAL

access-list TOUCHPOOL remark condition to perform NAT to COAL

access-list TOUCHPOOL permit ip object-group SCRANTON object-group COAL

access-list OUTSIDE_IN permit tcp object-group CSIPBS object-group CLIENTACCESS object-group XLATECSI

access-list XLATECSI remark Mark for NAT to CSI

access-list XLATECSI permit ip object-group SCRANTON object-group CSIPBS

access-list XLATECSI permit ip object-group HOOTERVILLE object-group CSIPBS

access-list IPSECCSI remark Mark Sensitive to CSI PBS AS400

access-list IPSECCSI permit ip object-group XLATECSI object-group CSIPBS

global (outside) 20 172.31.8.129-172.31.8.190 netmask 255.255.255.128

global (outside) 25 63.110.75.195 netmask 255.255.255.255

global (outside) 30 63.110.75.254

nat (inside) 0 access-list NONAT

nat (inside) 20 access-list TOUCHPOOL 0 0

nat (inside) 25 access-list XLATECSI 0 0

nat (inside) 30 0.0.0.0 0.0.0.0 0 0

[sstudsdahl]

You need to setup a PAT address on your NAT pool 20. Without a PAT address defined on the pool, once the IP addresses in the pool have been used up, additional systems that would get their addresses translated via this pool are unable to. To add a PAT address to this pool just add a single IP address to the global 20 in addition to your subnet. It should look like this when added:

global (outside) 20 172.31.8.129-172.31.8.190 netmask 255.255.255.128

global (outside) 20 172.31.8.191

HTH

Steve

[jkrawczyk]

Hi Steve,

I agree with you. However, the destination could be yahoo.com and the PAT address that I'd expect to see would be a 63.110.75.254 address.

Any ideas?

Kind Regards

Jeff

[sstudsdahl]

The way the NAT is setup, it would be translating the source IP address of your devices on the inside interface of the PIX going to the outside interface. The destination should still be the internet routeable address.

Adding the PAT address to your globabl 20 pool, should eliminate the need to clear the xlate table every ten minutes, but it won't solve the problem you have wiht systems not being able to reach the internet. (I looked closer at the ACL you have applied for the policy NAT that you are doing.)

I did a little more digging and have run across a bug (CSCec63822) in verison 6.3(3) with policy NAT that looks like it could be the cause of your problem. The bug is basically that policy NAT can not coexist with normal NAT. Based upon your configuration commands:

nat (inside) 0 access-list NONAT

nat (inside) 20 access-list TOUCHPOOL 0 0

nat (inside) 25 access-list XLATECSI 0 0

nat (inside) 30 0.0.0.0 0.0.0.0 0 0

The workaround appears to be to define all of your NAT statements using ACL's. The only NAT entry that you would need to change would be the NAT (inside) 30 to use an ACL to match the IP addresses of your inside networks. It also looks like the bug has been resolved in version 6.3(4).

Here is a link to the bug if you want to take a look at it.

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCec63822&cco_product=PIX+Firewall&fset=&swver=&keyw=policy%20NAT&target=&train=

Steve