I recently had to setup a VPN site-to-site connection for a client between Azure and an on-premises environment, where a Cisco ASA 5525 was used.
By default I setup such connections as a route based connection but we could not make this work (the ASA admins didn’t have any experience with connection into the Cloud and especially with Azure).
After opening a ticket with Microsoft, we could see in the logs, that phase 1 and 2 were successful, but the following showed up as well (1.2.3.4 = on-prem public IP, 5.6.7.8 = Azure VPN gateway public IP, 172.16.106.226 = destination host on the on-prem side):
SESSION_ID :{1cc0a60b-d971-4b49-bfac-bace75c44c83} Remote 1.2.3.4:500: Local 5.6.7.8:500: Proposed(send) Traffic Selector payload will be- [Tsid 0x34c ]Number of TSIs 1: StartAddress 0.0.0.0 EndAddress 255.255.255.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 0.0.0.0 EndAddress 255.255.255.255 PortStart 0 PortEnd 65535 Protocol 0
So the Azure side propagated the complete available address range to route and as the ASA did not answer it followed up to propagate the VNet address range, where its gateway subnet was located in:
SESSION_ID :{e7070311-bf5b-46bb-af4e-1e514ab5fc18} Remote 1.2.3.4:500: Local 5.6.7.8:500: Proposed(send) Traffic Selector payload will be- [Tsid 0x34b ]Number of TSIs 1: StartAddress 10.221.240.0 EndAddress 10.221.240.255 PortStart 0 PortEnd 65535 Protocol 0 Number of TSRs 1:StartAddress 172.16.106.226 EndAddress 172.16.106.226 PortStart 0 PortEnd 65535 Protocol 0
So we needed to show a way to propagate the right source address range (10.220.8.32/29) on the Azure side. Therefore, we had to update the connection to Use policy based traffic selector and a custom traffic selector to tell the ASA which address ranges we were offering and expecting to connect to.
The final connection configuration looks like this:
