cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
465
Views
0
Helpful
1
Replies

PIX Natting problem

rsubrata
Level 1
Level 1

I have one question regarding the PIX firewall's behavior. Recently, we had two similar cases happened, one with PIXOS 6.1.5 and the other is with PIXOS 6.3.4. The phenomena of the problem is:

There are two global pool and 2 nat corresponding to these 2 pools. One NAT is for the whole inside subnet, and the other nat is controlling certain host for translation, as shown below:

global (tgn) 1 1.1.1.1 netmask 255.255.255.255

global (internet) 2 2.2.2.2 netmask 255.255.255.255

nat (inside) 1 192.168.1.0 255.255.255.0

nat (inside) 2 192.168.1.12 255.255.255.255

nat (inside) 2 192.168.1.15 255.255.255.255

The purpose of these two NAT is to allow only certain hosts be able to access Internet, while all the hosts can access to TGN. However, for those hosts allowed to access to Internet, they can not access to TGN due to no translation being build up and the error message is "305006: portmap translation creation failed". After removing the nat 2, these special hosts can access to TGN, i.e. translation is built up.

Could anyone tell me what is the reason to this problem? Could you also share with me the translation methodology used by PIX firewall? Any fix from Cisco to this issue?

Thanks a lot for your kind explanation!

1 Accepted Solution

Accepted Solutions

gfullage
Cisco Employee
Cisco Employee

This is correct behaviour for what you have configured.

For traffic to flow from a higher to lower security interface, you need a nat/global pair. The pair is designated by the matching number just after the interface name in brackets, in your case you have a "1" pair and a "2" pair. Also remember that nat statements are used on a most-specific match, so when traffic from 192.168.1.12 and .15 is seen on the inside interface, the PIX will ALWAYS choose the specific "nat (inside) 2 192.168.1.1x" statement for them, it does this before even checking the destination interface.

What this means is that if these two hosts try to go to the tgn interface, they need to have a corresponding "global (tgn) 2 ....." statement to pair with their "nat (inside) 2 ..." statement. Because that doesn't exist, they can't go to that subnet.

By removing the two individual nat statements, they then start using the "nat (inside) 1 192.168.1.0" statement because that is the next best match. This does have a corresponding "global (tgn) 1 ..." statement pairing and so traffic can flow correctly.

If you want to keep your config as is, then for these two hosts to also get to the tgn interface they will need the following:

nat (inside) 1 192.168.1.12 255.255.255.255

nat (inside) 1 192.168.1.15 255.255.255.255

If you simply want to allow all traffic from inside to tgn, and have the inside hosts appear as their original IP addresses when on the tgn network, a better way might be to use a static as such:

static (inside,tgn) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

and then you can just have the individual "nat (inside) 2 ...." statements for hosts you want to go to the Internet. Might make your config easier to read, and save you having to add in two nat statements for each host that has Internet access.

View solution in original post

1 Reply 1

gfullage
Cisco Employee
Cisco Employee

This is correct behaviour for what you have configured.

For traffic to flow from a higher to lower security interface, you need a nat/global pair. The pair is designated by the matching number just after the interface name in brackets, in your case you have a "1" pair and a "2" pair. Also remember that nat statements are used on a most-specific match, so when traffic from 192.168.1.12 and .15 is seen on the inside interface, the PIX will ALWAYS choose the specific "nat (inside) 2 192.168.1.1x" statement for them, it does this before even checking the destination interface.

What this means is that if these two hosts try to go to the tgn interface, they need to have a corresponding "global (tgn) 2 ....." statement to pair with their "nat (inside) 2 ..." statement. Because that doesn't exist, they can't go to that subnet.

By removing the two individual nat statements, they then start using the "nat (inside) 1 192.168.1.0" statement because that is the next best match. This does have a corresponding "global (tgn) 1 ..." statement pairing and so traffic can flow correctly.

If you want to keep your config as is, then for these two hosts to also get to the tgn interface they will need the following:

nat (inside) 1 192.168.1.12 255.255.255.255

nat (inside) 1 192.168.1.15 255.255.255.255

If you simply want to allow all traffic from inside to tgn, and have the inside hosts appear as their original IP addresses when on the tgn network, a better way might be to use a static as such:

static (inside,tgn) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

and then you can just have the individual "nat (inside) 2 ...." statements for hosts you want to go to the Internet. Might make your config easier to read, and save you having to add in two nat statements for each host that has Internet access.

Review Cisco Networking for a $25 gift card