This test proved that the problem was not client-related, since the laptop worked fine when it emulated an on-site machine via the VPN but had intermittent connectivity without using the VPN. I rechecked every network device in line for a port block and found none. At this point, I began to think the issue had to be above Layer 4.

The only device that could possibly block above Layer 4 in this situation was the traffic manager, so I turned my attention to it again. The traffic manager had a basic configuration to deny popular peer-to-peer applications that a firewall rule based on ports may not catch. Other than that, there were no blocks -- just prioritizations and partitions based on applications and IP addresses.

I created the same inbound logging rule as before and monitored the traffic classifications. This time, I ran the test for a greater period of time than before. The extra time for traffic classification revealed the reason for the intermittent connectivity and the solution.

The traffic manager was misclassifying some of the portal connections as Skype. Skype, a popular peer-to-peer IP telephony application, was banned by the corporate security policy and enforced by the traffic manager peer-to-peer rules. The solution was to allow Skype-identified traffic to the portal server. Since the server was not actually running Skype, this was an acceptable solution.