Re: xlate problem in pix 525

arturo.reyna · ‎10-01-2003

Hello:

I have a problem with nat (xlate) in my firewall pix 525 with 6.2.1 , I have 6 global group for nat my inside address to access internet (1517 with global + 166 in static = 1683 total ). In sometimes my users aren´t able to access internet and outside services because all ip nat address are in use. The problem is that my average for the nat were almost 600 or a little more few months ago, I think somekind of session (virus o something) is triying to connect to internet in not valid o not allowed ports and all ip address were used by no working session, only take the session and those were no in use. My xlate timeout is 30 minutes, to help my user to access its services I had (have) clear the xlate table.

I want to deny pix to offer a ip address to any host with no valid profile o access deny, or reduce the time for timeout xlate.

I want the pix to check the outbound configuration before assign a ip address for any hosts.

Can I do something of this?

I hope you can help me.

scoclayton · ‎10-02-2003

Hi,

I am not 100% certain what you are referring to here. Can you post a sample of your global/nat config for review?

Scott

cratejockey · ‎10-20-2003

We are haveing the exact same issue at over 30 remote sites on PIX 501s. It appears to us that it is a virus, however we cannot locate any viral content on pc's local to the sites experianceing the problem. Have you found a solution to this problem yet? If so any imput you could offer us would be much appreciated.

Thanks.

cscott · ‎10-20-2003

If you are exhausting your NAT pool, have you tried adding the outside interface to the pool? This would PAT the overflow through the single IP on the outside interface. The command is:

global (outside) 1 interface

This might not let too many programs work over the internet, but it should get the web/email traffic flowing again.

nkhawaja · ‎10-20-2003

Hi,

It seems to me as you are under attack and spoof packets are chewing up the translation. There are a couple of things

1- try to add ip verify unicast reversepath to inside interface. It will block / deny all the spoofed addresses

2- try to make access-list to only permit your inside hosts/network being translated

3- try to change your nat rule, e.g. if you have a nat rule like nat (inside) 25 0.0.0.0 0.0.0.0, make it more specific like nat (inside) 25 yourprivatenetwork mask.

Thanks

Nadeem

cratejockey · ‎10-21-2003

Thanks for the reply. We agree we are underattack of some sort but we are a fully private network using private 10. address space. The 30 plus remote sites are part of over 200 total remote sites. This attack is being generated from within our network and we are currently trying to gain Syslog and packet capture data in order to narrow the search. However the virus or attack had totally stopped for the past three days. As for 2:35pm Eastern Time, all sites came under attack again. In addition we add 4 more sites to the list. We will try your recomendations but any other imput would be greatly appreciated.

Thanks,

Josh

cratejockey · ‎10-23-2003

I wanted to follow up my last post with more information that we have gained over the past day. We have continued to track this issue and have determined that whatever attack we are experiancing is most likely not being genterated from our remote sites. We have checked a site that contains only network equipment with no servers or worstations present. The pix Xlate table at this site completly full. This leads us to beleive that the attack is being generated most likely from the inside of our private network or from the public internet. However based on syslog data that we have gathered we have noticed a recurring set of non-existant public IP addresses that this attack is trying to contact from internally at our remote sites. I'm not sure this really gives alot more info for people to help us out with but thats as far as we have made it so far.

Thanks,

Josh

nkhawaja · ‎10-23-2003

Hi,

The recommendation I gave in my last email should work for any non related IPs. Especially the IP verify unicast command will do the work to drop all those IPs.

Thanks

Nadeem