Microsoft Azure To Cisco ISR Router Site to Site VPN

KB ID 0001220 


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



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
Petes-ISR(config-ikev2-keyring-peer)# address
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
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
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
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 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 is behind the router is the Azure network 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
crypto ikev2 proposal IKE-PROP-AZURE
 encryption aes-cbc-256 aes-cbc-128 3des
 integrity sha1
 group 2
crypto ikev2 policy IKE-POLICY-AZURE
 proposal IKE-PROP-AZURE
crypto ikev2 keyring KEYRING-AZURE
   pre-shared-key 1234567890asdfg
crypto ikev2 profile PROFILE-PH1-AZURE
 match address local interface GigabitEthernet0/0
 match identity remote address
 authentication remote pre-share
 authentication local pre-share
crypto ipsec transform-set TRANSFORM-AZURE esp-aes 256 esp-sha-hmac
 mode tunnel
crypto ipsec profile PROFILE-PH2-AZURE
 set transform-set TRANSFORM-AZURE
 set ikev2-profile PROFILE-PH1-AZURE
int tunnel 1
 ip address
 ip tcp adjust-mss 1350
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination
 tunnel protection ipsec profile PROFILE-PH2-AZURE
ip route tunnel 1


Related Articles, References, Credits, or External Links

Microsoft Azure To Cisco ASA Site to Site VPN

Author: PeteLong

Share This Post On


  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.


      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 via the tunnel is nice but how do you make sure that both ends agree on transporting only traffic between and (as would be clearly defined with a crypto map)? not only for security reasons but also because in your example the azure cloud has 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 you defined in azure instead of 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.


      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
        set transform-set TRANSFORM-AZURE
        set ikev2-profile PROFILE-PH1-AZURE
        match address 101

        access-list 101 permit ip

        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 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.


      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:


    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

Submit a Comment

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