Hi to all,

I have a problem with my ipsec tunnel between Mikrotik and Sonicwall.

The tunnel establishes a connection as soon as the lifetime 8h tunnel does not start automatically, I have to manually disable and enable it.

After establishing a connection it writes to me in the log these errors could it have to do with not establishing a connection after lifetime?

Where could be the problem?, I'm already desperate I have to manually renew the tunnel every 8 hours.

Thank you very much

The reply is ignored because it carries no contents - the log states that the decrypted packet has size of 0x12, which matches its last longword field, which it is the total length of the ESP part of the packet, including the preceding headers. Also the "next-payload" code (at offset 16) is 0.

It may be a decryption error at the Mikrotik end or the Sonicwall may indeed be sending an empty payload. At first glance it is tempting to say it is a decryption error because the difference in size between the encrypted version (0x60) and the decrypted one (0x12), 0x4e, is larger than the one for a succcessfully decrypted packet carrying the traffic selector, 0x44 (0x110 for the encrypted version and 0xcc for the decrypted one). But in fact this doesn't indicate anything because the payload is stuffed to 16-byte blocks before encryption.

So until you sort that out with Sonicwall and Mikrotik support, your only option is to schedule a script to check the active-peer state and disable/re-enable the peer once its uptime reaches 7h59m30s.

Thank you for the answer, however a new ipsec error pops up, identity identity not found for peer: ADDR4:

I am attaching the log and IPsec settings can you please check if everything is set correctly?

Internal network: 172.16.0.0/16
Remote network: 10.0.200.139

/ip ipsec mode-config
set [ find default=yes ] use-responder-dns=no
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 dpd-interval=disable-dpd enc-algorithm=aes-256 hash-algorithm=sha512 lifetime=8h nat-traversal=no prf-algorithm=sha512
add dh-group=modp2048 dpd-interval=disable-dpd enc-algorithm=aes-256 hash-algorithm=sha512 lifetime=8h name=ipodnik nat-traversal=no prf-algorithm=sha512
/ip ipsec peer
add address=46.234.101.177/32 exchange-mode=ike2 local-address=81.30.252.98 name=ipodnik-peer profile=ipodnik
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=8h pfs-group=modp2048
/ip ipsec identity
add my-id=address:81.30.252.98 peer=ipodnik-peer
/ip ipsec policy
add dst-address=10.0.200.139/32 level=unique peer=ipodnik-peer src-address=172.16.0.0/16 tunnel=yes
After disabling and enabling the peer tunnel always pops up.,

Thank you for any advice

Many things may be wrong, but what seems most likely to me is that when you disable and re-enable the peer, the Mikrotik acts as an initiator and the connection succeeds, whereas when the Sonicwall acts as an initiator during the IKE renewal, the Mikrotik acting as responder doesn't like the combination of CERTREQ coming from there and ID_I being an IP address when remote-id is set to auto.

So /ip ipsec identity set [find where peer=ipodnik-peer] remote-id=address:46.234.101.177 might help. To possibly see the result faster, maybe do not change the remote-id yet, and start from setting passive=yes on the peer at Mikrotik side, disable the peer, and re-enable it; if my assumption is correct, you should see the same error. If you do, change the remote-id as suggested above; if that helps, chances are high that the renewal will succeed as well, so you can set passive back to no and wait 8 hours for the final outcome.