strongSwan

When strongSwan is the responder behind a NAT device in transport mode, the initiator address is returned in both NAT-OA addresses from strongSwan. The local address is not returned as it should according to RFC 3947. This causes interoperability issues with (at least) Solaris.

A fix could be something like this:

--- C:/Data/IPsec/strongswan-5.5.1/src/libcharon/sa/ikev1/tasks/quick_mode.c    Sat Oct 08 13:16:33 2016
+++ C:/Data/IPsec/ikev1-NAT-OA-correction/quick_mode.c    Fri Mar 03 10:47:27 2017
@@ -706,12 +706,18 @@
     host_t *src, *dst;
     payload_type_t nat_oa_payload_type;

-    src = message->get_source(message);
-    dst = message->get_destination(message);
-
-    src = this->initiator ? src : dst;
-    dst = this->initiator ? dst : src;
-
+    if (this->initiator)
+    {
+        src = message->get_source(message);
+        dst = message->get_destination(message);
+    }
+    else
+    {
+        src = message->get_destination(message);
+        /* When behind NAT the local address is to be returned. Should also work when not behind NAT. */
+        dst = this->ike_sa->get_my_host(this->ike_sa);
+    }
+    
     nat_oa_payload_type = get_nat_oa_payload_type(this->ike_sa);

     /* first NAT-OA is the initiator's address */

Assuming that this->ike_sa->get_my_host(this->ike_sa) returns the address of the interface sued in the IPsec connection on a host with multiple interfaces.

Solaris 10 refuses to connect as it should, but Windows 10 appears to connect as initiator in this configuration indicating that the Windows IPsec implementation does not validate TCP checksums as it should in this configuration.

References:
RFC 3947 5.2. Sending the Original Source and Destination Addresses
RFC 2.1. b) Intrinsic NAT Issues