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.
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.
[box]
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
[/box]
Then add the proposal we created above to an IKEv2 Policy, (Note: a policy can have multiple proposals).
[box]
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
[/box]
Create a keyring, (in IKEv2 you can have multiple keys), and specify your VPN pre shared key, (PSK or shared secret).
[box]
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
[/box]
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).
[box]
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
[/box]
For ‘Phase 2‘ (IPSEC) you create a ‘transform set’.
[box]
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
[/box]
Then you tie all the ‘Phase 2‘ settings together with a ‘Phase 2’ profile, and link that back to the ‘Phase 1‘ profile.
[box]
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
[/box]
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).
[box]
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
[/box]
Finally the router needs to ‘know’ that traffic destined for Azure is sent down the VPN tunnel.
[box]
Petes-ISR(config)#ip route 10.0.0.0 255.255.255.0 tunnel 1
[/box]
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;
[box]
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
[/box]
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.
Hi – I have not, If anyone else would like to comment, I’ll post their findings.
Pete
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.
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
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.
Pete,
Would the tunnel interface ip/subnet require that your client’s and Azure’s be on the same network?
No not at all 🙂
P
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.
Not that I can think of, does the site based machine have a route back to the Azure subnet?
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”?
I don’t think it does, to will probably work with a smaller subnet.
P
Would it be possible to get this config modified for using crypto map isntead?
Yes configure the router and like this https://www.petenetlive.com/KB/Article/0000933 and the Azure end like this, https://www.petenetlive.com/KB/Article/0001515
P
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