[SOLVED] IPsec troubleshooting

bem · January 7, 2017, 12:35am

Sorry if this is the wrong place to post. Something’s wrong with my configuration and I don’t know what.

I’m trying to create an ipsec tunnel between a RouterBoard and a CentOS box (running libreswan), the latter of which is behind a NAT.

The physical network is A ↔ B ↔ C ↔ D. A, C, and D are CentOS systems; B is a RouterBoard. I am trying to establish a tunnel so that ‘A’ can communicate with ‘D’. ‘C’ is configured to forward UDP ports 500 and 4500 to ‘D’.

Also, the RouterBoard has another IPsec tunnel (to a different remote network) already active and working correctly.

From what I can tell, the IKE negotation works correctly and an SA is established for each direction, but the RouterBoard then does not actually forward any packets.

When I run ‘ping A’ on D:

I see encrypted UDP packets (port 4500) being sent from C to B.
On B, there is an ‘input’ firewall rule to accept UDP packets from C to port 4500. I see the packet count increasing.
On B, there is a ‘forward’ firewall rule to accept ICMP packets to A. This packet count does not change.
No packets actually arrive at A.

When I run ‘ping D’ on A:

I see unencrypted ICMP packets being sent from A to B.
On B, there is a ‘forward’ firewall rule to accept ICMP packets from A. I see the packet count increasing.
On B, a “larval” SA appears in the list. (In addition to the two “mature” SAs that were already there.) After a minute or so, this disappears.
No packets arrive at C (or D), except for periodic “keep-alive” packets.

How can I figure out what is happening to outgoing packets? The RouterBoard’s firewall is accepting them, and presumably the IPsec policy I defined is being applied, but once that happens, the RouterBoard… doesn’t recognize that it already has an SA? Or doesn’t believe that the SA should apply to that packet? And decides it wants to create a new SA, but doesn’t actually send any IKE packets to the other end?

How can I figure out what is happening to incoming packets? The sender is encrypting them according to (what it believes is) a valid SA, and the RouterBoard’s firewall accepts the encrypted packets, but then… it doesn’t believe they’re encrypted correctly? Or doesn’t know what to do with them after decrypting them, so drops them on the floor? Or sends them out the wrong interface? How can I figure out what it’s doing?

bem · January 9, 2017, 8:54pm

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.