topic Re: FWSM, nat exemption issue in Network Security

FWSM, nat exemption issue

Norberto Salgado — Mon, 11 Mar 2019 16:59:13 GMT

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,

Re: FWSM, nat exemption issue

Kureli Sankar — Wed, 20 Jan 2010 15:30:54 GMT

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

Re: FWSM, nat exemption issue

Norberto Salgado — Wed, 20 Jan 2010 15:40:57 GMT

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,

Re: FWSM, nat exemption issue

Kureli Sankar — Wed, 20 Jan 2010 16:53:07 GMT

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

Re: FWSM, nat exemption issue

Norberto Salgado — Thu, 21 Jan 2010 14:21:07 GMT

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,

Re: FWSM, nat exemption issue

Norberto Salgado — Thu, 21 Jan 2010 17:48:21 GMT

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

Re: FWSM, nat exemption issue

stuart — Fri, 22 Jan 2010 19:12:06 GMT

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

Re: FWSM, nat exemption issue

stuart — Fri, 22 Jan 2010 19:18:20 GMT

Also are there any shared interfaces between the contexts?

If so are you using context classification to ensure that traffic is forwarded to the correct context?

Stu