Azure IP Sec Issues

Hello All,

I have several PepLink Balance 305’s connected up to a Balance 508 in a star topology.

The 508 is connected via IP Sec VPN tunnels to Azure.

None of my satellite sites can traverse to Azure.

The diagram below shows my configuration where green detonates Azure end-to-end connectivity.

The 508 does not seem to be advertising it’s routes to Azure to my 305s.

I am not sure why.

I will gladly provide more in-depth networking information if necessary.

Any thoughts?

I’m not aware that Ip Sec tunnels advertise their routes through second hops. You could add a static route for the Azure subnet on the sattelites, pointing to the 508. You may also have firewall issues on both the satellites and Azure, not allowing exchange from the other.

Thanks for the reply.

That’s what I was afraid of.

It doesn’t seem like I can make a static route because the Azure gateway is on a separate subnet from the 305’s.

I’m currently look at placing a VM running Fusion Hub into the Azure cloud and establishing a PepVPN tunnel that way.

For the record, advertising the IPSec tunnels out over the PepVPN tunnels would be a really convenient feature.

Two thumbs up for this idea! With only slightly more overhead per packet PepVPN is superior to IPSec. Thanks

If there is a way to solve my problem without going to Fusion Hub route, I’d love to know.

Either way, I’m likely going with Fusion Hub.

Yes and no. I love pepvpn and speedfusion but when working with 3rd party vendors this doesn’t always work.

Microsofts best practice for Azure is to connect to it using an “Azure VPN gateway” which supports IPsec and BGP over IPsec. They have a support/compatibly list which the vendors look at and go with when looking to connect customer premises to Azure.

Partners can go in and argue for Peplink to be used instead of a $100 UBNT edge router but can’t win the argument if the tools aren’t even there to let them use Peplink.

Adding dynamic routing for IPsec on Peplink (i imagine) shouldn’t be too tough to do given it is already available over speedfusion, but would give partners a lot more ammo when going in to battle with other providers. Once the peplink devices are in then it makes it easier to sell them on the idea of pepvpn and speedfusion.

We have just gone through this exact situation and ended up having to go with the customer and provider and use a supported IPsec vpn endpoint instead of Peplink devices.

I don’t understand why you can’t write static routes for this?

On B305, destination Azure subnet, gateway B508
On Azure, destination B305 subnet, gateway B508

Once the traffic is routed onto the B508, that device already knows where to send it. As I said you’ll also need to be sure firewall rules on each end also permit the routing.

I don’t understand why I cant write static routes, either.

Perhaps I am doing this incorrectly.

Below is a screen shot of my attempt at “On B305, destination Azure subnet, gateway B508”

So, unless I’m missing something critical, static routes have to connect to gateways within the same subnet.

I am not willing to put each of my sites on the same subnet.

@masterofabcs

Definitely the static route are incorrect. Static route only work when the gateways are in the same subnet for the local LAN/VLAN interface.

For your case, i would think you can try the followings:

Believe PepVPN/SpeedFusion is connected between the B305 & B580.

In each Balance 305:

  • Create “outbound policy” to enforce Azure Network via the B305<—>B580 PepVPN tunnels

In B580:

  • Make sure IPSEC tunnel is defined all the local networks for all the B305 LAN subnet.

P/S :
You need to check on Azure on how to allowing those B305 LAN Networks to access the cloud servers.

Sorry yes of course thats right it should be outbound rules, not static routes.

Thanks for all the advice everyone.

The outbound policy is working and we are happily traversing to Azure now.

1 Like