Link to home
Start Free TrialLog in
Avatar of Chris Millard
Chris MillardFlag for United Kingdom of Great Britain and Northern Ireland

asked on

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 192.168.16.0/24 range.

In the branch office, we have 2 ADSL lines connected to a Draytek 3300V+ load balancer. This network is on a 10.0.0.0/24 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...

Avatar of stefor
stefor
Flag of Sweden image

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.
Avatar of Chris Millard

ASKER

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?
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 10.0.0.0/24 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?
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.
ASKER CERTIFIED SOLUTION
Avatar of mrklaxon
mrklaxon

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.