Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 3 subscribers
  • Views 5628 views
  • Users 0 members are here
Options
Suggested
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

IPSEC between multiple sites very slow

mjpmotw

We are running several Sophos UTM with the 9.7 firmware: SG330 (HA), SG230 (HA), 4xSG115 and about 8 x RED15. All sites have ISP between 25/100 and 1000/1000 (main office).

They are all connected using IPSEC or the RED Interfaces forming a hub and spoke connection (any site goes to any site).

As all sites need to reach all sites, we have only one tunnel configured between each site, but to reach across, we had to add local networks creating around 50 IPSEC connections on the hub.

 

PROBLEM:

For several weeks, we are encountering very slow IPSEC traffic between those sites. Only between 3-5 MBit/s instead of 25-300 MBit/s as before and as expected.
Review the firewall history we couldn't identify a suspious change. Users report that the issue started in December. 

We have tried to isolate the problem but failed. We have tested the following changes:

IPS, ATP, Web filter, Country blocking
Any actions in these Modules on/off have no effect on the performance in the tunnel. IPS had all local and remote subnets in the exception lists.

Firewall
All RED and all IPSEC tunnels create an exception rule via automatic firewall rules.

MTU
Set to 1500 for all WAN interfaces, all direct internet connections are fast according to "real data transfer" and iperf. Only the IPSEC tunnel ist slow.

CPU Load
The sg115 are rather weak but there is no CPU spike or lag. We had IPSEC with 300/300 about a year ago with the same hardware.

Routing
We could rebuild the hub/spoke with routing instead of many IPSEC tunnels (currently over 50 tunnels).

UTM RED
We didn't try this yet but we could replace the IPSEC connections with UTM-RED connections, with manual routing and firewall rules.

IPSEC VPNID
We are using the VPN ID = public DNS (public IP) of each site.

IPSEC Compression and Policies
Tunnel Compression and different policies AES128/256 etc. have no effect.

IPSEC MTU path discovery
We have set the MTU path discovery for all IPSEC connections on both sides.

IPSEC initiate/respond
According to Sophos, the branch offices should initialize.

Dedicated WAN
The main office has two WAN connections so we are using the uplink interface and the bind-to-interface-option in multipathing as recommended for availability reasons. We could simply set this to one interface.

Firmware up/down
We took a spare sg115 and downgraded from 9.7 to 9.6 with no effect.

Sophos Case
We have escalated the case to Sophos. They are very helpful but the support was unable to identify a root cause for this slow tunnel behavior.

Any other ideas?



This thread was automatically locked due to age.
  • 0 in reply to Ehigbai Iyemifokhae

    Thank you for your help, your questions have all been answered in my inital posting above. MTU discovery, blocking, logs, exceptions, all done. Differet tunnel initiation/response, different DES/3DES etc. have a minor effect that is not resolving the issue. WAN are mostly fiber or Coax and not PPPoE so MTU should be fine and is in testing. Now testing MSS.

  • 0 in reply to mjpmotw

    Matthias, what happens if you set the MSS of the tunnel to something like 1320?

    iptables -I FORWARD 1 -o -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1320

    That's a trick posted by Sascha Paris on 3-Mar-2014.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Sophos Support says that as of today, this it the iptables command for MSS:

    iptables -t mangle -I POSTROUTING -s 192.168.0.0/24 -d 172.16.16.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;
    iptables -t mangle -I POSTROUTING -s 172.16.16.0/24 -d 192.168.0.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;

    Change the source and destination networks for your networks.

    You can confirm the entries are added by listing the POSTROUTING chain in the mangle table of iptables:
    iptables -t mangle -L POSTROUTING;


    You can remove the custom entries with the following commands if you encounter any problems:

    iptables -t mangle -D POSTROUTING -s 192.168.0.0/24 -d 172.16.16.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;
    iptables -t mangle -D POSTROUTING -s 172.16.16.0/24 -d 192.168.0.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;

    These entries will not be retained through a reboot but a speed test after applying this may tell you if the issue is related to MSS

    -> we need to check this and - if still valid - the "iptables -I FORWARD 1 -o -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1320;"

  • 0 in reply to mjpmotw

    All those iptables-commands had no effect. We applied and verified. Whatever the underlying cause is...

    We also did more UTM RED Tunnel Testing and found out that the UTM RED Tunnel is way faster than the IPSEC. We simply don't know why.

  • 0 in reply to mjpmotw

    I bet you're felling like you're beating a dead horse, Matthias...

    If you don't want to just stay with the RED tunnels, I still think it would be worth trying fixed speed/duplex with reboots of the devices to force them to renegotiate.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML