I've just installed the newly released successor of Microsoft ISA Server 2006 in my test lab: Microsoft Threat Management Gateway 2010. It should offer better support for SIP and RTP protocols behind NAT setups. I'm running tests now to see if it all works fine with 3CX. One thing I came across which drove me nuts was activating the license. I had the 3CX setup running for months without any problems already. After changing my gateway from ISA 2006 to TMG 2010 my 3CX installation suddenly reported as not being registered and activated anymore. Weird. I could also not active the license anymore. This would give me a popup stating: "License.unexperrLicense Key Activation Failed Licence: 61 System: 0." Not really something that helps in pointing to the problem. After reinstalling 3CX and still having this problem I ran some sniffers on the network to see what 3CX was transmitting for the activation and what could be that it wouldn't like. I found out that TMG 2010 has built in HTTPS traffic scanning. It does this by intercepting the HTTPS packets, providing a "spoofed" self created certificate to the client thus being able to open the packets, opening the packets and retransmitting them onwards to their destination using the original certificate if the contents are approved. All sounds pretty well thought of, except that 3CX has some built in verification that checks if the communication is indeed with the HTTPS certificate 3CX expects to receive at erp.3cx.com. I guess to prevent packet hijacking and sending an ACK to a non-valid key yourself. Fair enough. A way to get around this is to exempt your 3CX server from having its HTTPS traffic scanned by TMG2010. To do this, go into the TMG2010 Management Console, expand your TMG2010 server or server array, go to Web Access Policy, click at the top at the Enabled link behind the text HTTPS Inspection. go to the tab Source Exceptions and add your 3CX server to the list on that tab. Note: adding a destination exception will not work since TMG2010 will still need to open the HTTPS packet in order to know the destination and match it with the exempt rule. This will still make 3CX dislike the response because the packet will be repackaged and signed with a TMG2010 self created certificate. So do use the Source Exception instead. After applying my changes (and waiting a few more minutes to be sure the change was replicated through the array), I tried activating again and voila.. activation succeeded. Hope this may help others facing the same problem save some time and hair pulling.