S2P VPN clients can't reach VMs on peered network

Question

I originally suspected that this was a routing issue, but I'm beginning to wonder.

Current configuration:
Azure Network A: 10.10.0.0/25
Azure Network B: 10.10.2.0/24
On premises C : 10.10.5.0/24

Connections:
A <-> B with Azure peering
A <-> C with Site-to-site VPN
B <-> C with Site-to-site VPN

Each network has a VPN server. From any point in any network, including clients of each VPN server, I can reach any other object on the network. This is functionally what I want, but there's a performance problem with the VPN clients that connect to networks A or B. I'm using SoftEther as the VPN server, and since Azure doesn't allow promiscuous networking, the VPN servers are NATing the clients. This adds overhead and reduces reliability. I would like to switch to using an Azure P2S VPN connected to network A (diagram attached).

I set up the Azure P2S VPN. I can reach all resources in network A. I can reach all resources in Network C (On premises), but I cannot reach resources in Network B.

I've checked the routing tables on various machines, and they look good. The fact that traffic can properly flow from VPN client through network A and down to the on-premises network is a good sign. VPN clients have 10.0.0.0/255.0.0.0 as on network. The in-network VMs have no special routing since it's handled at the gateway level.

There's one thing that may present an issue, just because it's uncommon. When I created the address pool for the P2S VPN, I used the second half of the potential network space of Network A. Network A has 10.10.0.0/25 and the VPN gets 10.10.0.224/27 for it's clients. This means that all of network A is in 10.10.0.0/24, which makes for nice, easy routing and firewall rules if needed.

I've checked the Network Security Groups, and there's nothing obvious. I'm not a networking expert by any stretch of the imagination, but I'm pretty sure that this should just work. I'm at a loss. Any insight would be welcomed.

Answer 1

Hello @Barry Lovalvo ,

From your description, I understand that you have an Azure VPN gateway deployed in Vnet A and are using SoftEther VPN in Vnet B. And there is a Vnet peering between Vnet A and Vnet B. If this is correct and you do not have an Azure VPN gateway deployed in Vnet B, then in order for your clients to access Vnet B resources via P2S VPN, you need to enable UseRemoteGateway / AllowGatewayTransit features in your Vnet peering.
Please refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal#can-i-configure-a-point-to-site-client-to-connect-to-multiple-virtual-networks-at-the-same-time
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

However, if Vnet B also have an Azure VPN gateway, then the above approach will not be possible because a virtual network can have only one gateway. The gateway is either a local or remote gateway in the peered virtual network, which means the virtual network that is using a remote gateway can't have its own gateway.

In case you are unable to use the UseRemoteGateway / AllowGatewayTransit features in your Vnet peering, you can go for site to site VPN connection with BGP between Vnet A and Vnet B and manually add the routes for Vnet B to the clients.

You can find all Azure Point-to-Site VPN routing and connectivity scenarios in the below article:
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing

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

----------------------------------------------------------------------------------------------------------------

Please don’t forget to "Accept the answer" wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Responding to myself, since I can't find an edit button.
I wonder if I have to manually add a routing table to network B. That seems unlikely, but possible. I'll play with it.

Answer 3

@GitaraniSharma-MSFT Thank you for your advice. I did not consider using the transit feature because the traffic was already flowing through the S2S gateway down to the on-premises network. I will review the documents and test things on Friday.