Ian_M10
These questions are relatively hard to answer verbosely without knowing your full network configuration/VPN solution etc but I’ve done my best to answer as much as is possible below. I would strongly recommend you consult VPN vendor if possible for explicit guidance in case there are any additional steps required for the particular solution.
1. Do we need a PAC file for proxy bypass to support our target remote working/spilt tunnelling solution?
The answer depends on your environment, and configuration on handling HTTP/HTTPS traffic. If you need/want to send traffic to an explicit proxy within the corporate network, but route other traffic such as the Optimize marked Office 365 endpoints via the local interface on the remote client. then yes, a PAC file is likely necessary to make this split.
Any traffic you want to send direct via the internet should be configured in the PAC file to return DIRECT, located above any logic which sends traffic to the proxy, a very simple example is shown below sending the OPTIMIZE traffic direct, the rest to the proxy, elements in italics being tenant specific:
// Define proxy server
var proxyserver = "PROXY 10.10.10.10:8080";
// Make host lowercase
var lhost = host.toLowerCase();
host = lhost;
}
//EXPRESS ROUTE DIRECT
else if ((isPlainHostName(host))
|| (shExpMatch(host, "contoso.sharepoint.com"))
|| (shExpMatch(host, "contoso-my.sharepoint.com"))
|| (shExpMatch(host, "outlook.office.com"))
|| (shExpMatch(host, "outlook.office365.com"))
)
{
return "DIRECT";
}
//Catchall for all other traffic to proxy
else
{
return proxyserver;
}
}
Once this split is made on the PAC file the VPN client also needs to be configured to recognise the traffic you want to allow to go direct via the local interface/gateway to the internet.
For example traffic to the proxy IP address/name e.g. 10.1.1.2 (proxy.contoso.com) will be configured in the VPN client to be routed down the VPN tunnel. Normally you would configure all your internal IP space to use the VPN tunnel.
Traffic to outlook.office365.com or the IP subnets that URL publicly resolves to should then be routed direct out of the user’s internet connection. How this is configured in the VPN client depends on the VPN solution itself. UDP traffic to Teams should work automatically via the local interface if a path is available via the internet for the IP subnets. (52.112.0.0/14 and 13.107.64.0/18)
2. If we do not need a PAC file, will the use of a PAC file impact our target remote working/spilt tunnelling solution?
If you don’t need a PAC file you are likely using a transparent proxy or direct network egress, in this scenario, the VPN client needs to have the configuration so that the Optimize marked IP subnets are sent out of the local interface, i.e. excluded from the traffic sent down the VPN tunnel. I’d suspect this isn’t a scenario you’re using (i.e. you’re likely using an explicit proxy as per answer #1 and thus are using a PAC file)
3. If we do need a PAC file, will it need to be different from the PAC file that will be used when our users are in the office\within the corporate network?
The answer to this question depends again on your internal network configuration. Does the internal network have a direct network egress for the Optimize traffic? If not (i.e. internet browsing has to go via the proxy on the corporate network). If the network doesn’t have a local network egress then traffic sent direct will get dropped. In this scenario you’ll need a different PAC file for the remote clients, which should be easy to do based on the IP subnet the client has e.g.
Client has IP subnet 10.1.0.0/16 = Corpnet client > Corpnet PAC
Client has IP subnet 10.2.0.0/16 = VPN Client > Remote Worker PAC
Or you can use myipaddress() function to point the client to different proxy nodes based on the Client IP range within the same PAC file.
If you do provide direct and local egress for the Optimize marked traffic from your corporate network (via SDWAN/Local Firewall etc) as per best practice, then you should not need a separate PAC file.
Hope that helps!
Paul & the Office 365 network team