I found what was wrong. Two things:
-
I had mistyped the SA Src. Address in the IPsec policy. A simple mistake, but apparently one that doesn’t cause any problems until you actually try to send packets across the tunnel.
-
It seems that the version of RouterOS we’re using is subject to the “SHA-2 truncation bug” described in the ipsec.conf manual page:
sha2-truncbug
The default ESP hash truncation for sha2_256 is 128 bits. Some IPsec implementations (Linux before 2.6.33, some Cisco (2811?) routers) implement the draft version which stated 96 bits. If a draft implementation communicates with an RFC implementation, both ends will reject encrypted packets from each other.
This option enables using the draft 96 bits version to interop with those implementations. Currently the accepted values are > no> , (the default) signifying default RFC truncation of 128 bits, or > yes> , signifying the draft 96 bits truncation. Another workaround is to switch from sha2_256 to sha2_128 or sha2_512.
Apparently this was fixed in RouterOS version 6.34 (which I haven’t yet tested.) So in order to interoperate with older versions of RouterOS, it is necessary to set the option sha2-truncbug = yes in your ipsec.conf, but presumably not for current RouterOS.