@obi Solved! The problem was caused by remote network configuration that two vpn client use same P2 local ip.

Found a similar older topic: https://serverfault.com/questions/734086/slow-cifs-file-copy-over-routed-network-with-different-bandwidths However disabling Jumbo and Netbios doesn't help... Our internet provider (TIM) suggested that's a CIFS issue, because windows file transfer works fast over LAN but not over WAN interfaces... In fact Iperf test values are in the order of 260Mbit/s, as sender and receiver, and that's good... They recommended to reduce Windows MTU to 1490 but the troughput is the same... Does anyone has some tuning to suggest?

@jimp Thank you sir, that did the trick, after I setup mobile config, applied settings and saved the authentication fields appeared. Much appreciate the assist sir.

@bert-0 As you wrote above, the IPSec status shows that the connection is established. So it might not be blocked at all.

@michmoor Look at the number of posts of that user : 1 So : on the triple point : [image: 1679380104832-102848a4-c6ff-4f7b-b4a9-a931deea7d08-image.png] and flag the post. Later on, as by magic, the polutware will be gone.

Want to confirm we're seeing the exact same thing here - we've got a bunch of 2.4.x in production we just upgraded to 2.6.0, with quite a few tunnels going between them, and it's been running flawlessly for 2 years now. All are running virtually, and on the other side we've got a mix of netgate 2100s recently upgraded to 23.01. The issue only happens between some 2.6.0s - we'd see things hang with both sides trying to initiate. In the logs: "ignoring acquire, connection attempt pending". We used nearly half a day debugging this, and the only way to get things to come up reliably (and so far, stay up), was to roll back one side to 2.4.4. Tunnels suddenly came up.

@konstanti Hi, thanks for coming back to me. I have an Network Alias with all of my subnets, on both sides, attached to the Alias. I have Allow All for the alias networks.

@scarrrr So both p2 seem to be up as well. No idea then, why you can't access the remote site. Maybe are there different routes for the remote networks?

@viragomann Just wanted to thank you! This was something I had been trying to do as well and solved my problem!

Hi, I didn't solve it even after updating to 23.01-RELEASE (amd64), FreeBSD 14.0-CURRENT. Can someone help me please? I am additionally attaching the openssl rdrand and devcrypto tests, between which there is no difference, I get the same result without the QAT card on AES-NI. WITH HARDWARE ACCELERATION (rdrand + devcrypto): /root: openssl engine (devcrypto) /dev/crypto engine (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support /root: openssl speed -engine rdrand -evp aes-128-gcm engine "rdrand" set. Doing aes-128-gcm for 3s on 16 size blocks: 109473266 aes-128-gcm's in 3.15s Doing aes-128-gcm for 3s on 64 size blocks: 59620644 aes-128-gcm's in 3.06s Doing aes-128-gcm for 3s on 256 size blocks: 37145965 aes-128-gcm's in 3.05s Doing aes-128-gcm for 3s on 1024 size blocks: 12758891 aes-128-gcm's in 3.07s Doing aes-128-gcm for 3s on 8192 size blocks: 1961291 aes-128-gcm's in 3.06s Doing aes-128-gcm for 3s on 16384 size blocks: 1004601 aes-128-gcm's in 3.09s OpenSSL 1.1.1t-freebsd 7 Feb 2023 built on: reproducible build, date unspecified options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-gcm 556330.64k 1245949.78k 3121023.03k 4255301.17k 5246333.35k 5320204.54k /root: openssl speed -engine devcrypto -evp aes-128-gcm engine "devcrypto" set. Doing aes-128-gcm for 3s on 16 size blocks: 109588628 aes-128-gcm's in 3.09s Doing aes-128-gcm for 3s on 64 size blocks: 58764133 aes-128-gcm's in 3.08s Doing aes-128-gcm for 3s on 256 size blocks: 36989212 aes-128-gcm's in 3.08s Doing aes-128-gcm for 3s on 1024 size blocks: 12517930 aes-128-gcm's in 3.03s Doing aes-128-gcm for 3s on 8192 size blocks: 1892616 aes-128-gcm's in 3.01s Doing aes-128-gcm for 3s on 16384 size blocks: 962895 aes-128-gcm's in 3.02s OpenSSL 1.1.1t-freebsd 7 Feb 2023 built on: reproducible build, date unspecified options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-gcm 566761.39k 1221816.69k 3076300.76k 4228737.43k 5154679.78k 5217925.52k NO HARDWARE ACCELERATION: /root: openssl engine (rdrand) Intel RDRAND engine (dynamic) Dynamic engine loading support /root: openssl speed -engine rdrand -evp aes-128-gcm engine "rdrand" set. Doing aes-128-gcm for 3s on 16 size blocks: 102136466 aes-128-gcm's in 3.01s Doing aes-128-gcm for 3s on 64 size blocks: 60435126 aes-128-gcm's in 3.16s Doing aes-128-gcm for 3s on 256 size blocks: 36288986 aes-128-gcm's in 3.04s Doing aes-128-gcm for 3s on 1024 size blocks: 12394560 aes-128-gcm's in 3.03s Doing aes-128-gcm for 3s on 8192 size blocks: 1920849 aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on 16384 size blocks: 1021912 aes-128-gcm's in 3.18s OpenSSL 1.1.1t-freebsd 7 Feb 2023 built on: reproducible build, date unspecified options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-gcm 543312.94k 1225456.81k 3056857.31k 4187061.26k 5245198.34k 5265613.75k /root: openssl speed -engine devcrypto -evp aes-128-gcm invalid engine "devcrypto"

@nogbadthebad Thanks for sharing that config. I will make some experiments with the settings. Currently I am trying to catch the error on the console. Still no success. Still no more sudden reboots.