FWSM, nat exemption issue

Unanswered Question
Jan 20th, 2010

Hi,

we have an FWSM that's using different contexts. We are using nat exemption in some of these contexts, sometimes our users in the outside can't access to the inside. This already happened in different contexts and diferents hosts. And when the problem occur some machines in the same vlan (configured in the FWSM in the same way) had the problem and were working fine. After delete the nat configuration and add it again, all machines started to work fine again. Can this be caused by a bug? Or can we be hitting the translations limit? We are using the version 3.2(2).

Thank you.

Best regards,

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Kureli Sankar Wed, 01/20/2010 - 07:30

It could be many things.

1. incorrect static

2. proxy arp

3. xlate exhaustion

Since this is multiple context I'd suggest opening a TAC case so, they can collect the necessary data at the time of the problem to identify the root cause.

-KS

Norberto Salgado Wed, 01/20/2010 - 07:40

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Thank you for your reply.

1.If it's an incorrect static, shouldn't the problem be continuous and always occur in same hosts?

2.The limit for xlate it's 256k for all contexts correct?

Can you advise me some troubleshooting document on this?

Thank you.

Best regards,

Kureli Sankar Wed, 01/20/2010 - 08:53

Unfortunately there is no troubleshooting document for this probelm as this could be caused by too many issues that I stated about including routing issues.

X-late limit is 256K divided between all contexts. You are correct.

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/specs_f.html#wp1056716

Before and during the problem you should collect the following:

1. sh xlate debug | i x.x.x.x

2. syslogs (level 7) when the flow breaks

3. sh arp | i x.x.x.x before and during

5. sh xlate count (do it on all contexts to see if one context is using up all the slots)

-KS

Norberto Salgado Thu, 01/21/2010 - 06:21

Hi,

I've asked some logs and the only thing that I see that can be related to problem it's this:

%FWSM-4-410001: Dropped UDP DNS request from InsideVLAN:a.a.a.a/20498 to Outside:b.b.b.b/53; label length 108 bytes exceeds protocol limit of 63 bytes

Where a.a.a.a it's the IP of one of the servers in wich we were unable to access from the outside at the time that message appears in logs.

Can this be related with the issue?

I only got that message in syslog in the time that the problem occur, if this it's the cause of the problem, maybe we should see more of this messages.

But it's a bit coincidence that the only message that we got at the time of the problem it's relative to one of the machines that we were having problems.

Thank you.

Best regards,

Norberto Salgado Thu, 01/21/2010 - 09:48

In the output of the show np stats 3 I can see a lot of Close Notify Errors, any idea of what can be causing this?

Discard Statistics
  ------------------
  Ingress Discards         : 0
    8100 Packets           : 0
    Emb Xlate Packets      : 0
    Process Ack Errors     : 0
    Close Notify Errors    : 123317
    D300 Packets           : 0
    Bad Vlan Id Packets    : 0
    VFT Load Errors        : 0
    PIF Load Errors        : 0
    Xlate Create Errors    : 0
    Ingress Aborts         : 0

  Egress Discards          : 31531514
    Xlate Read Error       : 0
    D300 Packets           : 0
    Not Outside Xlate      : 0
    Out Xlate Create       : 3
    Console Accs Denied    : 62323
    AAA Denied Packets     : 0
    AAA  Packets           : 0
    ACL Denied Packets     : 26486601
    TLV Error Packets      : 0
    Shunned Packets        : 0
    Too many connections   : 207
    Rev Route Lkup Fail    : 263816
    Inbound Deny (!static) : 22476
    Self Route Packets     : 4638527
    Session Mgmt           : 0
    Bad Vlan Id Packets    : 0
    Read Global Table Fail : 0
    ARP drop               : 0
    VFT Load Errors        : 0
    Pif Load Errors        : 0
    Bad IP Length Packets  : 0
    IP Checksum Errors     : 0
    Xlate Create Errors    : 0
    Est<->HO Errors        : 0
    HO Insert Errors       : 0
    ICMP Msg Orig Pkts     : 0
    Unsupported AAA Config : 0
    Sess Mgmt RL Drops     : 21
    Nat0 SSLC Outside      : 0
    Egress Aborts          : 0
    Management Only Ifc    : 0
    Route Misses           : 31005
    VF Disable Drops       : 0
    Deny Conns (Low PC Mem): 0
    Deny Conns (Conn State): 0
    SMTP Packets           : 0
    Assert Soft            : 0
    GPH Frame              : 0
    ICMP Packets           : 33
    Resource Allocate Fail : 0
    Invalide IP Addr       : 5
    Classify Fail          : 0
    Nat Lookup Fail        : 26423
    Policy CLS Lookup FaiL : 0
    Policy CLS Permit Fail : 0
    Policy Not Equal CLS   : 0
    Nat and Global Conflict: 0
    Interface Down         : 74

Xlate Create Errors      : 0
  HO Insert Errors         : 0
  Reset Pkts Generated     : 0
  VFT Load Errors          : 0
  PIF Load Errors          : 0

Hi,

Looks like this could be down to your DNS being dropped by the default DNS inspection policy.

Do a show service-policy on the FWSM depending on the code version should look something like the following:

sh service-policy

Global policy:

  Service-policy: global_policy

    Class-map: inspection_default

      Inspect: dns preset_dns_map, packet 0, drop 0, reset-drop 0

      Inspect: ftp, packet 0, drop 0, reset-drop 0

See if you have any drops in this line. If you users are accessing the servers by name for instance this could explain your outages.
The default policy should look like the below, if this has been modified to a lesser length could be the cause?

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum 512

Just something to check out, along side the potential NAT issues.

Stu

Actions

This Discussion