Re: Static mappings drop on PIX 6.3(3)

mrouch · ‎10-08-2004

I have a recurring problem with my pix firewall configurations. When I create static mapping from an inside interface to the outside, the static does not stay in place, but drops after having been idle (no traffic in or out for that static map) for a time. here is a sample of the relevant config.

---Begin---

access-list inside_nat0_outbound permit ip 10.31.84.0 255.255.255.0 any

global (outside) 1 10.31.84.20-10.31.84.253 netmask 255.255.255.0

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 10.31.84.3 10.229.24.117 netmask 255.255.255.255 0 0

---End---

In this example, addresses 20-253 are dynamically assigned, and address 3 is statically assigned to 10.229.24.117. Upon powering up, sending any traffic from 10.229.24.117 will correctly map that address to 10.31.84.3. Once this is done, traffic originating from the outside interface can access 10.229.24.117 via its nat address. If the traffic goes idle, however, after a while the translation is dropped, and it then requires OUTBOUND traffic to reinstate it. The nat address 10.31.84.3 will not accept any more inbound traffic. Only outbound traffic will reinstate the static translation.

Has anyone else seen this problem? How can I configure this so that either (1) the static translation never drops once created or (2) the pix allows inbound traffic from the outside interface to activate the static translation?

Thanks,

Mathew

scoclayton · ‎10-08-2004

access-list inside_nat0_outbound permit ip 10.31.84.0 255.255.255.0 any

nat (inside) 0 access-list inside_nat0_outbound

I suspect the above that I cut out of your post may be the problem. What exactly are you trying to accomplish with this statement?

To answer your original question, statics are bi-directional and the xlate should be created from the outside *if* allowed via your ACL. Having the connection or xlate time-out is a good thing as it frees un-used resources until they are needed.

Scott

mrouch · ‎10-08-2004

Sorry, I left out some information in my original post. the nat(inside) 0 statement is there because any traffic originating from 10.31.84.0 is subsequently encrypted and sent over an IPSEC tunnel to another pix. I've been following the configs recommended in Cisco Press' "Cisco Secure PIX Firewalls." Specifically chapter 11, configuring IPSEC. It states that since translation occurs before encryption, this nat 0 statement is required to send natted traffic over the tunnel.

scoclayton · ‎10-08-2004

Still not sure I follow. According to these 2 lines from your config:

global (outside) 1 10.31.84.20-10.31.84.253 netmask 255.255.255.0

static (inside,outside) 10.31.84.3 10.229.24.117 netmask 255.255.255.255 0 0

The 10.31.84.0 segment lives on the outside interface of your PIX. But these 2 commands tell the PIX to "nonat" any packets that it receives on it's inside interface sourced from 10.31.84.0/24 destined for anywhere.

access-list inside_nat0_outbound permit ip 10.31.84.0 255.255.255.0 any

nat (inside) 0 access-list inside_nat0_outbound

Based on what I what I can infer about your network, I don't understand how the PIX could be getting packets sourced from 10.31.84.0/24 on the inside interface. Am I missing something?

Scott

mrouch · ‎10-08-2004

Okay, here's a little more of the config:

---Begin---

access-list inside_nat0_outbound permit ip 10.31.84.0 255.255.255.0 any

access-list outside_cryptomap_1 permit ip 10.31.84.0 255.255.255.0 any

global (outside) 1 10.31.84.20-10.31.84.253 netmask 255.255.255.0

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 10.31.84.3 10.229.24.117 netmask 255.255.255.255 0 0

crypto ipsec transform-set xxxxx yyyyyyy zzzzzzzzz

crypto map outside-map 1 ipsec-isakmp

crypto map outside-map 1 match address outside_cryptomap_1

crypto map outside-map 1 set peer xx.xx.xx.xx

crypto map outside-map 1 set transform-set xxxxxx

crypto map outside-map interface outside

---End---

Basically, this pix nats everything outbound, one address statically and all others dynamically. Does that make any more sense?

subaa · ‎10-08-2004

Hi,

Delete global (outside) since it has no sense here. Configure the following:

-----------------------

access-list inside_nat0_outbound deny ip host 10.31.84.3 any

access-list inside_nat0_outbound permit ip 10.31.84.0 255.255.255.0 any

static (inside, outside) 10.31.84.3 10.229.24.117 netmask 255.255.255.255 0 0

-----------------------

The problem is simple:

1) nat 0 access-list definition is always stronger than your static. If you define a deny as above, that the second next stronger nat statemant comes (here it is the static)

2) As someone said above - there are some problem with your addressing. But no problem: delete the global, delete the nat (inside) 1 0 0 command.

SubAa

rsmith · ‎10-08-2004

I believe the nat 0 command should be deleted, and this should solve your problems. The vpn tunnel access-list will send data across your tunnel without nat, therefore, the nat 0 command is not needed, and is conflicting with your nat 1 command. When your session is idle, and the nat 0 takes precedence, it drops your static, and no outside access is possible.

mrouch · ‎10-09-2004

Okay, the consesus view seems to be that my nat 0 is at best faulty and at worst completely useless. I'll remove it and run some tests. I'll post the results here, probably tomorrow or Monday.

The more I think about it, the more I think you are correct.

mrouch · ‎10-11-2004

Okay, I've removed the nat 0 and spent a couple of frustrating hours testing it. Here's what it is doing.

I find that removing the nat 0 worked... sort of. It is true that now if I attempt to access the statically mapped host from the outside (a host on the far side of the vpn tunnel) the xlate will be recreated and IP connectivity will work... PROVIDED that there has been some activity in the vpn tunnel, coming from any host, within the last 60 seconds. I tested this repeatedly. If I sent a string of pings to the statically mapped nat address from the outside, then stop the pings and wait 60+ seconds without sending ANY traffic over the tunnel, subsequent pings will fail (even though the xlate still exists and the tunnel is still up!) If I wait only 55 seconds, the subsequent pings work just fine. 65 seconds, and they fail. Like clockwork.

Here's a specific test I did that illustrates the problem pretty well. I set up two hosts on the inside interface of the pix. One was assigned the IP address that gets the static nat, the other was assigned an address that will get allocated a nat address from the global 1 pool. I sent some traffic out to the Internet from the dynamically mapped pc. The tunnel comes up, and the xlate for that pc is created. Then I send a series of pings from the outside over the tunnel to the static nat address. The xlate is created, and the pings get replies. Everything looks good.

Now, I stop the pings and wait 60+ seconds. I start up the pings from the outside again. They fail, even though the xlate is still there and the tunnel is still up. I leave the pings going. Then I go to the PC with the dynamically assigned address and send some traffic over the tunnel (for example, I click "refresh" on the web browser). As soon as I do that, the pings to the static nat address start getting through.

Any ideas? I'm baffled.

lr.moore · ‎10-09-2004

Matt,

do you have proxy arp disabled on outside interface?

sysopt noproxyarp outside

If so, try enabling the proxy arp ..

no sysopt noproxyarp outside