Hello,

I hope I'm in the right section; I couldn't find a more suitable one.

At one location, there is an hEX S / RB760iGS set up to establish an IPsec connection with the central office (for RDP access to the location).
Access to the hEX S from the central office (via Winbox) also works.

After upgrading from 7.17.2 to 7.18 (also tested with 7.18.2), the IPsec tunnels still establish, but access is no longer working.

Access to Winbox on the MikroTik via IPsec:
Windows Client (10.67.23.66) > MikroTik (10.75.31.2)

Is there an explanation for this, or is it a bug?

Here is the configuration:


# 2025-03-12 15:43:45 by RouterOS 7.17.2
# software id = 0H5E-J9HA
#
# model = RB750Gr3
# serial number = HEX09CQREZS
/interface bridge
add name=bridge1
/ip ipsec profile
add dh-group=ecp521 dpd-interval=30s dpd-maximum-failures=5 enc-algorithm=\
aes-256 hash-algorithm=sha512 lifetime=18h name=profile.GIGG \
proposal-check=exact
add dh-group=ecp521 dpd-interval=30s dpd-maximum-failures=5 enc-algorithm=\
aes-256 hash-algorithm=sha512 lifetime=18h name=profile.ALGM \
proposal-check=exact
add dh-group=ecp521 dpd-interval=30s dpd-maximum-failures=5 enc-algorithm=\
aes-256 hash-algorithm=sha512 lifetime=18h name=profile.ALGV \
proposal-check=exact
/ip ipsec peer
add address=212.23.xx/32 exchange-mode=ike2 name=peer.GIGG profile=\
profile.GIGG
add address=80.151.xx/32 exchange-mode=ike2 name=peer.ALGV profile=\
profile.ALGV
add address=80.147.xx/32 exchange-mode=ike2 name=peer.ALGM profile=\
profile.ALGM
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add auth-algorithms="" enc-algorithms=aes-128-gcm lifetime=8h name=\
proposal.GIGG pfs-group=ecp256
add auth-algorithms="" enc-algorithms=aes-128-gcm lifetime=8h name=\
proposal.ALGM pfs-group=ecp256
add auth-algorithms="" enc-algorithms=aes-128-gcm lifetime=8h name=\
proposal.ALGV pfs-group=ecp256
/ip pool
add name=pool1 ranges=10.75.31.11-10.75.31.19
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ipv6 settings
set disable-ipv6=yes
/ip address
add address=10.0.1.1/24 interface=ether5 network=10.0.1.0
add address=10.75.31.2/24 interface=ether5 network=10.75.31.0
add address=192.168.0.53/24 interface=bridge1 network=192.168.0.0
/ip dhcp-client
add disabled=yes interface=bridge1
/ip dns
set servers=192.168.0.234
/ip firewall filter
add action=accept chain=forward comment=\
"accept established,related, untracked" connection-state=\
established,related,untracked disabled=yes
add action=accept chain=input comment="accept established,related,untracked" \
connection-state=established,related,untracked disabled=yes
add action=accept chain=output comment="accept established,related,untracked" \
connection-state=established,related,untracked disabled=yes
add action=accept chain=input disabled=yes log=yes
add action=accept chain=output disabled=yes log=yes
add action=accept chain=forward disabled=yes log=yes
add action=accept chain=input comment="accept established,related,untracked" \
connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid \
log=yes log-prefix="drop invalid"
add action=accept chain=input comment="accept ICMP" log=yes log-prefix=\
"accept ICMP" protocol=icmp
add action=fasttrack-connection chain=forward comment=fasttrack \
connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment=\
"accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid \
log-prefix="drop invalid"
add action=accept chain=input comment="WinBox Port5" dst-port=8291 \
in-interface=ether5 log=yes log-prefix="WinBox Port5" protocol=tcp
add action=accept chain=input comment="WinBox IPsec ALGM" dst-port=8291 \
ipsec-policy=in,ipsec log=yes log-prefix="WinBox IPsec ALGM" protocol=tcp \
src-address=10.66.0.0/24
add action=accept chain=input comment="WinBox IPsec ALGV" dst-port=8291 \
ipsec-policy=in,ipsec log=yes log-prefix="WinBox IPsec ALGV" protocol=tcp \
src-address=10.67.23.0/24
add action=accept chain=input comment="WinBox IPsec GIGG" dst-port=8291 \
ipsec-policy=in,ipsec log=yes log-prefix="WinBox IPsec GIGG" protocol=tcp \
src-address=192.168.91.0/24
add action=accept chain=input comment="WinBox LAN" dst-port=8291 \
in-interface=bridge1 log=yes log-prefix="WinBox LAN" protocol=tcp \
src-address=192.168.0.0/24
add action=accept chain=input comment="WinBox All" disabled=yes dst-port=8291 \
log=yes log-prefix="WinBox All" protocol=tcp
add action=accept chain=forward comment="accept ICMP" protocol=icmp
add action=accept chain=forward comment="SMB Out" dst-address=192.168.91.205 \
dst-port=445 log=yes log-prefix="SMB Out" protocol=tcp src-address=\
192.168.0.0/24
add action=accept chain=forward comment="RDP TCP In" dst-address=\
192.168.0.0/24 dst-port=3389 ipsec-policy=in,ipsec log=yes log-prefix=\
"RDP TCP In" protocol=tcp
add action=accept chain=forward comment="RDP UDP In" dst-address=\
192.168.0.0/24 dst-port=3389 ipsec-policy=in,ipsec log=yes log-prefix=\
"RDP UDP In" protocol=udp
add action=accept chain=forward comment="IPSec Policy In" disabled=yes \
ipsec-policy=in,ipsec log=yes log-prefix="IPSec Policy In"
add action=accept chain=forward comment="IPSec Policy Out" disabled=yes \
ipsec-policy=out,ipsec log=yes log-prefix="IPSec Policy Out"
add action=drop chain=input
add action=drop chain=forward
/ip firewall nat
add action=netmap chain=dstnat dst-address=10.75.0.0/24 src-address=\
192.168.91.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=192.168.91.0/24 src-address=\
192.168.0.0/24 to-addresses=10.75.0.0/24
add action=netmap chain=dstnat dst-address=10.75.0.0/24 src-address=\
10.66.0.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=10.66.0.0/24 src-address=\
192.168.0.0/24 to-addresses=10.75.0.0/24
add action=netmap chain=dstnat dst-address=10.75.0.0/24 src-address=\
10.79.28.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=10.79.28.0/24 src-address=\
192.168.0.0/24 to-addresses=10.75.0.0/24
add action=netmap chain=dstnat dst-address=10.75.0.0/24 log-prefix=xxx \
src-address=10.70.28.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=10.70.28.0/24 log-prefix=yyy \
src-address=192.168.0.0/24 to-addresses=10.75.0.0/24
add action=netmap chain=dstnat dst-address=10.75.0.0/24 src-address=\
10.70.31.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=10.70.31.0/24 src-address=\
192.168.0.0/24 to-addresses=10.75.0.0/24
add action=netmap chain=dstnat dst-address=10.75.0.0/24 log=yes log-prefix=\
test src-address=10.67.23.0/24 to-addresses=192.168.0.0/24
add action=netmap chain=srcnat dst-address=10.67.23.0/24 src-address=\
192.168.0.0/24 to-addresses=10.75.0.0/24
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip ipsec identity
add my-id=address:10.75.31.2 peer=peer.GIGG
add my-id=address:10.75.31.2 peer=peer.ALGM
add my-id=address:10.75.31.2 peer=peer.ALGV
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.91.0/24 level=unique peer=peer.GIGG proposal=\
proposal.GIGG src-address=10.75.0.0/24 tunnel=yes
add dst-address=10.79.28.0/24 level=unique peer=peer.GIGG proposal=\
proposal.GIGG src-address=10.75.0.0/24 tunnel=yes
add dst-address=10.66.0.0/24 level=unique peer=peer.ALGM proposal=\
proposal.ALGM src-address=10.75.0.0/24 tunnel=yes
add dst-address=192.168.91.0/24 level=unique peer=peer.GIGG proposal=\
proposal.GIGG src-address=10.75.31.0/24 tunnel=yes
add dst-address=10.66.0.0/24 level=unique peer=peer.ALGM proposal=\
proposal.ALGM src-address=10.75.31.0/24 tunnel=yes
add dst-address=10.70.31.0/24 level=unique peer=peer.ALGV proposal=\
proposal.ALGV src-address=10.75.0.0/24 tunnel=yes
add dst-address=10.70.31.0/24 level=unique peer=peer.ALGV proposal=\
proposal.ALGV src-address=10.75.31.0/24 tunnel=yes
add dst-address=10.67.23.0/24 level=unique peer=peer.ALGV proposal=\
proposal.ALGV src-address=10.75.31.0/24 tunnel=yes
add dst-address=10.67.23.0/24 level=unique peer=peer.ALGV proposal=\
proposal.ALGV src-address=10.75.0.0/24 tunnel=yes
add dst-address=10.70.28.0/24 peer=peer.ALGV proposal=proposal.ALGV \
src-address=10.75.0.0/24 tunnel=yes
/ip route
add disabled=no distance=3 dst-address=0.0.0.0/0 gateway=192.168.0.254 \
routing-table=main scope=30 suppress-hw-offload=no target-scope=10 \
vrf-interface=bridge1
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Berlin
/system note
set note=WUSM show-at-cli-login=yes
/system ntp client
set enabled=yes
/system ntp client servers
add address=pool.ntp.org

Sorry not an ipsec guru, but to be clear, the purpose of ipsec is so that a user at one router, on one device can use the RDP app/protocol through the ipsec tunnel to reach a device on the other router??
That sounds reasonable!

What does not sound right is using winbox over the internet. That would mean you open up a public IP to be able to access your winbox at the other end.
Public IPs are easy to spoof and access over the internet should ONLY be done via VPN. winbox is great once inside the router.

I'm not getting into the OP's issue, but IPsec is a VPN and using WinBox over IPsec............

Very true, if he is indeed doing winbox over the IPSEC, that is great, if not then its a concern. Since it was noted on a separate sentence without mention of ipsec, wanted to be sure ( there was no connecting words between the two sentences to give me a warm and fuzzy that ipsec was being used )!!

Hi,

no, Winbox is not on the Internet, only on IPsec.
It's just - it worked with 7.17.2 - it does not work with 7.18/7.18.2

In fact, it's just easy to test with Winbox - Finally - also the RDP-Access does not work with 7.18.x anymore...
After Downgrading to 7.17.2 - everything works fine again!

Thanks!

Most weird, perhaps an IPSEC variable use has changed slightly ???

The exact same problem here!
(Weird that a few services on different ports are working, but others not!)

Thank you very much, that makes me feel less alone
Even when I enable logging for firewall rules and NAT rules, nothing really seems to be coming through the tunnel (or at least what should be coming through). Nothing is being displayed.

Have you had the time to reset the device and start rebuilding the connections step by step to see if it works then (or at what point it stops working)?

As it is right now, it seems to me that the tunnels are being established, but nothing is going through.

Stefan

Which Services (Ports) DO work for you over IPSec?

Which Services (Ports) DO work for you over IPSec?

It is important to clear the directions in my writings, so my home is the server, the remote location is the client.
I downgraded to 7.17.2 on both sides.
- MSTSC (remote desktop) working from server's simple network to remote networks, any of the subnets..
- I can connect to remote mikrotik vpn client, but after a few secs, winbox ffreezes
- and that's all. None of any web services ports are working

So it is still not okay.
I have no time to rebuild all the configurations from zero, but it could be intresting, maybe. ....

Oh, I see. Yes, I also downgraded to 7.17.2.
I understood that for you, some connections were still working over IPSec even with version 7.18.

At the moment, I neither have the resources to go through everything step by step from a default config. But I will test the latest beta version when I get the chance.

Best regards,
Stefan

Hello, I am reporting a similar issue with 7.18.2.
l2tp/ipsec tunnel between hex S (server) and hap ax2 (client). Both were on 7.13 and everything was fine. After upgrading hex S to 7.18.2 the tunnel gets established but traffic does not pass between network. What's more, some of the traffic goes through and some doesn't - icmp (ping), ssh session goes thorough but http to server doesn't. Not tested too much so far but suspect some issues with mtu/fragmentation. Anyway, there is something wrong with this release - Mikrotik, please.

I am also seeing a issue with ipsec on hexs to hap ac3, winbox did not work, was blank, and router rebooted 3 times on its own with a kernel failure, once with a watchdog reboot.

also went back to 7.17.2, thank god I didn't do the remote side first.

Same here, downgrading helped.

Hi,

just to let you know, 7.19beta6 does not work, either.
I have a project for setting up a new one, I'll tell how far I come before I have to downgrade.

Stefan

Hi,

Unfortunately, I have to report that it's still not working even after a fresh setup. I completely reset a hEX S / RB760iGS (7.18.2) and then applied the following settings. After that, not even a ping from 192.168.91.205 (over ipsec) was possible.

The solution – downgrade to version 7.12.2 – everything works again.

/ip address add address=10.84.31.3/24 interface=ether5
/ip pool add name=pool1 ranges=10.84.31.11-10.84.31.99
/ip dhcp-server network add address=10.84.31.0/24 netmask=24 dns-none=yes
/ip dhcp-server add name=server1 interface=ether5 address-pool=pool1 disabled=no
/interface ethernet poe set poe-out=off ether5

/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=ether1
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4

/ip dhcp-client add interface=bridge1 use-peer-dns=yes use-peer-ntp=yes add-default-route=yes disabled=no

/system clock set time-zone-autodetect=no time-zone-name=Europe/Berlin
/system ntp client set enabled=yes mode=unicast servers=pool.ntp.org vrf=main

/ip ipsec profile add name=profile.GIGG dh-group=ecp521 dpd-interval=30s dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha512 lifetime=18h nat-traversal=yes proposal-check=exact
/ip ipsec peer add name=peer.GIGG disabled=yes exchange-mode=ike2 profile=profile.GIGG send-initial-contact=yes address=212.23.x.x
/ip ipsec identity add auth-method=pre-shared-key disabled=no generate-policy=no my-id=address:10.84.31.3 peer=peer.GIGG secret="PSK"
/ip ipsec proposal add auth-algorithms="" disabled=no enc-algorithms=aes-128-gcm lifetime=8h name=proposal.GIGG pfs-group=ecp256

/ip ipsec policy add action=encrypt disabled=no dst-address=192.168.91.0/24 dst-port=any ipsec-protocols=esp level=unique peer=peer.GIGG proposal=proposal.GIGG protocol=all src-address=10.84.0.0/24 src-port=any template=no tunnel=yes
/ip ipsec policy add action=encrypt disabled=no dst-address=192.168.91.0/24 dst-port=any ipsec-protocols=esp level=unique peer=peer.GIGG proposal=proposal.GIGG protocol=all src-address=10.84.31.0/24 src-port=any template=no tunnel=yes

/ip firewall nat add action=netmap chain=srcnat dst-address=192.168.91.0/24 src-address=192.168.100.0/24 to-addresses=10.84.0.0/24
/ip firewall nat add action=netmap chain=dstnat dst-address=10.84.0.0/24 src-address=192.168.91.0/24 to-addresses=192.168.100.0/24

/ip firewall nat add action=masquerade chain=srcnat dst-address=192.168.100.0/24 src-address=192.168.91.0/24

/system logging add topics=ipsec,!debug action=memory disabled=yes



Stefan

I have totally the same.
I have two MT connected via L2TP over IPSEC.
MT1 -> MT2
Connecting from MT1 network to MT2 via routed IPSEC (ping is working) - there is timeout on Winbox.

But if I open VPN directly from my computer to MT2, then I'm using an IP from pool created on MT2 and I'm able to connect via Winbox.

Tested on 7.18.2 and 7.19beta6

I checked config 5 times. It's good to see that I'm not alone

Just tried with an RBwAPGR-5HacD2HnD / 7.18.2
Same Config as above.

Ping and Winbox over IPSec works instantly - no Downgrade needed with that device.
Seems to be an issue with that hEX S...

Stefan

Same here. We using a CCR2004-16G-2S+. Issues with IPsec after tunnel stablished a Site to Site IPSec we have issues for connection on SQL Servers, jdbc drivers over Tomcat. A bloodymess with 7.18.2 version. The solution was to rollback to previous version was installed 7.15 i belive. Nothing was changed in configurations only the upgrade. Happy to see im not alone. Any advice or we stand waiting a Mikrotik statement?

A behavior. We have see on [Statistics] button over 7.18.2 a lot of [in state-protocol-error / no-state-errors] and [out state-mode-error / no-state-errors] couting. After rollback to 7.15 statistics still empty of errors.

I have no idea what one could change to make the communication over IPsec work again (in >= 7.18). I tried it with the absolute minimum configuration... - nos success...

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.

Just tried with an RBwAPGR-5HacD2HnD / 7.18.2
Same Config as above.

Ping and Winbox over IPSec works instantly - no Downgrade needed with that device.
Seems to be an issue with that hEX S...

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

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) 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 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

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.

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