Cisco ASA routing issues between interfaces

[lopezportilla]

Hi,

We have defined our main network as inside on our Cisco ASA. Then we defined vlan (sub interfaces)  within this interface and add groups that allow access to each vlan (departments).

So far all works as expected. We also allow inter and intra communications between interfaces (all have same level of security 100).

So from outside to inside or other sub interfaces (vlan) each one within a group with proper NAT and rules work.

The problem comes when we want to access from inside network (10.11.x.x) to a vlan with ip 172.21.x.x. 

Of course I cannot add a route to this network since it is known by the device on a vlan. 

I think I need to move the inside to be also a vlan and no IP address on the interface itself but use a vlan like the others under inside to be able to reach the other sub interfaces right?

So what we have is something like:

interface Ethernet1/14
description untagged / native VLAN to inner networks
nameif inside
security-level 100
ip address 10.11.x.x 255.255.252.0

interface Ethernet1/14.30
vlan 30
nameif WEB_dev
security-level 100
ip address 172.21.x.x  255.255.0.0 

Thanks

Carmelo Lopez

[Rob Ingram]

Hi,
Please run packet-tracer from the CLI and provide the output for review. E.g:- "packet-tracer input inside icmp 10.11.x.x 8 0 172.21.x.x"

Do you have NAT configured that could unintentially NATTING the traffic? Provide the output of "show nat detail"

HTH

[lopezportilla]

Hi,

Yes we do NAT

here is the packet trace

Phase: 1

Type: ACCESS-LIST

Subtype: 

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 172.21.xx.xx using egress ifc  Web-dev

Phase: 3

Type: SUBOPTIMAL-LOOKUP

Subtype: suboptimal next-hop

Result: ALLOW

Config:

Additional Information:

ifc selected is not same as preferred ifc

Doing route lookup again on ifc  inside

Phase: 4

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 10.11.xx.xx using egress ifc  inside

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: Web-dev

output-status: up

output-line-status: up

Action: drop

Drop-reason: (rpf-violated) Reverse-path verify failed, Drop-location: frame 0x000000aab04e9034 flow (NA)/NA

The NAT (only the part involved)

6 (outside) to (inside) source static Net-XXX-VPN-network Net-XXX-VPN-network  destination static Net-XXX-VPN-network Net-XXX-VPN-network no-proxy-arp route-lookup description no NAT for VPN Clients going to their own net

    translate_hits = 1348838, untranslate_hits = 1351597

    Source - Origin: 10.11.xx.0 Translated: 10.11.xx.0

    Destination - Origin: 10.11.xx.0 Translated: 10.11.xx.0

10 (outside) to (Web-dev) source static Net_Web-Dev_NEtwork Net_Web-dev_NEtwork  destination static Net_Web-dev_NEtwork Net_Web-dev_NEtwork no-proxy-arp route-lookup description no NAT for packets going in same network

    translate_hits = 1489143, untranslate_hits = 45535

    Source - Origin: 172.21.0.0, Translated: 172.21.0.0

This one I was thinking about using to NAT from inside to the Web-DEV. Not enable (I did and nothing happened).

11 (inside) to (web-dev) source static Net-XXX-VPN-network Web-dev-PAT-inside  destination static Net_web-dev_NEtwork Net_web-dev_NEtwork no-proxy-arp inactive

    translate_hits = 0, untranslate_hits = 0

    Source - Origin: 10.11.xx.0/22, Translated: 172.21.xx.xx/32

    Destination - Origin: 172.21.0.0/16, Translated: 172.21.0.0

[Rob Ingram]

Is that the full output of the packet-tracer command?
What was the exact syntax of the packet-tracer command you ran?

[lopezportilla]

Hi Rob,

yes that’s all from the trace

i did like you said replacing the IP with 2 working IP within the 2 networks

best

carmelo