Specifying "Intersting Traffic" on VPN Gateway for Public IP Addresses

Question

Greetings,

We are working on a Site-to-Site (S2S) VPN Gateway setup and feel like we are 90% of the way there. We do not have any control over the configuration and setup of the "on-premises" side of things (it's a partner that we're connecting to, not to our own office) and need to conform to their specifications.

So far, we've successfully created:

• Virtual Network (address space 10.3.0.0/16)
• Two Virtual Machines on the vnet (10.3.0.4 and 10.3.0.5) with public IP addresses (this is the important part)
• Local Network Gateway with the public IP address of the on-premises VPN device, as well as the defined address space for that network
• Virtual Network Gateway with an Azure public IP address
• Site-to-Site (IPSec) VPN Connection in the Virtual Network Gateway
• Using pwsh commands New-AzIpsecPolicy and Set-AzVirtualNetworkGatewayConnection, the encryption and other settings were specified and applied successfully

At this point, the on-premises team states that the connection attempt appears to be successful to the extent that the configuration proposal is accepted. Hooray! However, the next step where the Azure side is specifying the network(s) with "Interesting Traffic" is where the two sides of the VPN disagree.

The Azure side is stating that it will send traffic from 10.3.0.0/16 (which makes sense, given the above configuration), but the on-premises side needs to be receiving traffic from the two public IP addresses assigned to the VPN. In other words, VM1 needs to communicate through the VPN using VM1's public IP (52.x.x.x) in order for the on-premises to accept the traffic to the destination behind it.

I think there are two issues that remain to be solved:

1. Configure the Azure VPN to know and state that it will send traffic from two specific public IPs (52.x.x.x)
2. Configure VM1 and VM2 to actually send traffic intended for the on-premises VPN using their public IPs

I believe we would do #2 by setting up a NAT and/or a route table somehow, but we have not been able to find any documentation or settings that would assist with #1.

From the Azure side, the "VPN troubleshoot" link shows that both the Virtual Network Gateway as well as the VPN Connection are "Unhealthy" (as expected, since it won't connect), and the summary states:
The connection is not available in the VPN gateway because of configuration conflicts

With the Action stating:
Cross premises
Create a cross premises connection.
VNet-to-VNet
Create a VNet-to-VNet connection.

Unfortunately, my VPN and networking skills are simple at best and this type of cool, but advanced Site-to-Site connection are a little beyond my troubleshooting skills.

We have been eagerly moving resources from some other cloud provider and are much happier in the Azure environment. We just a couple of outstanding configuration issues - this VPN being the primary one - before we can claim full success. The Azure experience has been a welcome, comfortable, and highly-performant change and are looking forward to this last little piece being resolved.

Thanks in advance for any advice/help/suggestions on this issue!

Answer 1

Hi @GitaraniSharmaMSFT-4262,

Thanks for the reply. The initial requirement was dictated to us by our partner on the other end. However, in some recent troubleshooting and conversations, we may be able to work around that exact requirement. If so, this post is basically no longer relevant and I will update it accordingly.

As for the VPN, we're using a Route-based service with a Juniper SRX device on the partner's side of things.

I'll update this once I have more information from our troubleshooting.

Thanks again!