NAT 0 access-list

[ditscap]

NAT Timeout values with NAT 0

A server on the outside of the firewall initiates a session to the server on the inside. The server on the inside stores the session via IP Address and Source port... this connection needs to stay open, but if there is no communication after the time alloted in the xl timeout, it is torn down... then, the server on the outside initiates another session with a different source port.. after this happens several times, the service on the internal server dies.

If I use:

access-list notimeout permit ip host 10.10.10.4 255.255.255.255 any

nat (outside) 0 access-list notimeout

Since the pix doesn't build an xlate table, will this bypass the timeout for the xlate? Once 10.10.10.4 makes a conneciton to a host on the otherside of the pix, will it be able to be idle indefinitely?

Thanks

[nkhawaja]

Hi,

since with NAT0 we are bypassing the translation table, the xlat timeout should not be an issue here (Could someone else correct me, if translation table builds up with NAT0+acccess-list) but the connection timeout will still be there.

Thanks

Nadeem

[pd-yca]

Of course, if you "nat 0" the inside address, that address will have to be routable on the outside of your PIX.

Have you looked at the "timeout" command? Perhaps you can adjust the "xlate" and "conn" parameters (defaults: 3 hrs and 1 hr, respectively) to exceed the intervals of inactivity between the servers.

[ditscap]

This is a firewall within in the campus network. The devices behind the firewall are medical devices that have to be isolated from the rest of the network and only talk to a few devices on the LAN. The problem is, over night, there aren't as many xrays and data being passed back and forth... but when data is passed after the conneciton has timed out, it opens up a new session wich causes the service to freak (old 1960's technology that isn't going to be updated)... So, if I use nat 0 access-list, I can bypass the xlate timeout, but will have to up the connection timeout by quite a bit?

[ditscap]

Since the device initiating the contact is on the outside interface, will this still work? Can I nat 0 access-list on the outside? Example:

Server1 - IP Address is 10.10.10.1 (The one making the connection)

Server2 - IP Address is 172.16.1.1 (The one on the inside of the firewall being connected to)

Pix#(config)access-list No-Timeout permit ip host 10.10.10.1 255.255.255.255 host 172.16.1.1 255.255.255.255

Pix#(config)nat (outside) 0 access-list No-Timeout

Pix#(config)timeout conn 0:0:0

Thanks

[ditscap]

Any comments on my last question? Any one?

[tgrundbacher]

I'm not sure about the xlate timers and how to avoid them. Yet, I have some comment on your last question, the nat 0 on the outside.

It took me some time to understand it: I had a project where I had to transparently route initiating hosts from the outside to the inside. Even then you need to nat 0 the inside network/hosts TOWARDS the OUTSIDE. It's the only simple way to 1:1 translate addresses, regardless who initiates the connection; that is, doing it from the higher security level to the lower one. A simple example is:

access-list range_any permit ip

nat (inside) 0 access-list range_any

Of course you shouldn't forget to permit your desired protocols inbound on the outside int.

Tell me if that worked.

Toni

[scoclayton · Accepted solution]

Sure, but you have a few syntax issues. Refer to the following:

Pix#(config)access-list No-Timeout permit ip host 10.10.10.1 host 172.16.1.1

Pix#(config)nat (inside) 0 access-list No-Timeout

Pix#(config)timeout conn 0:0:0

** No need for the all 255 mask when you specify host. And you want to apply the NAT to the inside interface. The translations when using a nat 0 ACL can still be built from the less secure interface. And your timeout on the conn is going to be global. I do not recommend using this as it can cause adverse effects. Every conn that is left in an open state incorrectly will never be cleared from the PIX conn table. This can cause memory depletion over time so if you are going to do this, please check the 'sh conn count' and 'sh conn detail' output often and make sure you do not have a lot of open conns on the PIX. It may require manual intervention from you to either clear the conns or reload the PIX.

If you are in a situation where the connection needs to remain open indefinetly between these machines, you may be better off locating these two hosts on the same segment so as not to have take these steps. Just a thought.

Scott

[pokwan]

Scott,

I am confused, shouldn't the syntax be

Pix#(config)access-list No-Timeout permit ip host 172.16.1.1 host 10.10.10.1?

Thanks.

PF