08-23-2018 08:01 AM - edited 02-21-2020 08:08 AM
Hi all,
I am having some problems with a spoke-hub-spoke setup and I'm really stumped. Hopefully some knowledgeable person can help me out...
I have three sites: a hub and spokes A and B. Site-to-site VPNs are configured between spoke A and the hub, and spoke B and the hub. The hub can communicate with each spoke, but they can't communicate with each other.
Things I have already done:
Spoke A ASA: added the spoke B subnets to the interesting traffic and no-NAT
Spoke B ASA: added the spoke A subnets to the interesting traffic and no-NAT
Hub ASA: configured same-security-traffic inter-interface; configured no-NAT from the spoke A subnets to the spoke B subnets on the outside interface
The only routing in place on the hub ASA is 0.0.0.0 to the outside interface.
Using the command show crypto sa peer <peer ip> on the hub ASA, I can see that traffic for spoke B is arriving from spoke A and being de-encapsulated, but not being encapsulated and sent to spoke B. Same for traffic from spoke B to spoke A.
I will post santised configs if required, but is there anything I could have missed?
Many thanks
Alex
08-23-2018 09:06 AM - edited 08-23-2018 09:07 AM
Spoke A ASA: added the spoke B subnets to the interesting traffic and no-NAT
Spoke B ASA: added the spoke A subnets to the interesting traffic and no-NAT
Hub ASA: configured same-security-traffic inter-interface; configured no-NAT from the spoke A subnets to the spoke B subnets on the outside interface
Did you add Spoke A subnet as local network interesting traffic for Spoke B tunnel and vice versa on the hub? The ACL's should be mirror images on both sides.
08-24-2018 12:46 AM
Hi Rahul, yes I did. I forgot to incude that, sorry!
08-23-2018 10:00 AM
08-24-2018 01:21 AM
Hi Mohammed,
I have tried packet tracer before but it doesn't always give accurate results. For example: the screenshot below is on the Spoke A ASA, and it shows traffic from the Hub ASA local subnet being dropped, which isn't what really happens.
Is it correct to choose the Outside interface when packet tracing inbound VPN traffic?
Many thanks
Alex
08-24-2018 02:42 AM
You need to have active sa before running packet trace to match vpn encrypt action. Also, i asked for a trace from sub-A to sub-B and vice versa which matches your subnet
08-24-2018 03:23 AM
Ok, point taken! Here are the results of Spoke A to Spoke B:
Spoke A ASA: Packet allowed
Hub ASA: Packet dropped
And here are the results of Spoke B to Spoke A:
Spoke B ASA: Packet allowed
Hub ASA: Packet dropped
Those results echo what I have seen in the VPN tunnel stats on the hub. Traffic from Spoke A to Spoke B and vice-versa has 0 encapsulated packets.
Regards
Alex
08-24-2018 04:57 AM
08-24-2018 06:38 AM
Sure, here you are:
Result of the command: "packet-tracer input outside icmp 10.25.1.180 8 0 10.12.12.180 detailed"
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via 217.33.171.225, outside
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static EU_Networks EU_Networks destination static NA_Networks NA_Networks no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.12.12.180/0 to 10.12.12.180/0
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff35bbcdd0, priority=11, domain=permit, deny=true
hits=48241194, user_data=0x5, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=outside, output_ifc=any
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
08-24-2018 06:56 AM
Try "packet-tracer input outside icmp 10.25.1.180 8 0 10.12.12.180 detailed decrypted"
If you don't use "decrypted" , packet-tracer assumes that it is non-vpn traffic sourced from the outside interface. This usually hits the inbound ACL on the outside interface. VPN traffic by default bypasses this ACL, so you have to use the decrypted keyword to simulate that.
Also, share a sanitized version of the relevant configs (crypto map, acl, NAT) from all 3 sites if possible.
08-24-2018 07:48 AM
Unfortunately 'decrypted' doesn't work - from the Cisco command reference, it was only introduced in IOS 9.9.(1) and we are currently running 9.2(2)4. I will arrange an upgrade, but in the meantime I will work on the sanitised configs. I will update the thread as soon as I can! Many thanks for your help so far.
Alex
09-04-2018 07:41 AM
09-10-2018 03:48 AM
Hi Rahul,
I posted the sanitised configs above. I'd be hugely grateful if you could take a look over them as I am truly baffled as to why this is not working.
Unfortunately I haven't been able to update to IOS 9.9 yet as this is a production environment.
Regards
Alex
09-14-2018 06:38 AM
Config looks correct to me.
Can you get the output of "show crypto ipsec sa" from the hub? Also, try running the following debugs on the hub to see if it is attempting to establish a phase 2 tunnel.
debug crypto condition peer x.x.x.x
debug crypto ikev1 127
debug crypto ipsec 127
09-14-2018 07:44 AM
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