PIX all of a sudden can't handle dns traffic

Discussion in 'Cisco' started by jlm33990, Jan 30, 2006.

  1. jlm33990

    jlm33990 Guest

    Brand new to PIX. Here's the story...
    pix 515e running 6.3(5)
    Box will freeze from time to time and won't pass/handle new dns
    requests. IP traffic is still ok if you use ip# only. Host names will
    not resolve. Clear local will fix the problem. I don't have any rules
    or statics for dns.
    Inside clients point to an internal solaris named box for resolution
    who will pass request to isp if he doesn't have answer. Another fix to
    the problem is if I change my pc's resolver from the solaris box to the
    isp's dns.
    I've been running a solaris based firewall for years in the same
    environment and never had such a problem.(if I put the solaris firewall
    back in place the problem goes away)
    One minute I think there is something wrong with the pix because a
    reboot or clear local will fix the problem and the next minute I wonder
    if there could be something wrong with my named server because, as I
    said, if I point to the isp's dns servers the problem goes away. No
    changes have been made to the internal named server.
    I can see from syslog that the dns udp teardowns that normally take 1
    second all of a sudden take 2 minutes when the problem happens. I've
    looked throught the log around the time that happens and see nothing
    suspicious.
    Any ideas - I'm going insane
    thanks...jim
     
    jlm33990, Jan 30, 2006
    #1
    1. Advertising

  2. jlm33990

    lfnetworking Guest

    try messing with this command

    fixup protocol dns maximum-length <bytes>
    512 is the default

    jlm33990 wrote:
    > Brand new to PIX. Here's the story...
    > pix 515e running 6.3(5)
    > Box will freeze from time to time and won't pass/handle new dns
    > requests. IP traffic is still ok if you use ip# only. Host names will
    > not resolve. Clear local will fix the problem. I don't have any rules
    > or statics for dns.
    > Inside clients point to an internal solaris named box for resolution
    > who will pass request to isp if he doesn't have answer. Another fix to
    > the problem is if I change my pc's resolver from the solaris box to the
    > isp's dns.
    > I've been running a solaris based firewall for years in the same
    > environment and never had such a problem.(if I put the solaris firewall
    > back in place the problem goes away)
    > One minute I think there is something wrong with the pix because a
    > reboot or clear local will fix the problem and the next minute I wonder
    > if there could be something wrong with my named server because, as I
    > said, if I point to the isp's dns servers the problem goes away. No
    > changes have been made to the internal named server.
    > I can see from syslog that the dns udp teardowns that normally take 1
    > second all of a sudden take 2 minutes when the problem happens. I've
    > looked throught the log around the time that happens and see nothing
    > suspicious.
    > Any ideas - I'm going insane
    > thanks...jim
    >
     
    lfnetworking, Jan 30, 2006
    #2
    1. Advertising

  3. jlm33990

    jlm33990 Guest

    I thought of that but dismissed it thinking how could a simple dns
    request be more than 512 bytes - plus all dns stops - not just large
    requests.
    But it's worth a shot - I'll try messing with it and see what happens -
    i"m desperate. Thanks for the input....
     
    jlm33990, Jan 30, 2006
    #3
  4. This sounds like the symptoms of a known bug:

    CSCsc61300 CPU increases with high volume of DNS requests using same
    four-tuple.Here is list of all bugs recognised since the release of 6.3(5)
    and there associated 'patch' versions:Note there is no 102 6.3.5.100/
    30-Aug-2005 05:59 - CSCsb53549 VAC+ may cause interface to stop
    passing all trafficCSCsb53760 Port redirection for DNS traffic does not work
    correctly. 6.3.5.101/ 07-Sep-2005 02:23 - CSCsb71315 URL
    Filtering with long URLs could cause memory corruptionCSCsb75773 Malformed
    HTTP GET request causes URL filtering module to cause a crash. 6.3.5.103/
    11-Oct-2005 22:59 - CSCei63244 Traceback with lu_rx thread name in
    failover mode.CSCsb48916 Manual ipsec fail when esp-aes-256 specified with
    authCSCsb68431 names can turn off on startup, possible configuration
    lossCSCsb79761 Backspace sent in cut-through proxy authenticationCSCsb91253
    SIP: PIX does not parse the expire value in Register 6.3.5.104/
    09-Nov-2005 03:19 - CSCef19560 PIX - show uauth doesnt display users
    with space in usernameCSCsb79609 SIP: PIX does not update BYE embryonic's
    timestamp.CSCsb87382 SIP: Stanby PIX show the wrong value of xlate timeout
    for sip media.CSCsb91279 SIP: Standby PIX set unusual value of conn idle
    time.CSCsc23638 duplicate xlates on stateful standby due to static
    misconfigurationCSCsc25386 Higher metric OSPF external route is
    selectedCSCsc39368 PDM with Command Authorization requires the write command
    for Read-Only 6.3.5.105/ 01-Dec-2005 00:08 - CSCsc36311
    OpenSSL lib can be forced to negotiate the SSL 2.0 protocolCSCsc44193 ftp
    fixup drops ftp server response packetsCSCsc49665 SIP : Large number of
    static PAT cause delaying of RTP packetsCSCsc53472 PIX not following SNMP
    packet size standard in RFC3417CSCsc53491 Pix does not support SNMP variable
    ipForwardingCSCsc60930 PIX 6.3 Hitless Upgrade supportCSCsc61300 CPU
    increases with high volume of DNS requests using same four-tuple. 6.3.5.106/
    14-Jan-2006 00:09 - ? CSCdv54885 downloadable ACLs not deleted after
    cl uauth when telnet to PIXCSCsc14915 PIX 6.3 Spoofed TCP SYN packets can
    block legitimate TCP connectionsCSCsc66215 PIX reload with Thread Name:
    https_proxyCSCsc68744 PIX - Syslog PIX-6-110001: No route to IP generated
    incorrectlyCSCsc91098 SIP: PIX does not create media conns if first m= has
    port 0 in sdp. 6.3.5.107/ 23-Jan-2006 20:28 - CSCsc82346
    tftp fixup does not allow error message from clientCSCsc92911 PIX 6.3
    crashing at mgcp_show_sessionsCSCsc95334 PIX does not recognize RADIUS
    access-accept and access-reject packets.CSCsd08448 downloaded acl is not
    removed after a virtual telnet login 6.3.5.108/ 07-Feb-2006
    23:59 - CSCsb34758 connection to DMZ fails after PIX authentication
    sessionCSCsc60975 PIX crashes after removing Packet capture
    configuration...ver 6.3.5CSCsd14589 PIX reload with Thread Name:
    tcp_slowCSCsd26109 High CPU, delayed traffic, block depletion for 2 sec when
    loading PDM "lfnetworking" <_bill_@_lfnetworking.com> wrote in message
    news:wYwDf.28748$...
    > try messing with this command
    >
    > fixup protocol dns maximum-length <bytes>
    > 512 is the default
    >
    > jlm33990 wrote:
    > > Brand new to PIX. Here's the story...
    > > pix 515e running 6.3(5)
    > > Box will freeze from time to time and won't pass/handle new dns
    > > requests. IP traffic is still ok if you use ip# only. Host names will
    > > not resolve. Clear local will fix the problem. I don't have any rules
    > > or statics for dns.
    > > Inside clients point to an internal solaris named box for resolution
    > > who will pass request to isp if he doesn't have answer. Another fix to
    > > the problem is if I change my pc's resolver from the solaris box to the
    > > isp's dns.
    > > I've been running a solaris based firewall for years in the same
    > > environment and never had such a problem.(if I put the solaris firewall
    > > back in place the problem goes away)
    > > One minute I think there is something wrong with the pix because a
    > > reboot or clear local will fix the problem and the next minute I wonder
    > > if there could be something wrong with my named server because, as I
    > > said, if I point to the isp's dns servers the problem goes away. No
    > > changes have been made to the internal named server.
    > > I can see from syslog that the dns udp teardowns that normally take 1
    > > second all of a sudden take 2 minutes when the problem happens. I've
    > > looked throught the log around the time that happens and see nothing
    > > suspicious.
    > > Any ideas - I'm going insane
    > > thanks...jim
    > >
     
    Dom Wilkinson, Feb 15, 2006
    #4
  5. jlm33990

    stephan

    Joined:
    May 4, 2006
    Messages:
    1
    Have the same problem here.

    Did the fixup protocol dns fix the problem ?
     
    stephan, May 4, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page