Skype for Business is unable to sign in when SSL filtering is enabled. Does anyone know what exceptions need to be added to get it to work?
This thread was automatically locked due to age.
This reply is not very timely, but I think it's always good to find updated (or at least additional) information when searching for solutions. I found this thread several times when searching for information on how to configure UTM 9 to allow Skype for Business traffic through from my home network (i.e., as a Skype for Business user/client).
First, to allow Skype to sign in at all I needed to exclude any URLs associated with my employer's domain.
^https?://([A-Za-z0-9.-]*\.)?company\.com/?(.+)
(SSL scanning / Certificate trust check / Certificate date check)
After that I could sign in and send IMs, but as I found out later, Skype calls did not work. In trying to get calls to work, I built up the following list of exceptions based on observing the web filter log output.
^https?://[^.]*\.office365.com/?(.+)
^https?://clientlog.portal.office.com/?(.+)
^https?://[^.]*\.microsoft.com/?(.+)
^https?://[^.]*\.yammer.com/?(.+)
^https?://[^.]*\.office.com/?(.+)
^https?://xx\.xx\.xxx\.\d{1,3}/?(.+)
(SSL scanning / Certificate trust check / Certificate date check)
The last line where the x's appear, are actually numbers, but that is the IP pool for my employer's Skype servers, or at least that is what they appear to be to me (I am not an IT guy). For some reason these URLs were showing as IPs only in the UTM 9 web filter log, else they should/would have been covered by the very first exception, I would have thought. I also had to add some firewall rules for Skype traffic to the company specific IP range for services (TCP/UDP 50000:59999 / UDP 3478) before I stopped seeing dropped packets in the firewall log, but not sure if that was an absolute requirement. (Surely though, it couldn't hurt to not drop legitimate packets).
I have tested this with a couple of voice calls, but have not yet tested a meeting with sharing. Also I should point out that I haven't gone back and tried to trim the scope of settings back to find the bare minimum set of exceptions that are needed, so this should just be treated as a rough starting point, or something else to try, for anyone running into the same or similar issues.
Cheers.
EDIT: The line ^https?://clientlog.portal.office.com/?(.+) seems to be redundant based on the fact I added ^https?://[^.]*\.office.com/?(.+) afterwards.
This reply is not very timely, but I think it's always good to find updated (or at least additional) information when searching for solutions. I found this thread several times when searching for information on how to configure UTM 9 to allow Skype for Business traffic through from my home network (i.e., as a Skype for Business user/client).
First, to allow Skype to sign in at all I needed to exclude any URLs associated with my employer's domain.
^https?://([A-Za-z0-9.-]*\.)?company\.com/?(.+)
(SSL scanning / Certificate trust check / Certificate date check)
After that I could sign in and send IMs, but as I found out later, Skype calls did not work. In trying to get calls to work, I built up the following list of exceptions based on observing the web filter log output.
^https?://[^.]*\.office365.com/?(.+)
^https?://clientlog.portal.office.com/?(.+)
^https?://[^.]*\.microsoft.com/?(.+)
^https?://[^.]*\.yammer.com/?(.+)
^https?://[^.]*\.office.com/?(.+)
^https?://xx\.xx\.xxx\.\d{1,3}/?(.+)
(SSL scanning / Certificate trust check / Certificate date check)
The last line where the x's appear, are actually numbers, but that is the IP pool for my employer's Skype servers, or at least that is what they appear to be to me (I am not an IT guy). For some reason these URLs were showing as IPs only in the UTM 9 web filter log, else they should/would have been covered by the very first exception, I would have thought. I also had to add some firewall rules for Skype traffic to the company specific IP range for services (TCP/UDP 50000:59999 / UDP 3478) before I stopped seeing dropped packets in the firewall log, but not sure if that was an absolute requirement. (Surely though, it couldn't hurt to not drop legitimate packets).
I have tested this with a couple of voice calls, but have not yet tested a meeting with sharing. Also I should point out that I haven't gone back and tried to trim the scope of settings back to find the bare minimum set of exceptions that are needed, so this should just be treated as a rough starting point, or something else to try, for anyone running into the same or similar issues.
Cheers.
EDIT: The line ^https?://clientlog.portal.office.com/?(.+) seems to be redundant based on the fact I added ^https?://[^.]*\.office.com/?(.+) afterwards.
