PIX 501

[4mrasmussen]

I am having problems with a new PIX 501. The pix stops transmitting requests from inside to outside for one group of hosts at random times. Sometimes it will work for just a few minutes and sometimes it will work for over an hour. I can always get in from the outside through various ports I have opened (SMTP, HTTP, etc.) I just can't browse out from some of the computers.

I have found that if I issue a no arp outside <outside ip> <outside mac> The problem goes away for ahile and I can browse again, but eventually the problem appears again.

I put a network sniffer on the segment and I do not believe there is any malicious behavior on the network. When browsing fails SYN packets never receive a reply. They just attempt to retransmit.

Any ideas what might be causing this problem?

[Patrick Iseli]

Could it be that you exceed your user license?

Do a "show version" and check how much users can pass !

sincerely

Patrick

[esanders]

Please post show version and show runing-config.

[4mrasmussen]

The firewall is licensed for an unlimited number of users so that shouldn't be the problem. Here is the version info and running config.

[Patrick Iseli]

Config looks good.

I think to put a sniffer in place is good way to start troubleshooting that.

Do you have log output from the PIX whan that problem occoures.

sincerely

Patrick

[esanders]

enter "show tech-support" during lock-out.

[4mrasmussen]

Here is a copy of the tech-support during a lock-out.

Another thing to note is that the machines which are affected are the machines using PAT. The few statically NATed machines are not affected.

[esanders]

Pffff.

Hard.

First I would make some sugggenstions.

I wouldn't call an access-list smtp.

Reserved word?

Second global (outside) 1 68.15.232.108

I know I still didn't offer you the sollution but lets try

Kind regards, Eric

ps. when the hickup appears, what does the "show xlate" tells you?

[4mrasmussen]

Here is what the show xlate looks like during a hickup.

[esanders]

Gooed morning.

Just read your respons.

192.168.1.54.........

And that is... a proxy?

If so, are you sure the problem doesn't starts there?

Kind regards,

Eric

[4mrasmussen]

192.168.1.54 was just the only machine that I had on the network at the time of this lockup. There is no proxy on this network.

Thanks,

Mike

[meyer]

I had almost the same issue on a connection where I had multiple Cisco routers connected to the ISP. The ISP was using Juniper routers probably running VRRP. The Juniper routers were not responding to ARP requests quickly enough and the Cisco 4506 routers on the same connection were doing proxy-arps. I cured it by configuring "no ip proxy-arp" on all of my routers connected to this ISP connection. Do you have other routers on this same link?

The only difference was that the PIX would stop working for all traffic, not just groups of hosts, but then I was only using one Internet address on it. Is each group of yours using a different Internet addresses? That could explain that difference.

[supertoaster2]

You need to do a show arp see if there is a problem with a network card failure or switch failure where it isn't forwarding the frames onto the pix.

I would do a show arp on the pix to see what it has in the arp table, And log the access-lists to see what traffic is going through? But it does sound like the bandwidth or something is being used up?

When you say clear arp on the outside ? Why should anyone be pinging your outside ip address of the pix?

Why would clearing the arp on the outside affect your inside users?

clear traffic

Sh traffic to see what traffic the pix is actually doing?

Or what the mailserver queues are actually doing that is what the users are sending and what attachments are being sent?

sh arp when the problem occurs look for incomplete mac addresses.

sh xlate to see where traffic was going?

clear xlate to clear firewall table?

If that doesn't work use the clear arp interface outside?

Start logging the access-lists

If that doesn't work do debug ip packet to see if you can see incomplete headers on the frame.

At the moment I believe it is three things?

Virus, bandwidth be used by user or server, faulty switch or pix ethernet interface.

The other thing to do is have a pc on the inside interface doing a continuous ping to see when or how often the pings drop out?

But the sniffer should be telling you what packets are being sent to what ports?

Good luck

[4mrasmussen]

I agree that I have thought that it was a virus consuming the bandwidth but I have throughly sniffed the network and there is no extraneous traffic. I have even gone so far as to take all of the hosts off the network except for one that I absolutely know is virus and worm free. The problem still occured.

I will try your other suggestions today and let you know the results.

Thanks for all of the suggestions. This one really has me stumped.

Mike

[4mrasmussen]

I discovered the problem. I reset the PIX to the factory defaults and started over again. When I did this the outside interface recieved a DHCP IP address from my ISP. The IP address assigned was different then any of the static addresses I had been given. The PAT addresses worked fine with this address. I went through and reconfigured the rest of my settings. Then I tried to assign a static IP address to the outside interface. The problem came back. When I switched the outside interface back to DHCP it works fine. I guess my ISP doesn't allow PAT through the static IP address range. I will have to check with them.

Thanks again for all of your assistance.