cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3912
Views
0
Helpful
11
Replies

ASA issue routing packets to wrong interface

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 ?

11 Replies 11

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

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

- Jouni

Config of interfaces and NAT :-

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address x.x.x.x 255.255.255.248 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 10.178.8.64 255.255.255.0 standby 10.178.8.65

!

interface GigabitEthernet0/2.802

vlan 802

nameif dmz

security-level 90

ip address 10.10.120.1 255.255.255.0 standby 10.10.120.2

nat (outside) 0 access-list exempt

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

static (dmz,outside) 10.10.120.0 10.182.120.0 netmask 255.255.255.0

static (outside,inside) 10.10.191.0 z.z.z.0 netmask 255.255.255.0       ***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 10.10.120.10

Hi,

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

Hi,

Also atleast the following command seems abit strange:

static (dmz,outside) 10.10.120.0 10.182.120.0 netmask 255.255.255.0

Is there really a network 10.182.120.0/24 behind the DMZ interface?

- Jouni

Jouni.

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) 10.10.120.0 10.10.120.0 netmask 255.255.255.0      

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).

Hi,

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

Hi Paul ,

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

nat (outside) 0 access-list exempt

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

static (dmz,outside) 10.10.120.0 10.182.120.0 netmask 255.255.255.0

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 ?

Dan

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.

Paul , the only doubt that I have is with :

static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

even though the 10.10.120.0/24 is direcly connected but still part of 10.0.0.0/16 used as identity nat

Dan

Dan,

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

Glad to hear that Paul.

Dan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: