Hey guys, I need your help with a very weird problem I came across. Here is the setup: DMZ LAN --- [ISA 2000] ---+--- [Checkpoint] --- Internet ! ! [POP3] On the LAN are about a 200 workstations configured as Firewall and SecureNAT clients. Each workstation has Outlook and polls every 5 minutes the POP3 server on the DMZ. We have observed that very regular the Outlook client fails in polling the POP3 server with a connection timeout. By taking some NetMon traces at the POP3 server itself (runs on Win2003) we see that the failing connection requests arrive on the POP3 server but that the POP3 server does not respond to those connection requests. Further detailed analyzes of the NetMon trace reveals that all requests has as source IP address of course the primary IP address on the ISA external interface, but also that ISA 2000 very rapidly re-use previous used source ports. So, we suspect that the POP3 server receives connection requests for a connection that is still in the TIME_WAIT state. We then added on the POP3 server the registry key 'TcpTimedWaitDelay' (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) with a value of 30 seconds (the default is 240 seconds) and rebooted the server. That seems to mitigate the problem but did not solve it completely. So we deleted the key again do undo the change and rebooted the server again. We disabled then the entry Outlook in the Firewall client config and after refreshing the config on the clients, the problem was completely gone. The obvious question is now why? We took again some NetMon traces on the POP3 server itself to find out what could be different in a connection request originating from a Firewall and SecureNAT client. The only difference we could detect is that for connection requests originating from a SecureNAT client, the source port ISA server uses is each time higher than the previous one. Therefore, the chance that a connection request is received by the POP3 server for which a connection is still in the TIME_WAIT state is very, very small. So, the final question is: why does ISA behaves different for a connection request originating from a Firewall and SecureNAT client, and what can be done so that ISA behaves like a normal host in allocating the source port? Thanks, Stefaan