Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Slow Site to Site VPN

Hello all, I've been reading up everything I could find on this issue, but hopefully I can get some more info here.

We currently have 3 UTMs set up in 3 geographically remote offices, all UTMs are running in DL360 G5 Proliants and CPU use only occasionally spikes to 25% and RAM use is always below 13%, the WAN ethernet port being used is the built-in Broadcom NetXtreme II BCM5708 on all 3

2 of the offices have 100/100 Fiber internet service and one has 50/10 Cable service.

We are using AES 192 MD5 encryption settings with compression off, NAT traversal on, Support Path MTU discovery and ECN on

The 2 offices with 100/100 service are set as the service initiators in the Gateway type.

IPS is off, Anti DoS/Flooding is off  QoS is off.

The Site to Site connects rapidly and reliably among all offices, but we currently cannot get more than 3MB/sec out of any service, we've tried FTP, SMB, AFP and NFS, the average data transfer we get is closer to 1 MB/sec

I've tried getting the slower office out of the S2S chain, and even turning off VPN encryption but that resulted in no change in speeds.

Anything else I can look into?


This thread was automatically locked due to age.
  • If you ping from gateway from Site A to the gateway on Site B (public addresses), what is the latency.
  • If you ping from gateway from Site A to the gateway on Site B (public addresses), what is the latency.


    48.5ms tested from the Support > Tools option in each UTM

    I also ran a Traceroute between the two UTMs on 100/100 Fiber and it showed 9 hops with no latency higher than 60ms, all within the AT&T network
  • Okay this thing helped me some time back. There were fragmentation issues (even if you have the PDMTU).

    1. Enable Shell access
    2. Login via SSH as loginuser and change to superuser.
    3. Issue the following commands

    iptables -t filter -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1440

    echo "iptables -t filter -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1440" > /var/mdw/hooks/packetfilter_advanced

    chmod 400 /var/mdw/hooks/packetfilter_advanced
  • Thanks predrag!  

    MTU issues was what I've been leaning towards, I was going to play with 1406 MTU from reading about a thousand pages on the topic, but figuring out the correct MTU is kind of a shot in the dark.

    In this case you're setting the TCP MSS with to 1440, should MTU be left at 1500?

    Our S2S is linked via the primary WAN ports, would it make more sense to have all 3 UTMs use a separate dedicated WAN link with the correct MTU for just Site to Site?
  • Hi,

    No need to change MTU of the interface. Why I have selected 1440 is simple.

    Typical MTU is 1500 bytes, IPSEC adds 52 bytes. The MTU size then it should be 1448, and sometimes when there is PPPoE involved additional 8 bytes are used. So just to be on the safe side, adjust the MSS to 1440 and leave the MTU on the interface to 1500.
  • Do you know the command to check what the current TCP MSS value is?

    I'd like to know in case I need to set it back.
  • The current value by default is the interface MTU. If you want to reset it, its done by iptables command as well.

    iptables -D FORWARD 1
    chmod 700 /var/mdw/hooks/packetfilter_advanced
    rm -rf /var/mdw/hooks/packetfilter_advanced
  • I followed the steps and they have improved speeds a bit, although I've settled on a TCP MSS of 1460 after reading up a bit more and after several tests.

    We're going to set up dedicated ethernet interfaces for the site to site and set the MTU on those interfaces to the widely recommended IPSec tunnel MTU of 1400, with a TCP MSS of 1360

    I tried those settings during office off hours and I got the best result out of the 1400/1360 combo of all the settings I had tried, but 1400 is no good for a general use WAN port, so I put it back to 1500.
  • Joe, is there a reason you don't get Sophos Support involved?  I would have expected that selecting 'Support Path MTU discovery' would have prevented this problem from occurring, so I would have opened a ticket with them.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Joe, is there a reason you don't get Sophos Support involved?  I would have expected that selecting 'Support Path MTU discovery' would have prevented this problem from occurring, so I would have opened a ticket with them.

    Cheers - Bob


    Possibly my being stubborn? [:)]

    I'll give Sophos a shout.