IPSEC Site-To-Site VPN Slow

Hi,

I have an strange issue, When I download a file from internet I get the maximum speed of my ADSL connection (13Mbit) But when I download from my remote site using a IPSEC tunnel i only get 2-4Mbit per stream.
If I download via multiple streams every stream get 2-4Mbit and I can get the maximum speed.

The CPU is never close to maxed. Only 1-2%.

I have Path MTU enabled and also ECN on both sites. I have tried without also but the same result.

Anyone got an idea on what could be the cause of this?

Best Regards
Frank
  • I know this is an old thread, but I ran into pretty much the exact scenario described here except that our sides were using different hardware. One side was using a cisco ASA 5510 and the other was a UTM 9.3.10 virtual appliance.

    Just like the OP, the symptom was that each individual connection stream could only use about 2-5MB of bandwidth, but we could use multiple connections at the same time to get the full speed of our connection (about 80MBs).

    In our case, it was a problem with the Cisco ASA's software. We never found out exactly what, but replacing the config from scratch, with identical settings for the IPSEC tunnel, on the ASA resolved the issue. No changes where needed on the UTM.
  • In reply to tkent:

    I know this is an old thread, but I ran into pretty much the exact scenario described here except that our sides were using different hardware. One side was using a cisco ASA 5510 and the other was a UTM 9.3.10 virtual appliance.

    Just like the OP, the symptom was that each individual connection stream could only use about 2-5MB of bandwidth, but we could use multiple connections at the same time to get the full speed of our connection (about 80MBs).

    In our case, it was a problem with the Cisco ASA's software. We never found out exactly what, but replacing the config from scratch, with identical settings for the IPSEC tunnel, on the ASA resolved the issue. No changes where needed on the UTM.


    Speaking of the ASAs, by default the hardware crypto accelerator is not enabled. This is usually the cause for slow IPsec VPNs on ASAs.

    To check the status
    show crypto accelerator statistics

    To enable
    crypto engine accelerator
  • Also experiencing poor bandwidth via site-to-site.  My observations should it help:

    scp a 1 GB file:
      From: UTM-9.315-2  s/w
      To: UTM-8.310  s/w

    Scenario 1
    -------------
    275 KB/s  over site-to-site IPSec VPN (AES-128 PFS,) no IPS enabled on either end. Destination is metal host on a 1-Gbit network.

    Scenario 2
    -------------
    6.6 MB/s directly to destination firewall where source is behind firewall.

    Comment
    -----------
    The metal host in Scenario 1 pulled the 1 GB file from the destination firewall in Scenario 2 @ 55 MB/s.
  • Hello,

     

     i know it's an old thread: I had the same issue, disabling UDP flood protection did the trick for me.

  • In reply to ManagedServices1:

    Hi, and welcome to the UTM Community!

    Rather than disable UDP flood protection for everything, check the Intrusion Prevention log to see what Exception(s) you need to add.

    Cheers - Bob 

  • In reply to BAlfson:

    We have had the same problem in our company for about 4 weeks.

    Two locations Site to Site VPN:

     

    Location 1: SG135, 500/500 Mbit, FW: 9.605-1

    Location 2: SG125, 100/30 Mbit   FW: 9.605-1

     

    Since the last firmware update the SitetoSite VPN is extremely slow. I can only get a speed of exactly 780 KB/s.

    Before the update we were able to use the full bandwidth.

     

    Both tunnels have already been deleted, restarted the Firewall´s and tunnels newly set up. No improvement.

    IPS is not used at either site and MTU support is also active.

     

    Any ideas?

    Thanks

  • In reply to Johannes Lang1:

    I responded on your thread in the German Forum.

    Cheers - Bob

  • In reply to TKITFrank:

    Try to reduce the MTU at the client drastically.

    Possible you got usable speed with MTU 1200.

    next try to send and receive data.

    Is one direction good/ok and the other poor ... possible a duplex-mismatch-problem.