IKEv2 Slow

M270 on 12.7. We've been using IKEv2 for a number of months now and it hasn't been an issue as most of our employees use RDP. We have a couple of employees that use remote laptops that also use IKEv2 to access network resources, myself included. The access to all resources works, but it's unexpectedly slow. Our office has 1Gb fiber and I have 200 Mb fiber, but when I use iPerf to test the connection to my server I'm getting less than 3 Mb transfer speeds. Any ideas why it's less than what I would expect or is this exactly what I should expect?

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @ALyman

    The issue is likely the protocol in use -- it sounds like you're trying to access SMB file shares. SMB doesn't work well over connections with latency (it was never really designed to.)

    We have a KB about it here:
    (Why are SMB/CIFS file transfers so slow over my VPN?)
    https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA10H000000g33SSAQ&lang=en_US

    This article also does a really good job of explaining it:
    (Issues With SMB File Transfer Performance Over VPN) -- External link
    https://www.mirazon.com/issues-with-smb-file-transfer-performance-over-vpn/

    -James Carson
    WatchGuard Customer Support

  • Could well be a MTU issue.
    You can manually set the MTU at either or each end to 1400 and see if that helps.
    You can also use Alan's PMTU script to change Windows so that it automatically identifies the correct MTU to use for a session.
    I have listed that script in this topic:

    IKEV2 sound
    https://community.watchguard.com/watchguard-community/discussion/comment/5280#Comment_5280

  • Did anyone come up with a solution to this?

    iPerf from machine A to machine B on another site through BOVPN using internal address gets around 11Mbit, same machines but with a SNAT from the external IP into machine B and pointing A at the external IP gets 150-200Mbit. The "A" end has 300Mbit ethernet and side B has 500/50 broadband.

    A is M270, B is T30.

    If I replace the T30 with spare T10 into the same router/switch we get 80-90Mbit through BOVPN.

    WG just RMA'd the T30 as they saw some errors in log but the returned unit, hand setup replacement (to avoid any possible moved over dodgy rules or settings) did exactly the same as the old one.

    Tried lowering MTU, adjusting CF settings, all the tunnels created from scratch etc.

    May get help through the case still but seems you have same issue?

  • It seems as if the T30 is not using on board crypto support for this BOVPN, whereas the T10 is.

    What Phase 2 IPSec proposal are you using?

    The T30 has a NPX P1011 processor, which includes on board crypto support for 3DES, AES, RSA/ECC, MD5/SHA,

    https://www.watchguard.com/help/docs/hardware guides/Firebox_T30_T50_Hardware_Guide.pdf
    https://www.nxp.com/docs/en/fact-sheet/QorIQ_P1.pdf

    The specs for the T10 don't specify which exact processor is used, so I can't tell what on board crypto support is available.
    https://www.watchguard.com/help/docs/hardware guides/Firebox_T10_Hardware_Guide.pdf

    Perhaps this is a firmware issue on the T30 to not use the on board crypto support.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @Dragon_IT
    If you're sending SMB between the two sites, the problem is almost always going to be latency. SMB won't actually send more data until the previous segment is ack'ed by the recipient.

    If you can reply with your case number, I can have the lead team check and ensure your case is with the correct team to help with this type of issue.

    -James Carson
    WatchGuard Customer Support

  • If the transfer protocol is the same, there should not be this dramatic difference between a T30 (very slow) and a T10 (not slow)

  • This behavior definitely is odd because a T30 is normally a MUCH faster device than a T10.

    Following out of curiosity!

    Gregg Hill

  • What the resolution to this issue was (if there was one...)?

Sign In to comment.