Bandwidth considerations with Always on VPN and 80% WFH

VPN
1

Hi,

I’m looking at ways to manage the bandwidth across our always on VPN better. Generally we’ll have 20% people in the office and 80% working from home on any given day but everyone will come into the office at some point. Security are a blocker for split-tunnelling at the moment which will hopefully get resolved.

We have:

  • A head office with one ConfigMgr Server which has all of the roles except SQL. Most people based in this office will wfh the majority of time
  • There are 1500 users
  • ConfigMgr on HTTPS
  • Co-mgmt but only for Device Compliance, no CMG as everyone is on VPN
  • Al devices are laptops
  • One new branch with 50 users who are in the office 90% of the time*the network is not controlled by the business but by the building and they just use VPN
  • One very new branch office with 100 users from a merger who are in the office 30% of the time. Plans for a DP to be placed in this office
  • The VPN is generally slow and can be impacted by update deployments

​

The areas of consideration are:

BITS

  • Enable BITS to limit background traffic. Done via a GPO setting or SCCM. Bit old fashioned now I guess to use this and better to go with LEDBAT I would assume?
  • It affects all traffic, not just ConfigMgr traffic. It can still overload your VPN solutions and is not recommended .

LEDBAT

  • Is this a bit of a no-brainer? Does it work the same across VPN and local networks - assuming it does
  • It would help to rule out ConfigMgr being an issue with slow network speeds is my thinking

BranchCache

  • Again, is this worth it if the majority of devices are on the VPN? Is there a way to run BranchCache off for the VPN subnet
  • Or maybe it is if you use it in local caching mode which basically dedupe’s data but without P2P

ConfigMgr PeerCache

  • Seems pointless to enable this when the majority of users are remote, using laptops and on vpn. It would make the traffic worse
  • Might be worth enabling for the remote branches and not place a DP there if there were desktop’s but they are all laptops

Delivery Optimisation / Microsoft Connected Cache

  • The use case for this seems to be if you are using WUfB and the majority of your users are in the office. Then you would enable DO and install MCC. Maybe if you are using SCCM for updates but have allowed Edge and Defender updates via the Internet this could be worth considering?
  • Assuming to just not implement this until the switch to WUfB is made?
  • Should this be used if the majority of people are wfh and on vpn?
  • Read that this needs Express updates to be enabled for this to work with ConfigMgr which I remember being flaky?

Useful Research Links

2

Security are a blocker for split-tunnelling at the moment which will hopefully get resolved.

You really need to push them on that. Getting patches from MSFT is so much better for VPN clients.

3

The short answer is there’s a reason EVERYONE enabled split tunnel when COVID hit. Put in a CMG and split tunnel the traffic to all MSFT URL’s and the CMG.

4

This really depends on what you’re deploying. Is it primarily Windows updates or apps/packages?

If it’s Windows Updates, you can have the VPN connected devices get their content directly from Microsoft instead of your internal SCCM DPs.

If it’s apps/packages, you can continue having them get content from your internal DPs, setup and go with a CMG, or if you’re in a hybrid-join environment you can start deploying your apps via Intune instead.

Like you mentioned, basically any sort of bandwidth saving technology won’t have much of an effect on an 80% VPN connected client environment, other than if you just limit BITS speeds for everything. But that would just cause the clients to all be downloading content over your VPN for an extended period of time, albeit at a slower speed.

5

No split tunnel pretty much blocker using laptop

6

We were in the same scenario as OP. We are doing the following.
Enabled LEDBAT, this comes with its own caveat, as it will use 100% of the clients’ bandwidth when needed, but will also take a back seat when foreground applications need to use the bandwidth.
We set our ONVPN clients to their own Boundaries and Boundary Groups, which included their own Deployment Point servers. We do not deploy the SUGs to these DPs and set it to download from MS if not available on DP. We split tunnel this traffic to MS update and to cap any traffic to the DPs we enabled local QOS to and from the VPN subnets.

7

“If it’s windows updates….” What good is that without split tunnel? Everything is going over VPN and now you’re adding an extra bit of traffic from MS to the datacenter

8

Ahh, I didn’t notice until now that he said they weren’t using split tunneling. Yeah, that’s out then.