EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

AF

Azure Point to Site VPN & Its Routing

Azure Point to Site VPN & Its Routing

Posted on Sep 06, 2022 (0)

Point to Site VPN

A Point to Site VPN is used to provide a secure connection from individual client computer to Azure Virtual network.

Point to Site VPN uses one of the below following protocols:

Open VPN Protocol: It is a SSL/TLS based VPN protocol, can penetrate firewall on TCP port 443 outbound. This protocol is used to connect from Android, iOS (Version 11.0 and above), Windows, Linux, and Mac devices.

Secure Socket tunnelling protocol (SSTP):  It is a proprietary TLS based VPN protocol, which can penetrate firewall on TCP port 443 outbound. SSTP is only supported on Windows Devices. Azure supports all versions of Windows that have SSTP and support TLS 1.2 (Windows 8.1 and later).

IKEv2 VPN: It is standard protocol for Ipsec VPN solution. IKEv2 VPN can be used to connect Mac devices (MacOS version 10.11 and above).

IKEv2 and OpenVPN is only available option for resource manager deployment Model.

P2S VPN Client Authentication

Any user have to authenticates first, then only VPN tunnel is established. There are three options available that Azure offers to authenticate a connecting user.

Native Azure Certificate Authentication:

In this method, A client certificates present on Client device is used to authenticate the connecting user. Client certificates are generated from a trusted root certificate and is then installed on each client computer, or even a self-signed certificate can also be generated.

Client certificates are validated by VPN gateway, and this happens during establishment of P2S VPN connection. For this root certificate is required and must be uploaded to Azure.

Azure Active Directory Authentication:

Azure AD Authentication allow users to connect to Azure using Azure Active directory credentials. OpenVPN protocol only supports Azure AD Authentication and Windows 10 and later also requires use of the Azure VPN client.

With this method, you can leverage Azure AD conditional access as well as Multi-factor Authentication feature for VPN.

Active Directory Domain Server Authentication:

AD domain authentication allows users to connect to Azure using their organization domain credentials, for this it requires the RADIUS server that integrates with AD Server.

RADIUS server can be deployed on-premises or in your Azure VNet. During Authentication Azure VPN gateway acts as a pass through and forwards authentication message back and forth between RADIUS Server and Connecting device. If the RADIUS server is present on-premises then a VPN S2S connection from Azure to the On-premises must be required for reachability.

Below figure explains Architecture when RADIUS server is on Premises.

Below are details of Gateway SKU that supports P2S VPN

Below table shows observed bandwidth and packets per second throughput per tunnel for different Gateway SKU. All testing was performed between gateways (endpoints) within Azure across different regions with 100 connections and under Standard Load conditions.

Point-to-Site VPN Routing

There are various scenarios, which we are going to discuss and learn about P2S VPN Routing.

Use-Case 1: One isolated Vnet:

Refer below diagram to understand the Scenario:

In this scenario, P2S VPN Gateway is connected for Vnet which is not connected or Peered to Vnet1.

Route to be Added:

  • Route added to Windows Clients 10.1.0.0/16, 192.168.0.0/24
  • Route added to non-Windows Clients: 10.1.0.0/16, 192.168.0.0/24

Access:

  • Windows client can access Vnet1
  • Non-Windows Client can access Vnet1

Use-case 2: Multiple Peered VNets:

Refer below diagram to understand the Scenario:

In this Scenario, P2S VPN gateway connection is for Vnet1 , Vnet1 is peered with Vnet2 , Vnet2 is peered with Vnet3. Vnet1 is peered with Vnet4. There is no direct peering with Vnet1 and Vnet3. Vnet1 has “Allow gateway transit” and Vnet2 and Vnet4 have “Use remote gateway” enabled.

Route Added:

  • Route added to Window client: 10.1.0.0/16, 10.2.0.0/16, 10.4.0.0/16, 192.168.0.0/24.
  • Route added to non-Windows Client: 10.1.0.0/16, 10.2.0.0/16, 10.4.0.0/16, 192.168.0.0/24.

Access

  • Windows Clients can access Vnet1, Vnet2, Vnet4, but VPN client must be downloaded again for any topology changes to take effect.
  • Non-Windows clients can access Vnet1, Vnet2 and Vnet4.

Use-Case 3 Multiple VNets connected using S2S VPN

Refer below diagram to understand the Scenario:

In this Scenario, P2S VPN gateway is connected to Vnet1. Vnet1 is connected to Vnet2 using S2S VPN. Vnet2 is connected to Vnet3 using S2S VPN. There is no direct peering or S2S VPN connection between Vnet1 and Vnet3. All Site-to-Site VPN connection are not running BGP for Routing.

Routes Added:

  • Routes added to windows client: 10.1.0.0/16, 192.168.0.0/24
  • Routes added to non-Windows Clients: 10.1.0.0/16, 10.2.0.0/16, 192.168.0.0/24

Access:

  • Windows clients can only access Vnet1
  • Non-Windows Clients can access Vnet1 Only.

 

Use-Case 4 Multiple VNets connected using S2S VPN with BGP

Refer below diagram to understand the Scenario:

In this Scenario, P2S VPN gateway is connected to Vnet1. Vnet1 is connected to Vnet2 using S2S VPN. Vnet2 is connected to Vnet3 using S2S VPN. There is no direct peering or S2S VPN connection between Vnet1 and Vnet3. All Site-to-Site VPN connection are running BGP for Routing.

Routes Added:

  • Routes added to windows client: 10.1.0.0/16, 192.168.0.0/24
  • Routes added to non-Windows Clients: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 192.168.0.0/24

Access:

  • Windows clients can only access Vnet1, Vnet2, Vnet3, but route to Vnet2 and Vnet3 will have to manually added.
  • Non-Windows Clients can access Vnet1, Vnet2, Vnet3.

Use-case 5: One Vnet and One Branch Office Connection:

Refer below diagram to understand the Scenario:

 The P2S VPN gateway connection is for Vnet1. Vnet1 is not connected/Peered with any other Virtual network but is connected to an on-premises Site via Site-to-Site Connection and that is not running BGP.

Routes added:

  • Routes added to Windows Client: 10.1.0.0/16, 192.168.0.0/24
  • Routes added to Non-Windows Client: 10.1.0.0/16 , 192.168.0.0/24

Access:

  • Windows Clients can access only Vnet1.
  • Non-Windows Clients can access Vnet1 Only.

Use-case 6: One Vnet and a Branch Office via BGP.

Refer below diagram to understand the Scenario:

The P2S VPN gateway connection is for Vnet1. Vnet1 is not connected/Peered with any other Virtual network but is connected to an on-premises Site via Site-to-Site Connection and that is running BGP.

Routes added:

  • Routes added to Windows Client: 10.1.0.0/16, 192.168.0.0/24
  • Routes added to non-Windows Client: 10.1.0.0/16, 192.168.0.0/24, 10.101.0.0/16

Access:

  • Windows Clients can access only Vnet1 and Site 1, but routes to Site1 will have to manually added.
  • Non-Windows Clients can access Vnet1 and Site 1.

Use-case 7: Multiple VNets Connected to S2S and a branch office

Refer below diagram to understand the Scenario:

P2S VPN Gateway is connected to Vnet1. Vnet1 is connected to Vnet2 using S2S VPN and Vnet2 is connected to Vnet3 using Site to Site VPN. There is no direct peering or S2S VPN between Vnet1 and Vnet3. Vnet3 is connected to branch office (Site1) using Site to Site VPN Connection. All VPN Connection is not running BGP.

Route Added:

  • Routes added to Windows Client: 10.1.0.0/16 , 192.168.0.0/24
  • Route Added to Non-Windows Clients: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 10.101.0.0/16, 192.168.0.0/24.

Access:

  • Windows Clients can access only Vnet1.
  • Non-Windows Clients can access Vnet1 Only.

Use-case 8: Multiple VNets Connected to S2S and a branch office (BGP).

Refer below diagram to understand the Scenario:

P2S VPN Gateway is connected to Vnet1. Vnet1 is connected to Vnet2 using S2S VPN and Vnet2 is connected to Vnet3 using Site to Site VPN. There is no direct peering or S2S VPN between Vnet1 and Vnet3. Vnet3 is connected to branch office (Site1) using Site to Site VPN Connection. All VPN Connection is running BGP.

Route Added:

  • Routes added to Windows Client: 10.1.0.0/16 , 192.168.0.0/24
  • Route Added to Non-Windows Clients: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 10.101.0.0/16, 192.168.0.0/24.

Access:

  • Windows Clients can access only Vnet1, Vnet2, Vnet3 and Site 1. Bute Routes to Vnet1, Vnet2, Vnet3, and Site 1 must be manually added to the Client.
  • Non-Windows Clients can access Vnet1, Vnet2, Vnet3 and Site1 Only.

Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.