Microsoft Azure To Cisco ISR Router Site to Site VPN

KB ID 0001220 

Problem

Last week I was having problems getting a VPN up from a client’s Cisco ASA into Azure. This was because the Azure estate was using ‘route-based‘ or a ‘dynamic routing VPN‘. See the following article;

Azure to Cisco VPN – ‘Failed to allocate PSH from platform’

So the firewall was a non-starter, but Cisco ISR routers are supported, and they can handle virtual tunnel interfaces (VTI’s). So I used a Cisco ISR 1921 router, sat that beside the firewall, and gave that a public IP. Note: I did have to route the traffic to Azure, to use this router instead of the firewall but that’s easy. 

Now we just need to  get the VPN Tunnel up.

Cisco Router to Azure VPN

 

Solution

OK, before you get started your router needs to be able to support crypto/VPN’s. That means you should be running a ‘security’ license (show license should say you have a securityk9 licence installed and running, or K8 if you live in North Korea, or 1986). If you don’t, the router will not recognise any of the crypto commands.

To establish ‘Phase 1‘ of the VPN tunnel we need an IKE proposal. Note I’m using IKEv2, that is a requirement for route-based, or dynamic routing from Azure.

Petes-ISR#conf terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Petes-ISR(config)#crypto ikev2 proposal IKE-PROP-AZURE 
IKEv2 proposal should have atleast an encryption algorithm, an integrity algorithm and a dh group configured 
Petes-ISR(config-ikev2-proposal)# encryption aes-cbc-256 aes-cbc-128 3des 
Petes-ISR(config-ikev2-proposal)# integrity sha1 
Petes-ISR(config-ikev2-proposal)# group 2 
Petes-ISR(config-ikev2-proposal)# exit

Then add the proposal we created above to an IKEv2 Policy, (Note: a policy can have multiple proposals).

Petes-ISR(config)#crypto ikev2 policy IKE-POLICY-AZURE
IKEv2 policy should have atleast one complete proposal attached 
Petes-ISR(config-ikev2-policy)# proposal IKE-PROP-AZURE
Petes-ISR(config-ikev2-policy)# exit

Create a keyring, (in IKEv2 you can have multiple keys), and specify your VPN pre shared key, (PSK or shared secret).

Petes-ISR(config)#crypto ikev2 keyring KEYRING-AZURE
Petes-ISR(config-ikev2-keyring)# peer 40.113.16.195
Petes-ISR(config-ikev2-keyring-peer)# address 40.113.16.195
Petes-ISR(config-ikev2-keyring-peer)# pre-shared-key 1234567890asdfg
Petes-ISR(config-ikev2-keyring-peer)# exit
Petes-ISR(config-ikev2-keyring)# exit

Now all the ‘Phase 1‘ settings get tied together in a Phase 1 profile. (Note: GigabitEthernet0/0 is the public facing port, yours may be different).

Petes-ISR(config)#crypto ikev2 profile PROFILE-PH1-AZURE
% IKEv2 profile MUST have match identity or match certificate statements
Petes-ISR(config-ikev2-profile)# match address local interface GigabitEthernet0/0
Petes-ISR(config-ikev2-profile)# match identity remote address 40.113.16.195 255.255.255.255
Petes-ISR(config-ikev2-profile)# authentication remote pre-share
Petes-ISR(config-ikev2-profile)# authentication local pre-share
Petes-ISR(config-ikev2-profile)# keyring KEYRING-AZURE
Petes-ISR(config-ikev2-profile)# exit

For ‘Phase 2‘ (IPSEC) you create a ‘transform set’.

Petes-ISR(config)#crypto ipsec transform-set TRANSFORM-AZURE esp-aes 256 esp-sha-hmac
Petes-ISR(cfg-crypto-trans)# mode tunnel
Petes-ISR(cfg-crypto-trans)# exit

Then you tie all the ‘Phase 2‘ settings together with a ‘Phase 2’ profile, and link that back to the ‘Phase 1‘ profile.

Petes-ISR(config)#crypto ipsec profile PROFILE-PH2-AZURE
Petes-ISR(ipsec-profile)# set transform-set TRANSFORM-AZURE
Petes-ISR(ipsec-profile)# set ikev2-profile PROFILE-PH1-AZURE
Petes-ISR(ipsec-profile)# exit

You then need to create a tunnel, that will use all these settings.

Note: Yes you can use 169.254.x.x (I know it’s an APIPA address, but it will work fine).

Petes-ISR(config)#int tunnel 1
Petes-ISR(config-if)# ip address 169.254.0.1 255.255.255.0
Petes-ISR(config-if)# ip tcp adjust-mss 1350
Petes-ISR(config-if)# tunnel source GigabitEthernet0/0
Petes-ISR(config-if)# tunnel mode ipsec ipv4
Petes-ISR(config-if)# tunnel destination 40.113.16.195
Petes-ISR(config-if)# tunnel protection ipsec profile PROFILE-PH2-AZURE
Petes-ISR(config-if)# exit

Finally the router needs to ‘know’ that traffic destined for Azure is sent down the VPN tunnel.

Petes-ISR(config)#ip route 10.0.0.0 255.255.255.0 tunnel 1

Do I Need To Worry About NAT?

No, (even if you are doing NAT Overload). Unlike an IPSEC VPN on a firewall you do not need to exempt the traffic for the VPN, from NAT translation. That’s because it leaves the router through the tunnel interface and not the public facing interface.

Below are all the commands you can copy and paste and change accordingly;

Assumptions

192.168.100.0/24 is behind the router
10.0.0.0/16 is the Azure network
40.113.16.195 is the Azure Gateway IP
1234567890asdfg is the pre shared key
GigabitEthernet0/0 is the ‘public facing interface on the router’


!
access-list 101 permit ip 192.168.100.0 0.0.0.255 10.0.0.0 0.0.0.255
!
crypto ikev2 proposal IKE-PROP-AZURE
 encryption aes-cbc-256 aes-cbc-128 3des
 integrity sha1
 group 2
 exit
!
crypto ikev2 policy IKE-POLICY-AZURE
 proposal IKE-PROP-AZURE
 exit
!
crypto ikev2 keyring KEYRING-AZURE
 peer 40.113.16.195
   address 40.113.16.195
   pre-shared-key 1234567890asdfg
   exit
 exit
!
crypto ikev2 profile PROFILE-PH1-AZURE
 match address local interface GigabitEthernet0/0
 match identity remote address 40.113.16.195 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring KEYRING-AZURE
 exit
!
crypto ipsec transform-set TRANSFORM-AZURE esp-aes 256 esp-sha-hmac
 mode tunnel
 exit
!
crypto ipsec profile PROFILE-PH2-AZURE
 set transform-set TRANSFORM-AZURE
 set ikev2-profile PROFILE-PH1-AZURE
 exit
!
int tunnel 1
 ip address 169.254.0.1 255.255.255.0
 ip tcp adjust-mss 1350
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 40.113.16.195
 tunnel protection ipsec profile PROFILE-PH2-AZURE
 exit
!
ip route 10.0.0.0 255.255.255.0 tunnel 1

 

Related Articles, References, Credits, or External Links

Microsoft Azure To Cisco ASA Site to Site VPN

Author: PeteLong

Share This Post On

14 Comments

  1. Did you try to peer BGP with the Azure gateway? If so, can you provide a config example of that from both the Cisco isr and the azure config.

    Post a Reply
    • Hi – I have not, If anyone else would like to comment, I’ll post their findings.

      Pete

      Post a Reply
  2. why do you define access-list 101 without using it? i know it’s in the MS example config as well but it doesn’t make much sense. it would be needed for a crypto map – but you don’t use a crypto map.

    simply routing 10.0.0.0/24 via the tunnel is nice but how do you make sure that both ends agree on transporting only traffic between 192.168.100.0/24 and 10.0.0.0/24 (as would be clearly defined with a crypto map)? not only for security reasons but also because in your example the azure cloud has 10.0.0.0/16 defined. so it doesn’t really match.

    imagine a bigger company where they have a network department and a cloud department. the cloud guy adds another virtual network, IPSec is set up with new network proposal. but might be that that net is used somewhere else inside? yes, still no routing – but what if you did route the whole 10.0.0.0/16 you defined in azure instead of 10.0.0.0/24? wouldn’t like the idea of the things that could possibly go wrong.

    Post a Reply
    • Hi Bjoern,

      I sat and looked at this for a while, to answer you questions;

      Yes that ACL is redundant, I will have missed that because I’m usually on an ASA (with a crypto map).

      It’s essentially a GRE Tunnel you could make it more restrictive by changing the static route.

      Pete

      Post a Reply
      • You can Still use crypto map as below and not require a GRE tunnel:

        crypto map AZURE 10 ipsec-isakmp
        set peer 40.113.16.195
        set transform-set TRANSFORM-AZURE
        set ikev2-profile PROFILE-PH1-AZURE
        match address 101
        exit

        access-list 101 permit ip 192.168.100.0 0.0.0.255 10.0.0.0 0.0.0.255

        int gig 0/0
        crypto map AZURE

        Need to make sure on Azure side we have a mirror of ACL 101.

        Post a Reply
  3. Pete,
    Would the tunnel interface ip/subnet require that your client’s and Azure’s be on the same network?

    Post a Reply
  4. Any reason why you wouldn’t be able to access a site based https server from an Azure VM with this config? I cant get any http/https traffic to flow into Azure when it is initiated from there.

    Post a Reply
    • Not that I can think of, does the site based machine have a route back to the Azure subnet?

      Post a Reply
  5. Hi Pete.

    Why does the tunnel need a /24 IP address range (ip address 169.254.0.1 255.255.255.0) when the tunnel is terminated towards “interface GigabitEthernet0/0”?

    Post a Reply
    • I don’t think it does, to will probably work with a smaller subnet.

      P

      Post a Reply
  6. Would it be possible to get this config modified for using crypto map isntead?

    Post a Reply
  7. This config does not work on ASR or ISR to azure, it dies at trying to pick the proposals. If you notice the tunnel protection ipsec profile command on the tunnel vti, the profile never identifies the proposals – “crypto ikev2 proposal”

    Debug you get:

    NOTIFY(NO_PROPOSAL_CHOSEN)

    Mar 28 2023 14:06:14.026 MDT: IKEv2:(SESSION ID = 334939,SA ID = 1):Processing IKE_SA_INIT message
    Mar 28 2023 14:06:14.026 MDT: IKEv2-ERROR:(SESSION ID = 334939,SA ID = 1):: Received no proposal chosen notify
    Mar 28 2023 14:06:14.027 MDT: IKEv2:(SESSION ID = 334939,SA ID = 1):Failed SA init exchange

    Post a Reply

Leave a Reply to PeteLong Cancel reply

Your email address will not be published. Required fields are marked *