Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

PIX Natting problem

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
Cisco Employee

Re: PIX Natting problem

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.

1 REPLY
Cisco Employee

Re: PIX Natting problem

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.

111
Views
0
Helpful
1
Replies