A cautionary reminder when firewall rules are being set up for Skype for Business, that 443 or 443/TCP or 443/TCP/SIP does NOT mean HTTPS. Honestly, I don’t think I’ve met a firewall yet that supports Microsoft’s 443/SIP for a so my rule request is very specifically 443/TCP, unless the required rule, like for the Reverse Proxy actually state HTTPS, require 443/TCP the rule ye be.
The above link goes to Microsoft’s firewall port requirements, and for the Edge now they are specifying 443/SIP or 443/TCP for the Edge Access role (updated July 11, 2016). This is interesting because I think there has been a change in behavior in the Edge services, specifically around 443. Scenario below:
Client running CU-235 (yes, I use the last 3 digits of the CU, as some “CU’s” are security updates so I find this to be the most logical way of determining the CU being referenced), anyway, CU-235 was applied to both the Frontend and Edge servers properly. Internally, few if any issues were noticed, externally, there were problems with taking a 2-way PC-to-PC call, and adding a 3rd person to the call. Naturally the call is elevated into a Conference call and bridges through the Edge. Setup of this conference take 4-10+ seconds longer than usual, BUT the only the person who brought in the 3rd party into the call, and the 3rd party person, are in the call. The 2nd person who was in the call is Paused, and is eventually booted, but can click Rejoin and finally enter the Conference Call. Very annoying.
CU-259 comes along, and there’s hope that this may be resolved… Noop. In fact things go horribly horribly worse, as well as the same for CU-272. Meetings fail, all 2-way to 3-way calls externally fail, much more functionality is broken with Webconf and AV. Both times, the system was rolled back to a tolerable level.
Please bear in mind, I was requesting review of the firewall rules the whole time; power outage borked the firewall, couldn’t access, needed reboot, needed change window… ect. First glance at the rules, thar she sat, HTTPS. IF you are reviewing firewall rules with a client/FWadmin, and see HTTPS, you can pretty much assume this is an APPLICATION LAYER rule, and will restrict verbs and actions of the protocol being used. Some firewalls, if you enter 443/TCP the rule will actually switch to HTTPS (Juniper I’ve seen do this), and it requires the FWAdmin to make changes to create a new specific rule for 443/TCP. Different firewalls will also exhibit various different failures for the Edge. Simply put, IF in testing or in production, you have any kind of weirdness with External Conferencing or Web Conferencing functionality, Step 1) Make sure the firewall isn’t using an HTTPS rule. 443/TCP, gitterdone.
Oh look, a bird!
It also doesn’t hurt to make sure that SIP ALG, SIP Inspect, or any other APPLICATION LAYER filtering for SIP is disabled. Microsoft SIP is encrypted, but sometimes weirdness still happens
You may have been getting away with HTTPS rules on your Edge external rules, but with CU-235 and higher, especially higher, there is a good chance you’re going to encounter issues. Oh yes, MS Support was contacted before I came on board, and they were baffled by the behavior and failures, traces that they ran couldn’t explain the problem. So, SIP trace and wireshark wise, it’s not easy to identify this problem.