Seeking Advice: Azure VPN Setup for Small Business - Routing Issues with IKEv2

Hi everyone,

I’m helping a friend with their small business after their server died, and I volunteered to migrate them to the cloud. There are a maximum of 5 users, with 2 working from home frequently.

However, I’ve run into some challenges. Since it’s a small company, they’re reluctant to pay for an Azure VPN Gateway SKU, which starts at $140/month. Instead, I deployed a Basic SKU and connected their on-premises network to Azure. Some of their applications require Active Directory (AD) for authentication.

Initially, I set up a Mobile SSL VPN, but it turned out to be incredibly slow. After some advice, I upgraded to an IKEv2 Mobile VPN.

Here are the network details:

Azure DC: 10.3.1.4/16

Azure Subnet: 10.3.1.0/16

Local Network: 10.1.1.0/24

Mobile VPN SSL: 10.1.10.0/24

IKEv2 Mobile VPN: 10.1.20.0/24

No matter how many static routes I configure or which local addresses I assign to the tunnel, it won’t route properly. When connected to the IKEv2 VPN, users can see and ping the Domain Controller (DC), but they can’t route traffic to the Azure DC, network, or subnet.

The current version of WatchGuard (12.3.0) doesn’t seem to allow configuring rules to force VPN traffic through the tunnel unless done locally. This likely means I’ll need to configure NAT to allow users to access external networks.

The only way I’ve managed to get this to work is by setting the IKEv2 Mobile VPN Virtual Address Pool to match the local network. However, this results in IP address overlap, which I know could cause significant problems down the line. But it’s the only solution that’s worked so far.

My Questions:

Is it okay to leave the IP addresses overlapping in this scenario, or is it a recipe for disaster?

Are there any other solutions I should try?

I’m considering pushing them to invest in an extended license so we can upgrade the system. In the meantime, any advice or ideas would be greatly appreciated.

Thanks in advance for your help!

Shaun

What model firewall? 12.3 is pretty old at this point… current is 12.10.3. Have you looked at the docs?

Have you performed any change to your subnets in the Azune VPN gateway after your initial configuration?

A few questions/comments to help you troubleshoot:

  1. 12.3.0 is extremely old, about 5 years old. Make sure the Firebox is on modern firmware both for interoperability and especially for security.
  2. Is the Firebox itself able to ping Azure resources? You can use the built in diagnostic tools in the WebUI to test.
  3. Assuming yes to #2, does the azure side of the tunnel have a route for the IKEv2 virtual IP pool?
  4. Do your azure network security groups allow network access from the IKEv2 virtual IP pool?
  5. Failing all else, what does a packet capture on the Firebox filtered for the tunnel interface and the virtual IP pool tell you?

Like others your FW version is a bit concerning. We have several bovpns/bovpnvifs with basic and gateway skus depending on the client. Happy to assist but will need to chat a bit more about config on both sides. You can pm me if you want and I can send over my contact information.

Hi! Thanks for you response, it is a T35 FireBox. I’ve paid for a license waiting for delivery.

Xorosaurus! Thanks for getting back, I am waiting for a license as we speak.

  1. Is the Firebox itself able to ping Azure resources? You can use the built in diagnostic tools in the WebUI to test.

Firebox itself cannot reach azure VM no, however currently the IKEv2 Mobile VPN address pools are set to the same as the onprem local network 10.1.1.0/24 and they can ping the Azure VM 10.3.1.4 however If i put it to a different subnet they cannot ping it.

  1. Does the tunnel have a route for the ikev2 virtual pool.

Yes, the tunnel has ‘Tunnel Routes’ set up for this, and to my surprise still no change at all.

  1. Does your azure NSG allow network access from the IKEv2 Virtual Pool?

Currently, they do not. However there are not any rules allowing the 10.1.1.0 either, but it works.

Will try a packet capture and come back