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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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?
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...
Cloud as a Security Delivery Platform for MSSPs

Every Managed Security Service Provider (MSSP) needs a platform to deliver effective and efficient security-as-a-service to their customers. Scale, elasticity and profitability are a few of the many features that a Cloud platform offers. View our on-demand webinar to learn more!

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.
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.