question

TXSDEV-6118 avatar image
0 Votes"
TXSDEV-6118 asked mi1an edited

Point-to-Site VPN Peering

I have the following setup and need assistance with routing

Ultimate end goal of all of this is to allow Azure Files to be accessible on a non domain joined Windows 10 PC to authenticate using Azure AD (synced on from on prem AD in DR vNet). I'm able to successfully connect & authenticate to Azure Files on domain joined PC however for SMB traffic to be allowed for remote/home PC's an Azure P2S route was recommended but as of now I'm unable to successfully authenticate while connected to Azure Point to Site VPN because I don't have line of sight to my Azure VM running AD DS in DR vNet (192.168.39.0/24) network?

Virutal Network#1
DR
address space 192.168.39.0/24
DR subnet 192.168.39.128/25
GatewaySubnet 192.168.39.0/29
VM with AD DS role (192.168.39.100)
DR-P2S Peering enabled with Gateway Transit Enabled
This network also has a policy based VPN to on prem

Virutal Network#2
P2S
address space 10.0.0.0/16
default 10.0.0.0/24
GatewaySubnet 10.0.1.0/24
P2S-DR Peering enabled 192.168.39.0/24 with gateway transit enabled


Virtual Network Gateway with Point-to-Site configuration
Route-based with P2SvNet virtual network
Address Pool 10.1.1.0/24

Client Windows 10 Machine
Azure VPN Marketplace client software successfully connects to the P2SVNet gets an ip address in space 10.1.1.2 and can connect to 10.0.0.0/16 space however it does not connect to 192.168.39.0/29 network

I can ping and rdp to resources on 10.0.0.0/16 vNet but no luck with DR route.













azure-vpn-gatewayazure-files
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

GitaraniSharmaMSFT-4262 avatar image
0 Votes"
GitaraniSharmaMSFT-4262 answered GitaraniSharmaMSFT-4262 commented

Hello @TXSDEV-6118 ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

If you have enabled Vnet peering after the P2S configuration and are using a windows machine, then the VPN client must be downloaded again for the peered Vnet routes to be propagated to your local machine.
Please refer : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing#multipeered

In your case, since you are using the VPN client from MS store, you need to download the P2S VPN client profile from the Azure portal (VPN gateway > Point-to-site configuration > Download VPN client) and import/replace the new VpnSettings.xml file on the VPN client in your machine. This will make sure that the routes for your peered Vnets are included in your client profile and then you will be able to access the peered Vnet.
NOTE : Make sure to take a back-up of your existing VPN client profile before replacing it with the new XML file for any future issues.

To download the VPN client profile and import the XML file, please refer the below docs:
https://docs.microsoft.com/en-us/azure/vpn-gateway/about-vpn-profile-download
https://docs.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-client#import

Kindly let us know if the above helps or you need further assistance on this issue.


Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

· 12
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you for the reply. The reason why I had to download the client from the Microsoft Store is because the download from Azure portal (VPN gateway > Point-to-site configuration > Download VPN client option only downloading the config xml file and not the client installer.

I must be missing something, how do I download the client from the Azure Portal? I also tried to download using the Powershell script to get the url for the download and it also missing the msi/exe for the client.

0 Votes 0 ·

Hello @TXSDEV-6118 ,

You do not need to download the VPN client from the Azure portal. You can use the same VPN client that you installed from MS Store. The only thing that needs to change is the client profile on your machine.
To do that, download the XML file from Azure portal and import/replace it in your MS store VPN client:

153353-image.png


0 Votes 0 ·
image.png (324.7 KiB)

Thanks @GitaraniSharmaMSFT-4262, I should have mentioned in my reply that I have re-imported the XML file multiple times over and still it can't reach the peered vNet. VPN connected remote devices can ping only the Point-to-Site vNet 10.0.0.0/16 and not the 192.168.49.0/24 network.

For testing purpose I created a new VM in the 10.0.0.0/16 vNet and I can successfully reach the 192.168.49.0/24 network indicating the peering is working. Its the P-to-S VPN'd devices in the space of (10.1.1.0/24) that are unable to reach the 192.168.49.0/24

0 Votes 0 ·

Thank you for the update, @TXSDEV-6118.

Could you please confirm if you see the route 192.168.49.0/24 in the VPN routes when connected to the VPN client?

153759-image.png


0 Votes 0 ·
image.png (79.1 KiB)

Hello @GitaraniSharmaMSFT-4262 I'm not seeing the 192.168.49.0/24 listed in the VPN routes, only the following

153739-image.png


0 Votes 0 ·
image.png (21.5 KiB)

@TXSDEV-6118, this means the routes are not propagated to the VPN client. Are you able to see the route 192.168.49.0/24 in the VpnSettings.xml file that you downloaded from the Azure portal?

0 Votes 0 ·

@GitaraniSharmaMSFT-4262 I'm not seeing the 192.168.49.0/24 in the VpnSettings.xml file - how do I add that in there other than manually editing the file, which I doubt will mean anything for the VPN client's usage?

0 Votes 0 ·

@TXSDEV-6118, when you peer a Vnet with the VPN Vnet and are able to connect to the peered Vnet resources, the route is automatically propagated to the VpnSettings.xml file. Hence, it is advised to re-download the VpnSettings.xml file from Azure portal post peering configuration but since you have already re-downloaded the file many times and configured it in the VPN client, I will have to check why the routes are not being propagated automatically. Please allow me sometime to check on this and get back to you.

0 Votes 0 ·
TXSDEV-6118 avatar image TXSDEV-6118 GitaraniSharmaMSFT-4262 ·

Thank you!

0 Votes 0 ·
Show more comments
GitaraniSharmaMSFT-4262 avatar image
1 Vote"
GitaraniSharmaMSFT-4262 answered mi1an edited

Thank you for the confirmation, @TXSDEV-6118.

Now I know the root cause of the issue. It is the VPN gateways deployed in both Vnets.

Traffic is not transiting your peered VNet because of the VPN gateways deployed in both VNets. Traffic will transit a peered Vnet if only one of the VNet has VPN gateway deployed.
You can configure the gateway in the peered virtual network as a transit point to an on-premises network, but the virtual network that is using a remote gateway can't have its own gateway.
Reference : https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview#gateways-and-on-premises-connectivity

To resolve this issue, I would advise you to follow the below:
Either:
Delete the P2S VPN gateway from Virutal Network#2.
Configure P2S on the existing VPN gateway of Virutal Network#1.
Peer Virutal Network#1 & Virutal Network#2 and then use the transit gateway feature in the Vnet peering between both Vnets to access both Vnets from the P2S clients by re-downloading the XML file.
Refer : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing#multipeered

OR:
Disable the Vnet peering and create a site-to-site (IPsec) connection between the two VPN gateways.
Refer : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal#site-to-site-ipsec
The local network that is connected to Virutal Network#1 must contain both the Vnet range of Virutal Network#2 and the Point to Site range (address pool range) of VPN clients.
The point to site client must be injected with a proper route for Virutal Network#1, as by default the VPN package will only provide a route for Virutal Network#2.
You can leverage the Add-VpnConnectionRoute powershell cmdlet to add the route for Virutal Network#1.
Refer : https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconnectionroute?view=windowsserver2019-ps

Kindly let us know if the above helps or you need further assistance on this issue.


Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

· 7
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I was in the same situation and you helped me a lot by your answer. I deleted a VNG on a second VNET a now my network traffic is working as it should! Thank you so much.

1 Vote 1 ·

Thanks for staying on this topic and providing a resolution

The existing gateway to on-prem is based on the policy based VPN to Cisco ASA appliance and therefore can't add a route based P2S to the first vNET. I'll need to explore whether ASA device supports route based VPN to Azure.

Second option is our preferred way of connection, however, with the hardware shortages, we're waiting for several months for a firewall to be shipped to get this provisioned, therefore P2S was an attractive option in the interim.

Like I said earlier, the entire goal of this process is to make Azure File storage accessible and authenticated via Azure AD which appears to require a line of sight to the on prem or brokered VPN'd devices

0 Votes 0 ·

@TXSDEV-6118, you can easily implement the second option. It doesn't require any hardware.

You need to create a site-to-site VPN connection between the 2 VPN gateways in your Azure Vnets.

VPN gateway of Virtual Network#1 <---IPsec/S2S---> VPN gateway of Virtual Network#2

You just need to create 2 local network gateways for both the Vnets representing their address prefixes.
And the local network that is connected to Virtual Network#1 must contain both the Vnet range of Virtual Network#2 and the Point to Site range (address pool range) of VPN clients, so that the VMs in Virtual Network#1 are aware of the those address prefixes.
Finally, you have to manually add the route for Virtual Network#1 in your point to site client, as by default the VPN package will only provide a route for Virtual Network#2.

Once you add the route of Virtual Network#1 in your P2S client, you will be able to access the resources in Virtual Network#1. And the resources in Virtual Network#1 will be able to reply back as they know the address range of both Virtual Network#2 and P2S address pool which is added in their connected local network gateway.

Again, this is a Vnet to Vnet connectivity via Site-to-Site VPN connection and no hardware is required.
Refer : https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal#site-to-site-ipsec

Please let me know if you need further assistance on this issue.

0 Votes 0 ·

@TXSDEV-6118, I'm following up on my above comment. Were you able to implement the recommended solution? Kindly let us know if you need further assistance on this issue.

0 Votes 0 ·

@TXSDEV-6118, do you have any updates on this issue?

0 Votes 0 ·
TXSDEV-6118 avatar image TXSDEV-6118 GitaraniSharmaMSFT-4262 ·

Hello @GitaraniSharmaMSFT-4262

Here is an update from the recommendations you provided.

I was able to create a new VPN to the on prem (.50) network from the P2SvNet (10.0.0.0/16) and deleted the old VPN which as in place in the DR network (.49)

Created a peer with gateway transit enabled and we can now talk to .49 and 10.x vNets from on-prem.

Thanks for your assistance with the setup!

0 Votes 0 ·
Show more comments