cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
551
Views
0
Helpful
8
Replies

Pix 6.3(3) traffic flows & xlate issues

rahil.patel
Level 1
Level 1

Traffic flows (inside hosts going out) using PAT stop for random amount of time. When clear xlate command is issued on the pix, it enables the flows right away.

Have tried different timeout values for conn,xlate etc but the problem still exists. Currenlty the timeouts are set back to defaults.

Any help will be really appreciated.

8 Replies 8

baileja
Level 1
Level 1

Could you please post your config. It would be much easier to diagnose the problem. At the minimum include the nat and global related commands.

Here's the config

arp timeout 14400

global (outside) 1 xx.xx.xx.10

global (outside) 4 XX.XX.XX.17

global (outside) 5 XX.XX.XX.18

global (outside) 6 XX.XX.XX.19

global (outside) 7 XX.XX.XX.20

global (outside) 8 XX.XX.XX.21

global (outside) 9 XX.XX.XX.22

global (outside) 10 XX.XX.XX.23

global (outside) 11 XX.XX.XX.24

global (outside) 12 XX.XX.XX.25

global (outside) 13 XX.XX.XX.26

global (outside) 100 XX.XX.XX.30

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat (inside) 1 172.31.31.0 255.255.255.0 0 0

nat (inside) 4 172.16.3.0 255.255.255.0 0 0

nat (inside) 5 172.16.48.0 255.255.240.0 0 0

nat (inside) 6 172.16.64.0 255.255.240.0 0 0

nat (inside) 7 172.16.80.0 255.255.240.0 0 0

nat (inside) 8 10.3.0.0 255.255.248.0 0 0

nat (inside) 9 10.1.0.0 255.255.248.0 0 0

nat (inside) 10 10.2.0.0 255.255.248.0 0 0

nat (inside) 11 172.16.240.2 255.255.255.255 0 0

nat (inside) 12 172.16.240.18 255.255.255.255 0 0

nat (inside) 13 172.16.240.34 255.255.255.255 0 0

nat (inside) 100 172.16.48.10 255.255.255.255 0 0

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

I do see one thing odd about your config here. You have overlapping nat statements that map to seperate pools. For example your statement:

nat (inside) 1 0.0.0.0 0.0.0.0

covers every host on the inside and translates all of them to global pool 1. Following that nat statement you have various others translating identified subnets that map to other global pools. I think this might be the cause of your problems. Try removing the 0 0 nat statement. If you have subnets unidentified in the config above, replace the 0 0 nat statement with others that map those subnets to the same global pool (global 1).

jose.couto
Level 1
Level 1

We saw a similar problem in the past. The PIX was not the culprit, but an ADSL router in front of it. The router did not let pass the packages with source port over 60000 or so.

Check the traffic at the output interface in order to verify that the PIX is working fine.

Hope this helps. Regards.

If that was the case, then why would clear xlate restore the connectivity back?? I checked the router, its not the culprit.

When you say it stops for a random amount of time, does that mean it clears by itself if you dont do the clear xlate?

How many translations are active? There might an infected host opening thousands of connections. See if there are a lot of translations for the same host.

No the translations don't clear but the connections would do nothing. When you clear xlate & pix rebuilds them all the hosts can get through.

At any give time the translations that are active range from 500 - 900 which is normal in our case. There aren't as many connections from a single host.

Because after clear xlate the PIX starts to use low ports again, until it reach the 60000 some time later, where the problem appears again.

If you tested that the packets are not going through the PIX, forget my suggestion.

Regards.

Review Cisco Networking products for a $25 gift card