Exchange / Outlook - Attachment timeout problem using VPN

First of all, the network setup. We have two offices in separate towns. In the HQ, we have 2 ADSL lines connected to a Watchguard Firebox X550e. The internal network is on a range.

In the branch office, we have 2 ADSL lines connected to a Draytek 3300V+ load balancer. This network is on a range.

There is a VPN in place between the two offices.

The HQ has SBS 2003 running, and the branch office is using Outlook 2003.

Here's the issue. Using Outlook 2003 in the branch office, when users try to send an email with an attachment, the email either takes a long time to send, or times out with Outlook saying it's lost connection then has reconnected etc....

To test the problem further, I've used a web browser to connect to the Exchange server and send an email, and here are the results:-

The attachment is a PDF of 3.81MB in size.

When I'm connected to the exchange server using the internal server name (whether fully qualified or not) or it's internal IP address, when I click the button to attach the file the status bar sits with the "Sending request to ip address or server name" message for 6 minutes before the file shows as attached. Obviously, this traffic should be going through the VPN tunnel.

However, if I perform the same action, but this time in the browsers address bar use the external ip so that the traffic doesn't get router through the tunnel, then it takes around just 25-30 seconds to attach the same 3.81MB attachment.

Users in the HQ don't have any issues using Outlook.

I need to resolve this issue so that users can use the Outlook client properly and not have issues with it timing out...

LVL 17
Chris MillardAsked:
Who is Participating?
We have used WatchGuards in the past and have always forced ALL traffic through the tunnel.  If you hadn't found the packets going other directions I would suggest authentication/DNS issues to the email server or DSL issues with packet size (MTU) issues.

Since you say there are packets going out the wrong way - on out boxes we did little or nothing in the policy and let the VPN config control it as it was set to local subnet to ANY forcing all packets through the VPN.  If that isn't what you want then your description of the policy order should have your VPN subnet policy before all else so that it is processed first.  It should show from local subnet, any protocol, to remote subnet.

If your network knows where the resources are (DNS, etc.) then it should only look for the resource on the remote subnet and follow the VPN route and policy to get there.
Could be an issue with your VPN tunnel speed. Usually there's a license for higher bandwidth on network devices when using VPN, but when going over the internet it's a simple HTTPS connection that is considerably faster.
Chris MillardAuthor Commented:
OK - as a test, I've just copied a 67MB file over the VPN, and it took around 8 minutes - so why would a <4MB attachment take 6 minutes to attach using OWA, and not send at all using Outlook?
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

Chris MillardAuthor Commented:
Looking at the hostwatch on the Watchguard, it would seem that all TCP traffic from the branch to the HQ is coming in over the VPN, but all UDP traffic destined foe the range from HQ is going out through the external interface and not over the VPN...
Is your BOVPN Policy for Any Traffic or just TCP Ports?
Do you have a Policy higher in the order that could be routing UDP traffic or some UDP traffic out to the external interface?
Chris MillardAuthor Commented:
The BOVPN policy is for ANY traffic. Immediately above it is another policy called Outgoing which is a TCP-UDP policy and is set from Any to Any-External, Any-Trusted and PPTP-Users (Firebox-DB).

I have added To Any-BOVPN to this policy and saved the configuration, but the hostviewer is still showing outbound UDP traffic going out through the External Interface
The outbound UDP traffic going through the external interface, does any of it have a destination address that is in your private IP space? If it does, that is a problem, otherwise that is normal. If you want to force ALL UDP traffic through your VPN you could, but I don't think that's what you want.

It sounds like the remote IP space in the Branch Office Tunnel may not be set correctly.

As a side note in the To for your Outgoing policy you only need Any-External, not the other two. May not be causing your problem, but I don't usually see a reason to have it set that way.
Chris MillardAuthor Commented:
Problem actually turned out to be the packet size. It was fragmenting at 1417 bytes. Lowering the MTU on the Firebox from 1500 to 1400 cured the issue.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.