Is there a maximum size, a wpad.dat will be processed? / Skype4Business rules

I cannot speak directly to the proxy size limit.   Mine is about 4K and I have not seen a problem.   Since the proxy script is parsed by the browser, I doubt that there are any meaningful size limits.   Only Microsoft, Google, and Mozilla will know for sure...

As you said, if your proxy file says to go DIRECT, then your firewall rules have to allow the connection as well.

DouglasFoster said:

As you said, if your proxy file says to go DIRECT, then your firewall rules have to allow the connection as well.

That part is clear, but Microsoft wants "*.domain.com" exceptions being made. ON UTM I'm not able to use wildcards as firewall targets, maybe that worked in forefront, but not here... I already added all of their listet networks and dns hosts to a network group but for their over 250 /32 adresses I do not really want to create host objects as I think that would be a totally overkill and possibly not even worth the time if things change (and it isn't even controlable if some of 250 entries change, are removed or added).

As not all users in the company should use it I guess I have to use STAS and allow https/s traffic to any internet target for the designated users in the firewall. I'm note pleased with that solution but I do not see another good solution for it. The proxy exception part is nearly copy & pastable, edited from time to time with notepad++ that will be easy to maintain.

If anyone has a better solution than allowing http/s traffic to any on firewall's side it would be appreciated ;-)

Update: I was refering to this "bad joke list"

Guessing how Skype works, from a skim of their instructions and inference from other products:  

A primary channel is established using https/443 from the client application to their server.   Then they spawn a secondary channel over UDP using encryption settings negotiated on the primary channel.   For the two channels to match, the apparent source IP needs to be the same on both channels, and the secondary channel setup needs to provide information obtained on the primary channel.

Proxies can prevent the connection if the primary channel has a different external IP than the secondary channel.  HTTPS inspection probably messes this up because the encryption settings from the client to the proxy may be different than the encryption settings from the proxy to the server.   If the secondary channel has to match the encryption of the primary channel, the source and destination have different encryption expectations.  Microsoft also worries that the proxy will cause unacceptably latency.

Guessing how this affects UTM:

1) The whole thing might work using standard proxy, as long as https inspection is disabled for the Microsoft destinations.    I think you can disable https inspection for wildcards like *.skype.com using a DNS Group.   This assumes that standard proxy and non-proxy traffic will leave UTM with the same IP Address.

2) If #1 does not work, I would suggest trying transparent proxy.  Your proxy script changes will cause the application to attempt a connection on port 443, which will allow the transparent proxy to activate if the network selection matches.   If UTM is behind another firewall and in a bridged configuration, then you will probably need to use the "Full Transparent" checkbox to ensure that the source IP unaltered.

3) IF #2 still fails, then you still use transparent proxy, but you put the Microsoft servers into the transparent mode skiplist, again using DNS groups for the wildcards like *.skype.com

The overall goal is to handle everything with proxy setup instead of firewall setup, because I think it will allow you to use DNS Groups.

How does transparent proxy change my security posture?

The filter profile is selected based on network source object and port, so I don't think you can filter on user at all.  User network objects require a VPN client connection and IP address filters assume a short list of devices with static IP addresses (which is probably not the case.)  This means that transparent proxy will probably need to be enabled for most everything in your network.

However, transparent proxy will only be attempted when the proxy settings are not configured into the device, or the source application is not compliant with the proxy settings.  In some cases, transparent proxy may be able to handle some traffic that is currently going Direct.   (To maintain Direct behavior, the Direct addresses will need to be entered into the Transparent Mode Skiplist.)

User-level filtering can can be done by the policies and filter actions within the Filter Profile, so I think you can get to a configuration that only allows Skype for senior management, or only allows Transparent proxy for senior management.

I have just described a bunch of things that I have not tried, so I will be curious if any of this is valid in the real world.

Guessing how Skype works, from a skim of their instructions and inference from other products:  

A primary channel is established using https/443 from the client application to their server.   Then they spawn a secondary channel over UDP using encryption settings negotiated on the primary channel.   For the two channels to match, the apparent source IP needs to be the same on both channels, and the secondary channel setup needs to provide information obtained on the primary channel.

Proxies can prevent the connection if the primary channel has a different external IP than the secondary channel.  HTTPS inspection probably messes this up because the encryption settings from the client to the proxy may be different than the encryption settings from the proxy to the server.   If the secondary channel has to match the encryption of the primary channel, the source and destination have different encryption expectations.  Microsoft also worries that the proxy will cause unacceptably latency.

Guessing how this affects UTM:

1) The whole thing might work using standard proxy, as long as https inspection is disabled for the Microsoft destinations.    I think you can disable https inspection for wildcards like *.skype.com using a DNS Group.   This assumes that standard proxy and non-proxy traffic will leave UTM with the same IP Address.

2) If #1 does not work, I would suggest trying transparent proxy.  Your proxy script changes will cause the application to attempt a connection on port 443, which will allow the transparent proxy to activate if the network selection matches.   If UTM is behind another firewall and in a bridged configuration, then you will probably need to use the "Full Transparent" checkbox to ensure that the source IP unaltered.

3) IF #2 still fails, then you still use transparent proxy, but you put the Microsoft servers into the transparent mode skiplist, again using DNS groups for the wildcards like *.skype.com

The overall goal is to handle everything with proxy setup instead of firewall setup, because I think it will allow you to use DNS Groups.

How does transparent proxy change my security posture?

The filter profile is selected based on network source object and port, so I don't think you can filter on user at all.  User network objects require a VPN client connection and IP address filters assume a short list of devices with static IP addresses (which is probably not the case.)  This means that transparent proxy will probably need to be enabled for most everything in your network.

However, transparent proxy will only be attempted when the proxy settings are not configured into the device, or the source application is not compliant with the proxy settings.  In some cases, transparent proxy may be able to handle some traffic that is currently going Direct.   (To maintain Direct behavior, the Direct addresses will need to be entered into the Transparent Mode Skiplist.)

User-level filtering can can be done by the policies and filter actions within the Filter Profile, so I think you can get to a configuration that only allows Skype for senior management, or only allows Transparent proxy for senior management.

I have just described a bunch of things that I have not tried, so I will be curious if any of this is valid in the real world.

Kevin, I don't understand why you don't simply allow HTTPS traffic for all internal clients since you control their non S4B traffic with Web Filtering.

Doug, DNS Groups don't work like that.  They require a complete FQDN that has multiple A-records assigned.  I believe there's a feature request for something like what you describe.

Cheers - Bob

Bummed about dns groups.  Sorryabout the bad advice.  It was such a nice fantasy...

Because in the customer's environment the wpad.dat is used "manually", not automatically (not changeable) by the users.
So if the user simply disables the entry they are able to surf and the proxy is outdriven as it is not working in transparent mode.
Custormer was "bought" by a new company in 2015 and now the new company's IT department is starting to take over the systems and network slowly, so bigger changes to the whole network don't seem worth it for us anymore.

But for testing purposes I'll use a firewall entry allowing me everything (http/s to Any) at least from my testing machine.

I originally asked the question about the size, because the system is reporting many "Http proxy not running - restarted" errors, even at night, when no user is active.
I can't reconstruct a direct connection to the Skype 4 Business changes, but it feels a bit that those errors appear more frequent since the changes. They appear 1-10 times a day, as mentionned not really explainable with much load on the system.