Same for me, I can’t use my VPN on wireguard after upgrading. I’m going to downgrade to see what happens based on what you guys have said.
I won’t know for a week because my remote site lost power for 5 hours and my PCs all went off line. I don’t have winbox enabled on the remote WAN port so I can’t remote a PC to get in.
I do know that different SoCs implement different levels of encryption hardware offload that IPsec on RouterOS can take advantage of. Whether hardware offload happens for a particular device depends on whether that particular combination of hashing and crypto algorithms is supported for hardware offload on a given CPU/SoC; you can see the matrix of support for this here.
If you get different results (success or failure) for the same config on different RouterBOARD models, this makes me suspect that there might be some new bug that specifically impacts hardware-offloaded IPsec on particular models that maybe have a particular SoC.
It occurs to me that if this is the case, you might be able to work around it by choosing a proposal on both sides that would prevent the hEX S from trying to use hardware encryption acceleration. For example, the MT7621A in the hEX S does not support hardware acceleration when SHA512 is combined with any cipher, and also doesn’t support hardware acceleration for any hashing algorithm that is paired with AES-GCM for example. So maybe try to force it to use one of those combinations, and see if things suddenly “work” now.
If they do, then time to open a ticket with MT support to report yet another bug…
I had this same problem with Azure Vnet gateway s2s.
I changed to sha256 and aes256 cbc (I had gcm previously) - as according to the hw support table-and traffic started flowing.
Same here on a Hex S. Had to switch to AES-256 with SHA-256 (SHA-512 not hardware encrypted) or else unit would keep rebooting on phase 2 establishing in 7.19 and just not work in 7.18.
Same
BR5009 —> CHR, both 7.18.2, pure L2TP (no IPSEC)
I catch some logs about and being confused why it uses ZERO dest port, it SHOULD be 1701
sent control message to X.X.X.X:0 from X.X.X.X:1701
I step back on 5009 to 7.16.2 and it looks like it uses the right port now, see below (but still no real connection)
sent control message to X.X.X.X:1701 from X.X.X.X:1701
As far as I see (using logging, w\o pcap or wireshark)
- RB5009 sends messages to CHR, but an input-log-firewall rule on CHR (on the top) catches NO packets at all
But catches OK when i just doing
telnet X.X.X.X 1701
Weird
After some support polemics they recommend me to update on latest (unofficial) 7.20 - no visible effect
so still not resolved I see, did you say .20 is fixed?
Same here, on HEX router
Keeps rebooting over watchdog
I do have IPSEC tunnels too, but not tested as reboot halted everything very soon
Downgrade to 7.17.2 is now working Ok
Oh. Wild. I was suggesting the OPPOSITE: that the crashing was happening when it was USING hardware encryption offload, so switch to an algorithm that the hEX S DOESN’T support with hardware encryption, to force it to drop down to software.
It’s sounding, though, like maybe hardware encryption is what works, but software encryption does NOT?
I just scrolled back to the very first post to look at the config in more detail, and sure enough: it also specifies hash of SHA512, and a proposal with 128-bit AES-GCM. Both of which would not be hardware-offloaded. So…!
That’s bananas. The software encryption/hashing I would expect to be the “safe path”, since it’s the one that would be shared in common amongst all of the hardware platforms. And since different CPUs/SoCs both have different levels of support for hardware encryption offload as well as completely different ways of implementing it, it seems much more likely for something to go “wrong” with a model-specific feature like that, especially if it’s only one model or a small handful of models that are impacted by the bug.
I’m not really sure how to explain how software-only IPsec encryption would be causing crashes and reboots only on hEX S…if true, what a bizarre bug…
I’m wondering if it’s a combination factor of hardware offloaded cypher with non hardware hash and vice versa?
I initially tried AES256 with SHA-512 and it just kept rebooting as soon as P2 came online. AES-GCM just didn’t work at all.
Hi,
Versions v7.18.2 and 7.19betaXX are broken for IPSEC in hexS.
Simple example:
LAN site A (SIP videophone) ↔ IPSEC ↔ LAN site B (video intercom)
- SIP calls → OK
- Video calls → NOK, the call doesn’t go through, the call never goes through to the remote end, and sending “larger packets” doesn’t seem to work.
Downgrade to v7.17.2 and everything stabilizes.
Also, watchdog reboots are a disaster for hexS… the manufacturer has little reliability…
The only thing that works is v7.20abXX provided by support, but it also restarts from time to time by watchdog
They’ve JUST noticed me it has been fixed in the latest (unofficial) routeros-7.20_ab381-arm64.npk
Well, we’ll see tonight
Maybe ditch IPSEC and setup Wireguard.
I am seeing better throughput with Wireguard then IPSEC, so a big bonus.
any update?
Still catches an issue
CLIENT
- Im just wiped the RB5009 system via Netinstall to 7.18.2
- loaded config from the course rsc
- deleted l2tp-client interface and ppp profile
- configured new l2tp-client interface and ppp profile
and it still logs me
sent control message to X.X.X.X:0 from X.X.X.X:1701
ZERO dest port is still used
SERVER
I have a firewall rule capturing input/tcp/1701 on the very top of the list.
And counters shows 0 bytes\packets, so there are no client connection attempts registered.
After trying a simple “telnet X.X.X.X 1701” from RB5009–>CHR - the counters shown non-zero
And im testing input/udp/1701 using “nc -vv -u X.X.X.X 1701” - again non-zero counters
downgraded RB5009 to 7.16.2
Logs are now shows the right DEST port
sent control message to X.X.X.X:1701 from X.X.X.X:1701
CLIENT RB5009@7.16.2
FW rule on
”log/output/udp/1701/dst=X.X.X.X”
successfully captures outgoing packets
SERVER CHR@7.18.2
FW rule on
”accept/input/udp/1701”
captures nothing o_O
But if Im testing the upper rule using
“nc -vv -u X.X.X.X 1701”
again non-zero counters
has no one sent anything to support are they confirming the bug at all?
Did, they didn’t give a censored
It happens not just on Hex, but RB5009UPr+S+ too. Enable EOIP tunnel (removed IPSEC password) and router has crashed, like loosing connection every 15 seconds, stabilized only after I have disabled a tunnel and rebooted it manually. FW 7.19.1
Anyone having issues with hex, please update to a version from this link, https://box.mikrotik.com/d/acd5b3b59c5a4d3281cc/
If you still having issues after that, please create supout rif file and send to us.
so it has to be 21.x?
has anyone tested this at all?