In an explicit proxy environment it is common for outbound connections to the Internet to be limited to connections from a proxy IP(s). It is common for a firewall to be used to control access in this manner. At times we have seen Outlook clients ignore explicit proxy settings and attempt to connect to Office 365 servers directly which can result in very slow connecting behavior.
Note: The client application behavior is deemed to the change by the application or server provider from time to time. If the client application is no longer honoring the proxy setting even after trying all the possible IP addresses, a firewall rule might have to be configured to allow some direct connections from client application.
To confirm this issue a packet capture from the client while opening Outlook, which initiates connections to Office 365, is needed. The packet capture will show the following:
1. The Outlook client will send a DNS request to outlook.office365.com, and the response will contain all the destination IP addresses for this server as per the below packet capture line:
595 0.001580000 10.10.10.11 10.10.10.12 DNS 342 Standard query response 0x258e CNAME outlook.office365.com.glbdns.microsoft.com CNAME outlook-apacsouth.office365.com A 111.221.115.98 A 111.221.118.156 A 111.221.115.86 A 111.221.114.169 A 111.221.119.98 A 132.245.160.34 A 111.221.115.92 A 111.221.115.82 A 111.221.117.214 A 111.221.118.146 A 111.221.118.153
2. Next the Outlook client will try to establish a direct connection to one of the IP addresses that it received in the DNS response. Note that the client is ignoring its explicit proxy settings and attempting to establish these connections directly, which are dropped by the firewall:
906 0.000000000 10.10.10.12 111.221.115.98 TCP 66 49384 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
947 3.001512000 10.10.10.12 111.221.115.98 TCP 66 [TCP Retransmission] 49384 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
992 5.999961000 10.10.10.12 111.221.115.98 TCP 62 [TCP Retransmission] 49384 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
3. Then after three SYN packets for the same destination, and waiting on average for 3-6 seconds in between each packet without a response, the Outlook client will try to go to another IP address from the DNS response as per the below packet capture lines:
1065 12.000780000 10.10.10.12 111.221.118.156 TCP 66 49385 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1096 2.998964000 10.10.10.12 111.221.118.156 TCP 66 [TCP Retransmission] 49385 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1494 12.000739000 10.10.10.12 111.221.115.86 TCP 66 49410 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1670 12.001145000 10.10.10.12 111.221.114.169 TCP 66 49413 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1830 12.000674000 10.10.10.12 111.221.119.98 TCP 66 49414 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
Most likely all of the above connection examples were blocked or dropped by the firewall since it is not allowing clients to connect directly to the Internet. Outlook will go through the list of IP addresses returned from DNS and attempt to establish connections with them directly. Only after all of those attempts fail with Outlook then use explicit proxy settings
The result of this behavior is application slowness as it takes many seconds for each direct attempt to fail and there are many IP addresses for Outlook to make attempts to.
Refer to the following two URLs for more information on one potential issue with the outlook client causing the delays:
http://support.microsoft.com/kb/2916915/en-us
http://blogs.msdn.com/b/modonovan/archive/2014/01/05/10481165.aspx