ASA with route-based VPN to connect to Azure VPN Gateaway and BGP routing

Intro!

Hey guys, I made something work that was not supposed to work. However this guy deserves the credit (see this post).

Cisco ASA (or PIX... but that would not work for what I want to do)

Normally, a Cisco ASA (or PIX for the folks who were around a whily ago) allows "policy based" VPNs. Essentially, the difference between route based and policy based VPN is in the negociation of the "proxy" during the IKE negociation.

Policy based VPN

In the case of policy based VPN, both devices exchange their respective "encryption" domain. Matching encryption domain is one of the criterias it takes for the VPN to come up. In a Cisco router, creating that means writing ACL and matching these ACLs with a crypto map statement.

Route based VPN

In the case of route based VPN, the encryption domain is "any to any", or 0.0.0.0/0 to 0.0.0.0/0. This is where the tactic described here works very well! That served as a basis for what I wanted to do : connect using site to site (S2S) VPN BGP to my Azure virtual networks (VNets).

My setup

Since I have a cheap DSL connection at home AND a cheap router (not possible to add STATIC routes!!!), here's what I had to do to circumvent the fact that I do not have more than one public IP :



You get the idea...? The ASA thinks both its outside interfaces (OUTSIDE1 and VPN) are /25 networks BUT the DSL router thinks it's a /24. Now because of proxy arp taking place in VRF Outside router, when the DSL router sends a packet to destination 192.168.2.129 (remember, the DSL router thinks .129 is on its internal interface... so ARPs for that IP), the VRF OUTSIDE router (a VRF inside a L3 switch) responds to the ARP it with its own MAC address and forwards the packet to the VPN interface of the firewall (.129). So everyone is happy and the ASA thinks it has two distinct outside interfaces.

SO! The methodology described by Renato Morais works its magic here. Only, the DSL router had to have a DMZ host defined in order to send IKEv2 and IPSEC packet to the VPN interface of the ASA when the VPN connection is initiated from the outside (Azure Virtual Network Gateway).

Azure Connection

Now, for to allow ASA to connect to Azure using Route-Based VPN, you have to make sure you first read this on Microsoft's Azure Documentation web site.

First things first, it will require you to have a recent version of OS on your ASA as you can only connect to a VNET Gateway using IKEv2 as mentioned here (where the IPsec parameters are well described). I know I know, here, it says it's not going to work using the ASA. But if you did what I've told you earlier, it will work so don't worry. So update your ASA and check on Cisco's web site to see which version is required to run IKEv2. And maybe BGP but I decided to do BGP from my internal L3 switch.

Cisco ASA configuration

Here's snippet of the relevant configuration on my ASA :

! Outside interface...
interface Vlan2
 description outside
 nameif outside
 security-level 0
 ip address 192.168.2.6 255.255.255.128
! VPN outside interface...
interface Vlan21
 description outside-vpn for Azure
 nameif vpn
 security-level 0
 ip address 192.168.2.129 255.255.255.128
!
<snip>
! Defines interesting traffic for the VPN... ANY to ANY - unusual on a ASA.
access-list vpn-VRF-DEV line 1 extended permit ip any4 any4
!
route outside 0.0.0.0 0.0.0.0 192.168.2.1 1
route vpn 137.117.103.130 255.255.255.255 192.168.2.130 1
! THIS IF FOR THE AZURE ADDRESS SPACE OF YOUR VNET(s)
route vpn 192.168.0.0 255.255.0.0 192.168.2.130 1
! THIS IS FOR STUFF INSIDE YOUR NETWORK
route inside 192.168.32.0 255.255.248.0 192.168.38.2 1
!
<snip>
! phase 1 IPSEC stuff
crypto ipsec ikev2 ipsec-proposal ESP-AES-256-SHA
 protocol esp encryption aes-256
 protocol esp integrity sha-1
!
<snip>
!
crypto map VPN-VRF-DEV 10 match address vpn-VRF-DEV
crypto map VPN-VRF-DEV 10 set pfs
crypto map VPN-VRF-DEV 10 set peer <AZURE GW IP>
crypto map VPN-VRF-DEV 10 set ikev2 ipsec-proposal ESP-AES-256-SHA
! enable this on the VPN interface
crypto map VPN-VRF-DEV interface vpn
!
<snip>
! these are part of the parameters described here
crypto ikev2 policy 50
 encryption aes-256 aes
 integrity sha
 group 2
 prf sha
 lifetime seconds 10800
! enable this on the VPN interface, no need to enable it on the outside interface
crypto ikev2 enable vpn
! now is the time for key configurations...
tunnel-group <AZURE GW IP> type ipsec-l2l
tunnel-group <AZURE GW IP> ipsec-attributes
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****
!
And voilà! your VPN should be UP... when the next step is done. You can reverse the order, whatever floats your boat.

Azure virtual network gateway

You need to configure the VPN GW in Azure for everything to work. I suggest you follow the guide here. My colleague does a great job at describing how you should go about it.

I would point out that the Local Network Gateway that you create in Azure needs only to be the /32 address of the BGP peer that you're going to be running internally. In my case, it was 192.168.38.2, the L3 switch IP.

Once the VPN is established, make sure you can ping the Azure GW IP (see end of part 1, here, for how to obtain the internal IP of the GW in Azure) from the IP of the device you'll end your BGP session on (doing a ping a.b.c.d source vlan38 or some other command...). Once that works, you`re good to go. Your VPN should go up and the BGP sessions are ready to come up. BUT your BGP ought to be well configured... one thing you want to make sure is that you use ebgp-multihop configuration :

router bgp 65050
 bgp log-neighbor-changes
 neighbor 192.168.228.254 remote-as 65010
 ! That's the one you have to make sure you do
 neighbor 192.168.228.254 ebgp-multihop 255
 neighbor 192.168.228.254 update-source vlan38
 !
 address-family ipv4

  ! this is how you choose what you inject to Azure
  redistribute static  neighbor 192.168.228.254 activate
  neighbor 192.168.228.254 prefix-list azure-prefix in
  ! THAT IS NOT SUPPORTED in AZURE
  default-information originate
  no auto-summary
  no synchronization
  network 192.168.224.0 mask 255.255.240.0
  network 192.168.224.0
 exit-address-family

I'm NOT using an ASA, but a CSR, an ASR or an ISR. What should I do?

Essentially the same. However when you define the VTI tunnel, I believe you can put any address on the device (the scripts given here and here even say 169.254.0.1 but the essence is to at least have the route to your networks go towards that tunnel interface. I didn't test it myself, I'd love to but I don't have access to these devices. I wish I did. BUT I will try it with a CSR router inside another VNET and inside the SAME VNET as a person I've talked with suggested to do. It does not feel right but I will try it.