I was lucky enough a few weeks ago to get a Velocloud SD-WAN by VMware router for my homelab. This post won’t be about all the features and capabilities of Velocloud, but there is one particular capability that, although useful, causes a few challenges with Horizon and Identity Manager.

I’m talking about Dynamic Multi Path Optimisation. Being an End User Computing specialist, I’m not going to pretend I am a networking expert but I will try to explain it as best as I can. On my Veloloud Edge Router in my lab, traffic is dynamically routed through the Velocloud Edge Gateway hosted by VMware on the megaclouds like AWS. Read the document linked above, but what it allows is Velocloud to optimise and improve internet and network traffic when routed through one of these Gateways.

However, after setting one of these bad boys in my homelab I noticed that things weren’t quite working quite as expected for Horizon and Identity Manager.

If anyone has implemented Identity Manager for their On-Premises Windows devices or like in my case Horizon 7 VDI, you’ll know that being able to use Kerberos as an authentication method makes access to Virtual Desktops and Published Apps incredibly simple. Because a user already has a Kerberos ticket from the logon process, Identity Manager can use this to authenticate the user and SSO into the portal and also use it for TrueSSO into Horizon. The way this is typically set up is that you create an Access Policy in Identity Manager for all Web Browser/Win 10 traffic on your Internal Network to use Kerberos as the primary auth method and tie to this a defined Network Range. We need to separate this out because if you’re not on a domain joined PC or using some other process to get a Kerberos token the user us prompted with an NTLM Username and Password prompt.

This is what my access policy looks like:

One of the challenges (*cough* limitations *cough*) with SaaS Identity Manager however is that the Network Range (in my example HOME) is you can only define a WAN IP, not an internal range.

So where’s the issue with Velocloud? Well multi pathing breaks this concept of a known WAN IP. Although I have a static IP, whenever I went to Identity Manager it kept giving me an error saying it couldn’t find the Access Policy (it couldn’t find an Access Policy that my endpoint rules matched) or it went to one of my fallback Access Policies that were assigned to ALL RANGES.

The first clue looking at my Audit Events in the Identity Manager console.

Notice the sourceip does not match what is in my HOME Network Range (my WAN IP)?

Doing a WHOIS on that IP definitely doesn’t match my ISP.

The weird thing was that even going to https://whatismyipaddress.com I got my external IP. To prove my hunch, all I had to do was add the above IP address into its own Network Range and test it with my Policy. Which worked.

What that made me realise (due to my limited Velocloud experience) that multi-pathing was the cause!

How did I resolve this? Well it was pretty simple.

In the Velocloud Orchestrator (where you configure your Edge Gateway) you need to add a ‘Business Rule’ to force traffic to Identity Manager to go directly via your WAN link and bypass DMPO.

The rule is pretty straight forward for my situation. Velocloud is smart enough to match partial FQDNs so I could have also set the hostname field to ‘vmwareidentity’. The important part here is:

– Set Network Service to Direct (go directly out your WAN link)
– Link Steering should be configured to force it via a specific WAN link (I have a 4G router attached as backup which would cause issues if used as a route as well)

Now, once this is set and applied to my Velocloud Edge, Identity Manager sees my real WAN IP address and Kerberos works correctly.