ASA route-based VPN to Azure with multiple on-prem subnets only includes first subnet

[DavidParker35087]

I have an issue with an IKEv2 route-based tunnel from an ASA Version 9.8(4)20 to Azure. On the Azure end, we have two address spaces defined for our local network. On the ASA end, we send all traffic destined for our one network in Azure through the tunnel. This works fine so long as the ASA end is the Initiator. The problem is that when the tunnel drops and the Azure end becomes the Initiator, only the first subnet listed in our Address space gets incorporated into the tunnel. The other traffic is dropped.

Azure:

LocalNetwork (on-prem)

10.0.0.0/8

172.16.10.0/24

ASA:

all traffic destined for Azure

10.20.0.0/16

ASA Initiator:

sh crypto ikev2 sa                 

IKEv2 SAs:

Session-id:512843, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                                  Status         Role

2932040661 168.39.0.54/500                                     52.238.73.64/500                                         READY    INITIATOR

      Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK

      Life/Active Time: 86400/15 sec

Child sa: local selector  0.0.0.0/0 - 255.255.255.255/65535

          remote selector 0.0.0.0/0 - 255.255.255.255/65535

Azure initiator:

sh crypto ikev2 sa

IKEv2 SAs:

Session-id:512841, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                                  Status         Role

2925279193 168.39.0.54/500                                     52.238.73.64/500                                         READY    RESPONDER

      Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK

      Life/Active Time: 86400/8694 sec

Child sa: local selector  10.0.0.0/0 - 10.255.255.255/65535

          remote selector 10.20.0.0/0 - 10.20.15.255/65535

Using the route-based tunnel I don't think I can make the traffic selectors match. If I switch the order of the subnets on the Azure end, the first one is the only one added to the tunnel. I've been working with Azure support, but I'm not making much headway. We thought about adding an NSG to prevent Azure end from initiating the tunnel, but it seems like more of a hack than a solution.

I'm thinking there has to be a better way. Surely there are other Azure customers that need to send multiple subnets across a route-based tunnel to an ASA?

[Rob Ingram]

Hi, This is a route based VPN not a policy based VPN, you need to define static routes with the tunnel interface as the next hop.

FYI, your hash and DH group are weak, you should consider using stonger ciphers....these older ciphers are being depreciated in newer code.

HTH

[DavidParker35087]

I am working on trying to upgrade the encryption. Following the Azure template, choosing the following the tunnel will never establish.

crypto ipsec ikev2 ipsec-proposal AZURE-PROPOSAL

 protocol esp encryption aes-256

 protocol esp integrity sha-256

I get something like:

IKEv2-PROTO-1: (1157): Failed to find a matching policy

IKEv2-PROTO-1: (1157): Expected Policies:

ESP: Proposal 0:  AES-CBC-256 SHA256 Don't use ESN

So I backed off the sha-1 for now.

On the ASA end, the static route works beautifully, so long as the ASA becomes the Initiator. It is the Azure end I'm having difficulty with when it is the Initiator. My understanding is in Azure, the routing is controlled by the subnets listed in the local network gateway. Only the first network gets incorporated into the selector from the ASA's perspective.

[Ruben Cocheno]

@DavidParker35087 

A couple of consideration here...

You have a clash on your subnets local/remote 10./8 and 10.20/16

since you running a code higher than 9.7, route based VPN is prefered

Due some issues that Public cloud sends out 0.0.0.0 0.0.0.0, which you can control on the ASA side using vpn-filter just to send specific subnets, but beware if you are using NAT

You can always run BGP on top of it, if you aare looking at some some using Express Route, so you job is done.

[DavidParker35087]

I am aware that the address space overlaps, but if I were to break out all the subnets in Azure for my on-prem networks, I'd be in worse shape than I am now. I can't get Azure to Initiate the tunnel for more than one subnet now. Its like Azure is claiming to use a route-based VPN, but in reality, when it is the Initiator, it is building traffic selectors based upon the networks listed you want to send across the tunnel. So it isn't really routing, or, it does add a route but also builds a traffic selector based upon the first subnet you happen to have listed in your local networks, so nothing else will cross the tunnel. If I swap the order of the networks listed in Azure, it only selects traffic for the first one in the list when it is the Initiator. When the ASA is the initiator, everything is golden.

[Ruben Cocheno]

@DavidParker35087 

Done a setup recently with Palo, and i used BGP due the customer using Express Route, so the VPN was solely to be the Backup Path. After many faailover tests, everything waas working smootly.

[DavidParker35087 · Accepted solution]

I think I have a solution. Even though the Azure VPN was setup as a route-based tunnel, it was configured to UsePolicyBasedTrafficSelectors $True. This is causing the first subnet listed in the address space on the local network to be used in the traffic selector. I need to change this value to $False during the next maintenance window and it should use 0.0.0.0 as the traffic selector then route the tunnels in the address space across the tunnel.

[DavidParker35087]

The problem is sorted out. It was caused by a Frankenstein hybrid route/policy based tunnel on the Azure end. We experienced the same symptoms when the ASA was configured as policy based VPN. 

Oh well. I wouldn't have learned as much about route-based tunnels or configuring Azure VPN if everything had worked correctly from the beginning.