PIX NAT Issue

[xcz504d1114]

My PIX experience has clearly gone the way of the DoDo. I have a customer that has switched their internet provider, and is on a migration path to remove their existing PIX. The new internet connection is attached to an ASA, not the PIX, but servers still sit behind the PIX DMZ for now. So, the data path has changed from PIX DMZ to PIX Outside, to PIX DMZ to PIX Inside then routed to the ASA.

I cannot get the NAT to work proper going from the PIX DMZ (Security lvl 4) to the PIX Inside (Sec Lvl 100).

Traffic routes properly, but only if a connection is initiated by the inside first, to establish an existing NAT. The DMZ cannot properly NO Nat out.

I have tried the following:

Nat (inside) 0 0.0.0.0 0.0.0.0

access-list dmz_nonat permit 10.1.0.0 255.255.255.0 any

Nat (dmz) 0 access-list dmz_nonat

The 10.1.0.0/24 would represent the DMZ IP address space. Going from teh Inside to DMZ works, but the DMZ cannot initiate connectivity out, until a NAT entry is built from the Inside first.

[Jouni Forss]

Hi,

I am not sure if I understand the setup/topology completely but from what I understand there is simply some NAT problem on the PIX that wont let DMZ initiate connections towards INSIDE?

You also mention that the traffic will only flow if INSIDE initiates the connection? Sounds to me like you have configured Dynamic PAT from INSIDE to DMZ perhaps?

But I am not really sure what the situation.

Perhaps a simple picture of the network setup, current PIX NAT configurations and the description which network needs to reach which network would give us clue what configurations are needed to correct the situation.

- Jouni

[xcz504d1114]

Sure, here is a drawing of what I was trying to describe. Also, I can completely delete any and all existing NAT's, and start from scratch.

[Jouni Forss]

Hi,

I would imagine with such a setup the traffic from DMZ to OUTSIDE through the ASA should be fine provided that the default route from the PIX points to the INSIDE interface of the ASA and the route for the DMZ network from the ASA points to the INSIDE interface of the PIX.

If this is not so, I would have to see the NAT configurations on the PIX atleast.

What I do wonder is how your INSIDE to DMZ traffic would work. There might be some asymmetric routing going on if both PIX and ASA is connected to the same LAN subnet directly.

What I mean is that a new TCP connection formed between INSIDE and DMZ host would go

• TCP SYN from host to defaulte gateway ASA
• TCP SYN from ASA to PIX INSIDE and finally to host on DMZ
• TCP SYN ACK from DMZ host to PIX and from there directly to the host on the INSIDE
• TCP ACK from the INSIDE host to the default gateway ASA and from there to PIX INSIDE and then finally to DMZ host

Though I would imagine that you have configured TCP State Bypass or have something else to prevent this from being a problem.

- Jouni

[andduart]

Hi,

Have you tried to collect logs at a time to have the issue? They could give us more information

logging on

logging buffered 7

sh log

Also, what is the software version in your Pix?

[jumora]

Ok, we need to define what is the source IP address what is the destination IP address, what services, how traffic will flow from where it is coming from, if the server on the DMZ of the PIX knows how to route back to the source (this depends mainly on the PIX routing table), security levels involved.

So this is what we have for the time being:

PIX:

Traffic flow from Security level 4 to the PIX Inside interface with security level 100

If you are initiating traffic from the DMZ to reach something on the inside you need to check that you have the correct NAT or NAT exemption and then that you have the corresponding ACL + access-group that will allow that traffic to go through to the inside, remember that security levels come in place here, from high to low ACL is not a requirement if no ACL+access-group is applied to the interface but it is a requierment is you are coming from a lower security interface to a higher security interface.

The NAT exeption rule would go something like this:

access-list nonat permit ip any 10.1.0.0 255.255.255.0

Nat (inside) 0 access-list nonat

FYI: This is just a configuration example, I am not sure what you already have configured on your PIX

Then if you where to generate traffic from the DMZ network of the PIX to the inside you would still be missing the ACLs that would permit the traffic through to the inside.

Configuration example:

access-list dmz permit ip 10.1.0.0 255.255.255.0 X_network X_netmask

From the looks of it you already have the correct ACL since on your notes you indicate that when traffic was originated from the inside you would be able to access from the dmz. This is due to NAT 0 configuration that I mentioned you should remove. NAT zero configuration builds an XLATE when you establish a connection from the higher security level where the command was in place after the timeout XLATE kicks in you will no longer be able to reach anything on the higher security level.

I would remove that NAT zero line since it is not really good to have something that temporarly works but it all depends on your current setup and what flows from one interface to another.

[jumora · Accepted solution]

Just follow the next and it should work:

enable

config t

access-list nonat permit ip any 10.1.0.0 255.255.255.0

Nat (inside) 0 access-list nonat

The reason that his works when traffic is originated from the higher security level interface to the lower is becase of the  NAT 0 configuration  that you mentioned or configured before:

Nat (inside) 0 0.0.0.0 0.0.0.0

NAT zero configuration builds an  XLATE when you establish a connection from the higher security level interface from where it is applied to any other interface on a lower security level then when the timeout XLATE kicks in you will  no longer be able to reach anything on the higher security level from the lower.

I  would remove that NAT zero line since it is not really good to have  something that temporarly works but it all depends on your current setup  and what flows from one interface to another.

[xcz504d1114]

This is exactly what i was looking for, I was applying it to the wrong interface, cleaned up all the other unnecessary NAT's and applied this, thank you.

[jumora]

Have a nice one!!!!