Pix 6.3 to 7.0.5 upgrade - static NAT issue

Unanswered Question
Mar 5th, 2007

Hi,

PIX525 upgrade from 6.3(3) to 7.0.5. Upgrade was successful.

Inside - security 100, 10.1.1.0/24

demo - security 50, 192.168.1.0/24

A server in "demo" segment needs to initiate a connection to a server "Inside".

In 6.3, I was doing like this which was working:

static (inside, demo) 10.1.1.1 10.1.1.1 netmask 255.255.255.255

access-list demo_acl permit tcp any any eq http

access-group demo_acl in interface demo

IN 7.0.5:

nat-control

access-list demo_acl extended permit tcp any any eq http

access-group demo_acl in interface demo

Is it so that in 7.0.5, "static" statement is not required? Because, that is what I am observing. I am able to access the inside server without the static statement.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
vitripat Mon, 03/05/2007 - 16:29

It is not designed to work that way. With nat-control enabled, you do need the static command. Are there any other nat commands, like nat 0 with access-list, or simple nat 0?

Regards,

Vibhor.

yvasanthk Mon, 03/05/2007 - 23:20

Hi Vibhor,

Well, there is a nat 0 applied for the inside..

nat (inside) 0 access-list inside_acl

But, this is only for connections initiated from the inside.

Also, the following config does not work

nat-control

static (inside, demo) 192.168.1.10 10.10.1.12 netmask 255.255.255.255

access-list demo_acl extended permit tcp any any eq http

access-group demo_acl in interface demo

The server on the "demo" segment cannot make connections to the address 192.168.1.10

If I downgrade to 6.3, there is no issue at all. But, I cannot be with 6.3 as I need 100VLANs support that comes with 7.0

suschoud Tue, 03/06/2007 - 06:01

If nat-control is enabled, you must configure a NAT rule before an inside host can communicate with any outside networks. The no nat-control command allows inside hosts to communicate with outside networks without configuring a NAT rule. Only hosts that undergo NAT need to have a NAT rule configured.

Two NAT policies are used to perform address translation on each packet that traverses the security appliance, an inside NAT policy and an outside NAT policy. If the nat-control command is enabled, each inside address must have an inside NAT rule before communication is permitted through the security appliance. Additionally, if outside dynamic NAT is enabled on an interface, each outside address must have an outside NAT rule before communication is permitted through the security appliance.

If the no nat-control command is configured and no NAT policy matches, an address rewrite is not performed and processing continues. The default is NAT control disabled (no nat-control command).

Note: To ensure backward compatibility, the nat-control command is automatically enabled if the startup configuration is six or lower.

Hope this helps!!

Regards,

Sushil

vitripat Tue, 03/06/2007 - 08:03

nat (inside) 0 access-list inside_acl

This works bi-directional. Can you provide the output of "show access-list inside_acl"?

yvasanthk Wed, 03/07/2007 - 01:34

nat-control

nat (inside) 0 access-list inside_acl

nat (inside) 15 10.1.1.20 255.255.255.255

global (demo) 15 192.168.1.20 netmask 255.255.255.255

Here is the "show" output:

access-list inside_acl line 1 extended deny ip host 10.1.1.20 192.168.1.0 255.255.255.0 (hitcnt=0)

access-list inside_acl line 2 extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0 (hitcnt=0)

Actions

This Discussion