Project

General

Profile

Bug #2268

Wrong NAT-AO address returned when strongSwan is responder in transport mode behind NAT

Added by Ole Fostad over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
ikev1
Target version:
Start date:
06.03.2017
Due date:
Estimated time:
Affected version:
5.5.1
Resolution:
Fixed

Description

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

Associated revisions

Revision d8f0d9c2 (diff)
Added by Tobias Brunner over 3 years ago

quick-mode: Correctly prepare NAT-OA payloads as responder

The initiator's address was sent back twice previously.

Fixes #2268.

History

#1 Updated by Tobias Brunner over 3 years ago

  • Category changed from libcharon to ikev1
  • Status changed from New to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.5.2
  • Resolution set to Fixed

Thanks for the report. The assignment of the addresses was, in fact, incorrect as responder (dst was assigned to src, which then was assigned to dst again). A fix has been pushed to master.

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.

Same on Linux and FreeBSD (see #2213-5), they simply ignore the checksums after IPsec.

Also available in: Atom PDF