ASA issue routing packets to wrong interface

Unanswered Question
Apr 18th, 2012

Looking for help/advice with the following problem: We have an ASA5520 running ver 7.0(8), nat-control is disabled. On the "outside" interface we have a closed network which is publicly addressed i.e. no access to Internet. We also have two Vlan interfaces on a trunk connection i.e. "inside" interface (Vlan7) and "dmz" interface (Vlan802). Traffic from the "outside" to "inside" is statically NAT'd such that the public IP is translated to a private IP when accessing the "inside" interface. However, our OSS servers on the "dmz" interface need to be able to receive packets from the public IP addresses on the "outside" . All is okay with the outside to inside traffic and traffic initiated from the OSS servers on the "dmz" to the outside works okay (snmp gets etc) i.e. the servers receive reply packets from the public addresses of the outside devices.

However, traffic that originates on the "outside" interface (snmp traps etc) which is destined for the "dmz" is actually being routed to the "inside" interface and therefore the public source address is being NAT'd by the static NAT command. The access-list "in_on_outside" has relevant entries to allow connectivity from outside to dmz, we have tried a static nat command (outside, dmz) to maintain the public addressing but this made no difference and also a nat exempt.

With nat-control disabled - do I still need a translation or NAT exempt for the "outside" <> "dmz" traffic flow, if so how should this look ?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jouni Forss Wed, 04/18/2012 - 03:00


Can you post configurations of the interfaces and NAT and perhaps the ACLs too.

- Jouni

paul.mccluskeyg... Wed, 04/18/2012 - 03:18

Config of interfaces and NAT :-

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address x.x.x.x standby x.x.x.y


interface GigabitEthernet0/1

description STATE Failover Interface


interface GigabitEthernet0/2

no nameif

no security-level

no ip address


interface GigabitEthernet0/2.7

vlan 7

nameif inside

security-level 100

ip address standby


interface GigabitEthernet0/2.802

vlan 802

nameif dmz

security-level 90

ip address standby

nat (outside) 0 access-list exempt

static (inside,outside) netmask

static (dmz,outside) netmask

static (outside,inside) z.z.z.0 netmask       ***real publics removed****

The following host to host ACL was created as a test in an attempt at NAT exempt:-

access-list exempt extended permit ip host z.z.z.244 host

Jouni Forss Wed, 04/18/2012 - 03:29


Your firewalls software should already include the "packet-tracer" command.

Can you use the "packet-tracer" command on the command line interface for the traffic that is problematic and post the whole output here

The command format is:

packet-tracer input

The input interface is the interface from where the connections is initially established from.

- Jouni

Jouni Forss Wed, 04/18/2012 - 03:30


Also atleast the following command seems abit strange:

static (dmz,outside) netmask

Is there really a network behind the DMZ interface?

- Jouni

paul.mccluskeyg... Wed, 04/18/2012 - 03:43


Packet tracer does not seem to be available in this version of software:-

# packet-tracer ?

ERROR: % Unrecognized command

Also, apologies for the typing error, the above static should read :-

static (dmz, ouside) netmask      

I don't think this is actually necessary as nat-control is disabled but at the same time I don't think it will be causing the problem (sorry inherited most of this config).

Jouni Forss Wed, 04/18/2012 - 03:52


Seems I remembered wrong. The packet-tracer command was introduced in 7.2(1) software.

Could you maybe try the connection and at the same time gather log through ASDMs monitor window and post a screencapture here.

- Jouni

Dan-Ciprian Cicioiu Wed, 04/18/2012 - 04:29

Hi Paul ,

As you have disabled nat-control, I would try to delete :

nat (outside) 0 access-list exempt

static (inside,outside) netmask

static (dmz,outside) netmask

The configuration - without those nat/static statements look straigh forward. With nat-control , there is no need for nat in any direction.

How do you know that your traffic is forwarded to the inside interface ?


paul.mccluskeyg... Wed, 04/18/2012 - 05:54

Yes - I will try to arrange to have those statements removed, I agree they should not be needed. Having said that I don't think they will be contributing to this problem?

I have captured traffic on all interfaces and can see the packets arrive on the "outside" interface and leave on the "inside" interface - no sign of them on the dmz interface.

Jouni - sorry we don not use ASDM only cli.

Dan-Ciprian Cicioiu Wed, 04/18/2012 - 05:59

Paul , the only doubt that I have is with :

static (inside,outside) netmask

even though the is direcly connected but still part of used as identity nat


paul.mccluskeyg... Wed, 04/18/2012 - 07:24


Looks like your suspicions were correct - removing that static seems to have resolved the problem - thanks very much for your help :-)


This Discussion

Related Content