ISA To TMG – Site To Site IPSec VPN

I recently encountered an issue creating a site to site IPSec VPN tunnel between Microsoft ISA Server 2006 and Microsoft Forefront TMG 2010. The IPSec tunnel itself would establish correctly, however I found I could only contact resources at either end of tunnel if I initiated the connection from either the ISA or TMG servers themselves. If I attempted to send a PING command from a workstation on the ISA internal network, to a workstation on the TMG internal network it would simply timeout. CIFS, FTP and web traffic all suffered the same fate.

After creating the topology in a test virtual environment, I was able to replicate the exact same issue I was experiencing in the production environment. After a few days of performing traces, I contacted Microsoft Partner Support to ask if they had experienced this problem before. They informed me they had and it was addressed in post SP1 hotfix KB 980674. Even though my TMG toplogy did not contain an NLB, and the KB article specifically states the hotfix is for NLB topologies, it resolved my issue never the less. To ensure your ISA to TMG IPSec site to site VPN works correctly ensure the following actions are performed:

1. Ensure the name of the IPSec VPN is the same on both the ISA and TMG servers. For example, in the site to site VPN wizard on your TMG server, if you name the tunnel “IPSec VPN” this name must also be used when you set the tunnel up on the ISA server.

2. Change the IPSec Phase 1 and Phase 2 security settings on your TMG server to match those on your ISA server. By default, TMG uses a higher level of IPSec encryption than ISA. You can obtain the IPSec security settings by reviewing them in the properties of the site to site VPN tunnel as shown in the below screenshot.

IPSec Settings 250x300 ISA To TMG   Site To Site IPSec VPN

3. Ensure the network address ranges you assign in the site to site tunnel wizard are correct. For example, if you are setting up the VPN connection on your TMG server and the ISA servers internal network address range is 172.16.10.0 – 172.16.10.255 you must specify the network in the tunnel wizard as 172.16.0.0 – 172.16.255.255, otherwise traffic will not pass over the tunnel correctly.

4. Ensure your ISA and TMG servers are fully service packed and all hotfixes are applied, in particular hotfix KB 980674 on your TMG server, even if you do not have an NLB configuration.

Hopefully this help will solve any cross platform IPSec VPN issues you are experiencing.

OCS 2007 R2 – External Audio/Video Conferencing Issues

The successful implementation of external audio/video conferencing in Microsoft OCS 2007 R2 appears to be an issue that many people face when deploying the product. I too have experienced this issue and this post will detail both the errors and resolutions put in place to enable external A/V conferencing on an OCS 2007 R2 Standard Edition deployment with a Consolidated Edge server. The implementation item’s listed in this post assume you have a firewall product in front of the Consolidated Edge server that is performing both resverse proxy and NAT features.

1. External A/V Conferencing – Errors

When testing multiparty A/V conferences I experienced the following errors. These errors were produced when adding a third participant to an existing two party (peer to peer) A/V conference.

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

The call was disconnected because you stopped receiving audio from user@externaldomain.co.uk. Please try the call again.

An error occurred while trying to take the call off hold. If the problem persists, contact your system administrator. More details (ID:500)

An error occurred while trying to start the conference. More details (ID:52031)

As you can see, there is not a single persistent error that is produced which unfortunately makes troubleshooting slightly more difficult. After spending some time performing SIPStack traces and reviewing Communicator logs via the Snooper Tool, I narrowed the errors down to a firewall and consolidated edge server configuration issue.

2. External A/V Conferencing – Resolution Items

The item’s listed below resolved the external A/V conferencing issues I was experiencing. These steps are also included in the official Microsoft production documentation for Consolidated Edge server deployments.

A/V Edge Service Name Resolution- Configure the Edge Server to resolve the FQDN associated with public A/V Edge service to the publicly routable IP Address, not it’s internal NAT’d IP address. For example, if your A/V Edge service has a public IP address of 100.200.255.255 and a NAT’d IP address of 10.45.16.5, if you run a command prompt from the Edge Server and type ping av.externaldomain.co.uk it must return 100.200.255.255. A good way of achieving this is making a hosts file entry on your Edge Server to force the FQDN to resolve to the public IP address.

A/V Edge Service NAT- Assuming you have a firewall product (ISA/TMG) in front of your Consolidated Edge server that is performing NAT, configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox. This setting can be found under the Edge Servers properties dialog box.

Firewall Access Rules- Configure your firewall product with the following protocol definitions to allow A/V traffic to be passed to your Consolidated Edge server. Once you have performed this, create a new server publishing rule that targets your Consolidate Edge server and utilises the protocols you have just created.  Please note the below protocol definitions target ISA/Forefront TMG deployments specifically. A very useful article on performing this can be found here.

Protocol nameAV TCP In
Protocol typeTCP
DirectionInbound
Port Range50000-59999
Protocol nameAV UDP in
Protocol typeUDP
DirectionReceive/Send
Port Range3478, 50000-59999

Testing Access - If you are using internal clients to perform multiparty A/V testing then ensure those clients have unrestricted access through your internal firewall. I experienced an issue where outbound traffic from my test clients was being blocked by my internal firewall, which in turn created additional issues. Ensure you have complete outbound access for your test clients and then scale back access from there.

I hope this assists your external A/V conferencing implementation.

ForeFront TMG & GFI MailEssentials – Updating Issues

I have recently experienced an issue on several deployments of Microsoft ForeFront Threat Management Gateway in conjunction GFI MailEssentials 2010. When installing GFI MailEssentials on a server running ForeFront TMG, a configuration error occurs in the MailEssentials config.mdb file which incorrectly points the spam definition updating entry to “C:\Program Files\” opposed to “C:\Program Files (x86)\”. Due to this, updates for spam modules such as Phishing and SpamRazer do not download correctly and as a result you may experience the following error:

GFI 254x300 ForeFront TMG & GFI MailEssentials   Updating Issues

Despite the error stating the problem occurred due to a “network error”, it certainly is not and several hours of testing with ForeFront TMG’s own monitoring utilities and WireShark proved this theory correct. To resolve the issue, please perform the following actions:

1. Stop all GFI MailEssentials services and the Message Queuing service on the server running GFI MailEssentials 2010.

2. Click Start, and select Run. In the Run dialog box type the following without quotations “iisreset /stop” , and click ok

3. Navigate to the folder “C:\Program Files (x86)\GFI\MailEssentials” and copy the config.mdb file to a workstation that has Microsoft Access 2003 or higher installed.

4. Open the config.mdb file in Microsoft Access and open the table named “au_profiles”. In this table locate the “localpath” entry and change this to be “C:\Program Files (x86)\” opposed to “C:\Program Files\”

5. Save the amended config.mdb file and then copy this to the “C:\Program Files (x86)\GFI\MailEssentials” directory on your server, choosing to overwrite the existing file.

6. Click Start, and select Run. In the Run dialog box type the following without quotations “iisreset” , and click ok.

7. Start all GFI MailEssentials services and wait for, or manually update your anti-spam module definitions.