Must reboot Pix 515...

[vfr1999]

I'm relatively new to working with firewalls, so please bear with me. Recently a guy set up a PIX 515 for us and a couple of weeks after it went online we started experiencing a problem. At seemingly random times, attempts to access sites like Yahoo and Monster.com result in Page not found. As time has gone on, the list of sites affected now includes Google and ESPN (these sites were not originally affected). Nslookup on these affected sites fails. The only way to "fix" the problem and get back to those sites is to reboot the PIX. The problem might come back in 10 minutes or not for hours or the next day. A friend of mine thinks that it is a DNS problem, but why would rebooting the PIX resolve the issue, even if only temporarily? I have posted the config for the PIX. Any help is appreciated.

PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password Rq0tA/lEqFtmn.Eq encrypted
passwd 7DRHGTSgmripPocl encrypted
hostname corepix
domain-name inviewvision.com
clock timezone EST -5
clock summer-time EDT recurring
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
no fixup protocol http 80
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
object-group service WebTCP tcp
port-object eq telnet
port-object eq www
port-object range 3389 3389
port-object eq https
port-object eq ftp
port-object eq smtp
port-object eq domain
port-object range 18888 18888
port-object range 554 554
port-object range 7070 7070
port-object range pptp pptp
port-object range 19180 19181
port-object range 4662 4662
object-group service 4.61udp udp
port-object eq domain
object-group service 4.60tcpin tcp
port-object eq www
port-object eq https
object-group service 4.13tcpin tcp
port-object eq www
port-object eq https
object-group service MAIL2_TCP_IN tcp
port-object eq www
port-object eq https
object-group service VCGATLS10_TCP_IN tcp
port-object eq smtp
object-group service VCGATLS07_tcp_in tcp
port-object eq domain
object-group service VCGATLS07_UDP_IN udp
port-object eq domain
object-group service VCGATLMCRPOWA1_TCP_IN tcp
port-object eq www
port-object eq https
object-group service VCGATLS01_TCP_IN tcp
port-object eq pptp
port-object range pptp pptp
object-group service BES tcp
port-object range 3101 3102
object-group service VCGATLMCRPWEB3_TCP_IN tcp
port-object range https https
port-object eq https
port-object eq www
access-list inside_access_in permit tcp any any object-group WebTCP
access-list inside_access_in permit ip any any
access-list inside_access_in permit icmp any any echo
access-list inside_access_in permit tcp host 172.16.4.11 any object-group BES
access-list inside_access_in permit tcp host 172.16.6.25 any object-group VCGATLS01_TCP_IN log
access-list outside_access_in permit icmp any any echo-reply log
access-list outside_access_in permit tcp any host 65.114.63.35 object-group MAIL2_TCP_IN log
access-list outside_access_in permit tcp any host 65.114.63.40 object-group 4.13tcpin
access-list outside_access_in permit tcp any host 65.114.63.43 object-group VCGATLS10_TCP_IN
access-list outside_access_in permit tcp any host 65.114.63.42 object-group 4.60tcpin
access-list outside_access_in permit tcp any host 65.114.63.37 object-group VCGATLS07_tcp_in
access-list outside_access_in permit udp any host 65.114.63.37 object-group VCGATLS07_UDP_IN
access-list outside_access_in permit tcp any host 65.114.63.36 object-group VCGATLMCRPOWA1_TCP_IN
access-list outside_access_in permit tcp any host 65.114.63.38 object-group VCGATLS01_TCP_IN
access-list outside_access_in permit tcp any host 65.114.63.44 object-group VCGATLMCRPWEB3_TCP_IN
no pager
logging on
logging timestamp
logging console emergencies
logging trap notifications
logging host inside 172.16.4.42
logging host inside 172.16.6.98
mtu outside 1500
mtu inside 1500
ip address outside 65.114.63.34 255.255.255.224
ip address inside 172.16.6.22 255.255.252.0
ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip audit info action alarm
ip audit attack action alarm
pdm location 0.0.0.0 0.0.0.0 inside
pdm location 208.52.129.160 255.255.255.224 outside
pdm location 172.16.4.60 255.255.255.255 inside
pdm logging critical 100
pdm history enable
arp timeout 14400
global (outside) 10 interface
nat (inside) 10 0.0.0.0 0.0.0.0 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 65.114.63.33 1
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
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 208.52.129.160 255.255.255.224 outside
http 0.0.0.0 0.0.0.0 outside
http 172.16.4.0 255.255.252.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
fragment size 1500
sysopt connection permit-pptp
telnet 0.0.0.0 0.0.0.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80
Cryptochecksum:13709e7cea89f22a343a4e57eda734b8
: end

 

[tbissett]

The only thing I can think of has nothing to do with the PIX rebooting, but here goes: Do you have a DNS reverse-lookup record for the IP of the PIX outside interface (65.114.63.34)? HTTP performance can be intermittent without this. Cisco also has a doc that says the same thing:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094459.shtml

Totally unrelated, but your inside_access_in access-list really isn't doing a whole lot because the second line is permitting all IP, so you're permitting everything anyway... Every line below isn't being used as a result, and the line above isn't needed either due to line 2. You're better off either getting rid of the access-list entirely (PIX default behavior) or using the access-list to actually limit the traffic that you want going outbound (better from a security standpoint).

 

[criticalUpdate]

try changing the fixup protocol dns maximum-length 512
to a larger amount like 4096 or just doing a no fixup protocol dns then test for awhile.!

Jeff

 

[vfr1999]

I changed the fixup protocol dns maximum length to 1024 and that seems to have done it. No problems since yesterday. Thanks a bunch, it was driving us nuts.