Re: ASA VTI - incorrect ipsec SA

LordBoBCUP · ‎08-13-2021

Hi,

I have an ipsec route based site to site VPN however the ipsec SA's look incorrect and only include a subset of routes passing across it.

We have a hub and spoke setup, the hub site has one route based VPN to our remote office (Spoke A), traffic passes from that spoke to the hub no problem at all. I have another spoke (Spoke B) (one of our clients networks) which provides us access to some resources. Accessing this from the Hub is fine, working as expected. Accessing this from our remote spoke doesn't work.

When looking at sh cry ipsec sa peer (Spoke B IP) I see only one SA (and not 0.0.0.0/0 as I would expect) but a specific route which only includes address space from our Hub site not the remote spoke. I suspect (but this is what I don't fully know) but I _believe_ that this is coming from the configuration on the client spoke during negotiating of that tunnel. Can someone confirm that this is likely the case? As I understand it in the ASA (9.7.1) you cannot set a profile policy on ipsec on the tunnel configuration so you can only have the default which is to try and negotiate 0.0.0.0/0. Seeing the specific route for the SA (172.20.0.0/20 - 10.230.0.0/22) but I cant see that in any config on my side, is throwing me off as to why this hub/spoke config is not working as expected.

Thanks in advance

Karsten Iwen · ‎08-13-2021

What you see can be cause by the configuration of the other side of the tunnel. If they configured a policy-based VPN, then the ASA (same with IOS routers) negotiates down to the networks the other side proposes. Can you summarize your Hub and spoke networks into one entry? Then ask them to use this summary. If not, you have to ask them to move to "any" or if they can't, migrate to policy-based VPN on your side.

LordBoBCUP · ‎08-13-2021

Thanks @Karsten Iwen we did supply the two subnets we wanted to utilize over the network. I know they are using a Fortinet device of some kind but not sure if they are using policy-based or route based. I'll contact them next week to follow up an ensure they have configured our second subnet and its not just a misconfiguration on their side.

If I was to move to a policy-based VPN on my side (for both my hub and my spoke), other than configuring the config map, with the ACL that has interesting traffic, and NAT exemptions, is there anything special I have to do to ensure the hub routes the traffic to the spokes correctly?

Karsten Iwen · ‎08-13-2021

If you provided them two subnets, they certainly configured a policy-based VPN. With route-based VPNs you typically only have one subnet (like "any") and the IP routing controls if traffic is sent to the tunnel or not.

For moving to policy-based VPNs, controlling the NAT-exemption is typically the most critical task. For the crypto-ACL, make sure that your local part includes your hub- *and* the spoke subnet.