cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5599
Views
0
Helpful
15
Replies

ASA 5506X Traffic flow between interfaces

OldSchoolTechie
Level 1
Level 1

Dear all,


I am on 9.6 and trying to get traffic flowing between two interfaces. These have the same security level and are permitted to talk
using same-sec intra|inter. There is no routing in place, meaning everything is directly connected. To cut it short, here's the layout:
inside=192.168.1.254; LTE=192.168.5.1; outside has public WAN IP. I want to establish traffic between inside and LTE as a
prerequisite for PBR.

Symptom:

I seem to be unable to get past the interface, that is - i CAN ping from "LTE" to hosts in that segment (and of course within "inside" as well).ICMP is permitted, yes - but I cannot get a ping across these.


There is no ACL on any interface (as per the docs, you don't need it if you have the same sec-level in place).
There is NAT exemption in place for 192.168.5.0 against the inside and outside and itself in place, as well for a few VPN pools and subnets (all fine). The packet tracer reveals the following, and I am at my wits end......perhaps s/o can have a look into it.

packet-tracer input inside tcp 192.168.1.254 http 192.168.5.10 http......

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.5.10 using egress ifc  LTE

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,LTE) source static inside_net inside_net destination static LTE LTE no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface LTE
Untranslate 192.168.5.10/80 to 192.168.5.10/80

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 192.168.1.254 using egress ifc  inside

Result:
output-interface: LTE
output-status: up
output-line-status: up
Action: drop


TIA+Brgds,

Dan

15 Replies 15

And there I fixed it.

The culprit was:

recursive next hop statement on policy

missing dynamic NAT entry from inside_net object to LTE.

Complete IP Stack works, 80/443 nicely separated and delivering a fair 120 MBit downstream as opposed to 3 before.

Review Cisco Networking products for a $25 gift card