slow transfer speeds ove ipsec
-
@hescominsoon If we could get all the IPsec settings you are using (except the PSK and IPs of course lol) that would greatly help here.
You have to user ciphers that are properly accelerated and then make sure you have IPsec MB and/or QAT enabled.
-
@planedrop i am using aes 128 and AES-NI CPU Crypto: Yes (active)
IPsec-MB Crypto: Yes (active) sha 256 dh group 14. everything else is pretty much at defaults..i am using psk as well. -
@planedrop said in slow transfer speeds ove ipsec:
@hescominsoon If we could get all the IPsec settings you are using (except the PSK and IPs of course lol) that would greatly help here.
You have to user ciphers that are properly accelerated and then make sure you have IPsec MB and/or QAT enabled.
so i compressed the files into one large 580 gb file after checking rss and such i am getting around 100 megabits...with bursts to 120.
-
@hescominsoon AES-GCM? Or normal AES? GCM will get you much much better results.
-
Use AES-GCM and check "Asynchronous Cryptography" and "Make before Break" is activ in IPsec Advanced Settings.
Setup "Enable Maximum MSS" and set it to 1328, you will find it under: System Advanced Firewall & NAT.
I use "IP Fragment Reassemble" too.
This 1328 is the best MSS for IPsec tunnel mode if you want to avoid padding data.And don't use SMB over high latency connections, it's very slow. Use rsync or other WAN optimized stuff instead. Even ftp performance better, if you run up to 10 paralle streams.
Netgate 6100 & Netgate 2100
-
@NOCling IIRC but make-before-break is only needed if you are doing re-auth rather than rekeying.
Also not sure how big a difference async makes, I have VPNs that move gigabit without that set, but I do have dedicated CPIC cards for acceleration so maybe it'd make more of a difference on normal hardware. Either way async can break things.
Agreed about the 1328 MSS, though not all TCP workloads support clamping. I have a setup where clamping isn't supported so traffic is fragmented no matter what (in fact 100% of packets are fragmented and I still can manage gigabit lol).
And yeah @hescominsoon like @NOCling says, SMB really isn't ideal for this, if you actually need to move data super fast over a VPN, you should look elsewhere. Even NFS should be better.
-
@planedrop i will switch it to gcm and see..no i do not need this super fast...but this is the initial seeinding to a remote file share member DC...but it's for if the worst happens so smb will be used no matter what. Let me change the the other AES and try this again.
-
@planedrop said in slow transfer speeds ove ipsec:
@hescominsoon AES-GCM? Or normal AES? GCM will get you much much better results.
switched aes to 128 gcm and thgat got me..nothing sustained in terms of speeds...
-
@NOCling said in slow transfer speeds ove ipsec:
Use AES-GCM and check "Asynchronous Cryptography" and "Make before Break" is activ in IPsec Advanced Settings.
Setup "Enable Maximum MSS" and set it to 1328, you will find it under: System Advanced Firewall & NAT.
I use "IP Fragment Reassemble" too.
This 1328 is the best MSS for IPsec tunnel mode if you want to avoid padding data.And don't use SMB over high latency connections, it's very slow. Use rsync or other WAN optimized stuff instead. Even ftp performance better, if you run up to 10 paralle streams.
i was unable to set it to anything but 1400 as it was greyed out. after making those changes i actually lsot half of my speed. so i will be undoing some of them to get me back to where i was previously...with this being two windows machines...i might try setting up a temporary ftp server on the remote side..but they wil be using smb so i have to make that work the best i can for now eventually.
-
@hescominsoon so turned on everything suggest3ed here and even setup an ftp server on the remote...transferring the one large file is now down to 60 megabits..and will not go any faster. I am at a loss as to why i have now halved my transfer speeds from ftp instead of smb...
-
@hescominsoon Can you list all of your IPsec settings in detail (other than IP addresses)?
-
@planedrop i put everything back to defaults..deleted the big file and am using filezilla to transfer everything to an ftp server i setup on the destination temporarily. i have 10 transfers going at once and am touching 220 megabits now..which is nearly the bandwidth at the remote iirc(the source just got upgraded to 500 megabits)...i will tinkert some more but so far the only change i am running now is the gcm version of aes..literally everything else is at defaults
-
@hescominsoon No I mean your settings for the IPsec tunnel itself, there aren't "defaults" you have to configure things.
For example, is your Phase 1 IKE V2? What authentication method? AES128-GCM but what is the Key Length and DH Group set to?
I think the best way we can help is if we have a list of every setting that is configured on your tunnel for both phase 1 and phase 2. Then we can give better advice on what to adjust to improve performance.
-
@hescominsoon now the 71 is using up to 56 percent cpu..i am ok with that at least i am seeing decent performance...:)
-
@planedrop said in slow transfer speeds ove ipsec:
@hescominsoon No I mean your settings for the IPsec tunnel itself, there aren't "defaults" you have to configure things.
For example, is your Phase 1 IKE V2? What authentication method? AES128-GCM but what is the Key Length and DH Group set to?
I think the best way we can help is if we have a list of every setting that is configured on your tunnel for both phase 1 and phase 2. Then we can give better advice on what to adjust to improve performance.
i am using and AES-NI CPU Crypto: Yes (active)
IPsec-MB Crypto: Yes (active) sha 256 dh group 14 aes-gcm 128 that's what is in phase 1 i am using psk for authentication the key kength is 128 as per aes-128.... -
@planedrop yes ike is v2 which is what the system setup by default...:)
-
so now with everything as the system did by default when i first setup the vpn(with the exception of switching to aes gcm 128 instead of regular aes-128) and using ftp with 10 simultaneous transfers i am seeing a maximum of 400 megabits...which works much better.
-
@hescominsoon glad it's working better. GCM is far more efficient and is the way to go if you care about speed.
As for key length, I was asking about that setting because the key length setting actually becomes the ICV when you use AES GCM (it just doesn't dynamically rename itself).
Also, if you care about security, I would recommend using DH21 instead, 14 is fine but 21 is a good amount more secure.
Glad you are seeing better performance though, that is almost certainly due to GCM being used.
-
@planedrop said in slow transfer speeds ove ipsec:
@hescominsoon glad it's working better. GCM is far more efficient and is the way to go if you care about speed.
As for key length, I was asking about that setting because the key length setting actually becomes the ICV when you use AES GCM (it just doesn't dynamically rename itself).
Also, if you care about security, I would recommend using DH21 instead, 14 is fine but 21 is a good amount more secure.
Glad you are seeing better performance though, that is almost certainly due to GCM being used.
i will switch it to 21 once this half terabyte transfer completes..i am way behind now trying to get the performance worth using...:)
-
@hescominsoon Totally get you yeah. 14 is still considered secure but may not be considered so for much longer, so I'd say no rush on it but yeah swap to 21 when you can. You shouldn't really see much of a performance degradation with it either, if any at all.
I'd recommend 21 for both Phase 1 and 2.
