07-07-2016 08:05 AM - edited 03-12-2019 01:00 AM
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
07-07-2016 01:19 PM
First off, you do not need to have the NAT exempt, infact I would remove the inside to LTE NAT exempt all together.
Could you post a full running config (remember to remove any public IPs, usernames and passwords)?
you are correct in stating that you should not need an ACL on the interface if you have the same-security-traffic permit inter-interface (between two interfaces with same security level) and same-security-traffic permit intra-interface (hairpinning traffic on a single interface regardless of security level).
do the two subnets connect to the same switch?
does the switch have vlans configured with IPs in the two VLANs? If so are these VLANs in different VRFs?
--
Please remember to select a correct answer and rate helpful posts
07-07-2016 11:59 PM
Marius,
first off, thanks for taking your time for looking into that, really appreciate it.
Here's a sanitized running config. I posted the main Networking part which I suspect to contain the culprit. The crypto stuff and the likes of ssh etc. were omitted for reasons of clarity. I initially spoke of PBR which is configured here but not "switched on" an Interface because I lack the requirements for it; PBR would direct packets to a dead end.
Background Info, also answering your questions:
192.168.[3,4,7].0 are remote VPN Networks.
192.168.1.0/24 is the inside. Hangs off a small GiE Switch.
192.168.5.0 is the LTE Segment.
The LTE unit is wired using CAT6 cable straight 1:1 to giE3/1. No switching here.
07-08-2016 02:59 AM
You have some accessories lists configured. Are you sure that the LTE-WAN acl is not assigned to the LTE interface?
--
Please remember to select a correct answer and rate helpful posts
07-08-2016 03:42 AM
As you can see, there is no access-group on the Interface - that means no ACL is in effect. The LTE_WAN ACL you see is intended for PBR control.
07-08-2016 07:52 AM
your packet-tracer is incorrect. You are using a source IP of the inside interface which is why it is failing. try it using 192.168.1.10 for example.
How are you testing traffic between the two subnets? Ping?
--
Please remember to select a correct answer and rate helpful posts
07-09-2016 01:59 AM
Marius, you cannot use the PT on Interfaces other than those you have on the Hardware; to my Knowledge it is unable to intercept stuff coming thru the ASA.
Anyway, testing back and forth using ping between LTE and inside -> no avail.
And yes, ICMP is permitted.
07-09-2016 02:22 AM
First off packet-tracer only simulates a packet passing through the ASA and because traffic can not be simulated using an ASA asigned IP you need to use a different IP than that is configured on the ASA interface.
If these are Windows machines have you turned off the windows firewall while testing?
Please post the packet tracer output using IPs other than that is configured on the ASA interfaces.
If this still fails and windows firewall is turned off please post a full running config of your ASA.
--
Please remember to select a correct answer and rate helpful posts
07-11-2016 07:31 AM
Sorry for being late re. the weekend.
Please find below what the PT yields. Interesting enough - upon pinging manually - I can observe (using deb ic tr ) only the request from .1.2 to 5.10 but nothing comes back. Pinging from 5.1. to 5.10 yields request and reply. And yes, the windows F/W is of course off (deactivated) and no other security software is out there.
packet-tracer input inside icmp 192.168.1.2 8 0 192.168.5.10 detailed
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/0 to 192.168.5.10/0
Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.2 using egress ifc inside
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,LTE) source static inside_net inside_net destination static LTE LTE no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.1.2/0 to 192.168.1.2/0
Forward Flow based lookup yields rule:
in id=0x7fe99f7d2a60, priority=6, domain=nat, deny=false
hits=14, user_data=0x7fe9a0f68610, cs_id=0x0, flags=0x0, protocol=0
src ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=192.168.5.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=LTE
Phase: 5
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe9a0e40510, priority=2, domain=permit, deny=false
hits=26, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe99ec89c40, priority=0, domain=nat-per-session, deny=true
hits=624702, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe99f77c9c0, priority=0, domain=inspect-ip-options, deny=true
hits=258460, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe99f77c1d0, priority=66, domain=inspect-icmp-error, deny=false
hits=3717, user_data=0x7fe99f77b740, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 9
Type: DEBUG-ICMP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fe9a0cf3030, priority=13, domain=debug-icmp-trace, deny=false
hits=3715, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,LTE) source static inside_net inside_net destination static LTE LTE no-proxy-arp route-lookup
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fe9a1123a50, priority=6, domain=nat-reverse, deny=false
hits=15, user_data=0x7fe9a0f6c0a0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=192.168.1.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=192.168.5.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=LTE
Phase: 11
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fe9a0ce3330, priority=0, domain=user-statistics, deny=false
hits=111, user_data=0x7fe9a06910d0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=LTE
Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 308937, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_dbg_icmp
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Module information for reverse flow ...
Result:
output-interface: LTE
output-status: up
output-line-status: up
Action: allow
07-11-2016 01:32 PM
Please post a full running config (please remember to remove any public IPs, usernames and passwords).
--
Please remember to select a correct answer and rate helpful posts
07-12-2016 01:38 AM
07-12-2016 12:15 PM
Add the following:
policy-map global_policy
class inspection_default
inspect icmp
Then you should be able to ping between the two subnets.
--
Please remember to select a correct answer and rate helpful posts
07-12-2016 01:00 PM
FAIL. Same behavior as before. Can observe request, no echo (from 192.168.1.1 -> 5.10 ), can observe request AND echo from 5.1. to 5.10
07-12-2016 01:16 PM
set up a capture on the LTE interface.
cap CAPLTE interface LTE match ip host 192.168.1.1 host 192.168.5.10
If you see the the packet exit the LTE inter face i.e you see an entry for 192.168.1.1 towards 192.168.5.10 but nothing coming back then the issue is on 192.168.5.10 or the network between this PC/server and the ASA.
--
Please remember to select a correct answer and rate helpful posts
07-12-2016 01:31 PM
Here goes:
4 packets captured
1: 22:27:29.674907 192.168.1.1 > 192.168.5.10: icmp: echo request
2: 22:27:34.244814 192.168.1.1 > 192.168.5.10: icmp: echo request
3: 22:27:39.252809 192.168.1.1 > 192.168.5.10: icmp: echo request
4: 22:27:44.244387 192.168.1.1 > 192.168.5.10: icmp: echo request
Makes me go bonkers, Marius. Never observed anything similar before.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide