IKE_SA_INIT packets are ignored when source port is not 500 and custom ipsec port is used

[freepaddler]

Hello,

I'm trying to setup strongswan behind NAT and with custom ipsec port

NAT rules:

public_udp 500 -> private_udp 501
public_udp 4500 -> private_udp 4501

stronswan acts as ike2 responder

The problem is when IKE_SA_INIT arrives from random port, then strongswan ignores it:

02[NET] received packet: from 1.1.1.1[56720] to 192.168.10.2[501] (604 bytes)
02[NET] waiting for data on sockets

and nothing happens

but when IKE_SA_INIT packet arrives from source port 500, then it is processed as expected:

02[NET] received packet: from 1.1.1.1[500] to 192.168.10.2[501] (604 bytes)
02[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
02[IKE] 1.1.1.1 is initiating an IKE_SA

.... etc and connection establishes as expected

stongswan.conf:

charon {
    port = 501
    port_nat_t = 4501
}

I also tried to build with --with-charon-udp-port=501 --with-charon-natt-port=4501 and gained the same result

If make 1-1 NAT rules (public_udp 500-> private_udp 500) and run charon on default ports, then it works as expected in both cases.

Could you please help me with any idea why does it happen and how to fix it.

Thanks in advance.

[Thermi]

Please provide complete debug logs (#196), the output of ipsec statusall, and your complete configuration.

[Thermi]

Hi, you need to connect to the NAT-T port. The reason for that is that the port to float up to after NAT detection is not explicitely negotiated, so if NAT was detected, the whole point of moving the ports would not be possible for the NAT-T port. The packet format between the IKE and the NAT-T port are slightly different. For NAT-T, there is a non-esp marker in the beginning for IKE packets, and for ESP packets inside the UDP packet, the SPI of the ESP packet is there instead.
TL;DR: Configure to start negotiating on NAT-T port.

[freepaddler]

Hi Thermi

the case is also for RW clients, where sometimes it is impossible to setup destination port

just to clarify - is that a strongswan design only? because according to https://tools.ietf.org/html/rfc5996#section-2.23

even though IKE packets MUST be sent to and from UDP port 500
or 4500, they MUST be accepted coming from any port and responses
MUST be sent to the port from whence they came.

i suspected that responder will reply to IKE_SA_INIT and according to difference between NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP initiator will send all further traffic via udp to 4500

[Thermi]

just to clarify - is that a strongswan design only? because according to https://tools.ietf.org/html/rfc5996#section-2.23

No. That is the IKE standard and because of the NON-ESP marker.

https://tools.ietf.org/html/rfc5996#section-3.1

When sent on UDP port 500, IKE messages begin immediately following
the UDP header. When sent on UDP port 4500, IKE messages have
prepended four octets of zero.

 The format of the IKE header is shown in Figure 4.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Initiator's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Responder's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As you can see, the requirement to prepend four octets of zero directly conflicts with the IKE header format, which starts with the IKE initiator SPI.

Section 2.23:

   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is a NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending ESP with UDP encapsulation is
   not required, but understanding received UDP-encapsulated ESP packets
   is required.  UDP encapsulation MUST NOT be done on port 500.  If
   Network Address Translation Traversal (NAT-T) is supported (that is,
   if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
   all devices MUST be able to receive and process both UDP-encapsulated
   ESP and non-UDP-encapsulated ESP packets at any time.  Either side
   can decide whether or not to use UDP encapsulation for ESP
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST use UDP encapsulation for ESP.

   o  To tunnel IKE packets over UDP port 4500, the IKE header has four
      octets of zero prepended and the result immediately follows the
      UDP header.  To tunnel ESP packets over UDP port 4500, the ESP
      header immediately follows the UDP header.  Since the first four
      octets of the ESP header contain the SPI, and the SPI cannot
      validly be zero, it is always possible to distinguish ESP and IKE
      messages.

the case is also for RW clients, where sometimes it is impossible to setup destination port

Then those RW clients by design can not support any setup where you can not use the default IKE ports. That is not a restriction posed by strongSwan but by your network.

i suspected that responder will reply to IKE_SA_INIT and according to difference between NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP initiator will send all further traffic via udp to 4500

No. The initiator is told to float up to UDP port 4500. The initiator is the one initiating the connection, so obviously the responder can be connected to by the initiator, but not necessarily the other way around. That's why that is designed that way.

Here's the code path for receiving packets that might or might not be IKE packets.

I hope this clears things up for you.

[freepaddler]

Hi Thermi,

thanks a lot for detailed answer. No questions left, it’s clear for me now.

[Thermi]

Great, then please close the discussion and/or mark the answer as accepted.

[freepaddler]

Made a small patch (for 5.9.2) to check not default IKEV2_UDP_PORT but charon socket.

May be this can be useful for someone.

--- src/libcharon/network/receiver.c_orig	2021-03-29 22:08:57.000000000 +0300
+++ src/libcharon/network/receiver.c	2021-03-29 23:35:21.000000000 +0300
@@ -457,9 +457,9 @@
 		return JOB_REQUEUE_DIRECT;
 	}
 
-	/* if neither source nor destination port is 500 we assume an IKE packet
-	 * with Non-ESP marker or an ESP packet */
-	if (dst->get_port(dst) != IKEV2_UDP_PORT &&
+	/* if source is not charon.port and destination port is not 500 we assume 
+	 * an IKE packet with Non-ESP marker or an ESP packet */
+	if (dst->get_port(dst) != charon->socket->get_port(charon->socket, FALSE) &&
 		src->get_port(src) != IKEV2_UDP_PORT)
 	{
 		if (memeq(data.ptr, marker.ptr, marker.len))
--- src/libcharon/network/sender.c_orig	2021-03-29 22:08:57.000000000 +0300
+++ src/libcharon/network/sender.c	2021-03-29 23:34:31.000000000 +0300
@@ -121,9 +121,10 @@
 		message->destroy(message);
 	}
 
-	/* if neither source nor destination port is 500 we add a Non-ESP marker */
+	/* if source port is not 500 and destination port is not charon.port we add
+	 * a Non-ESP marker */
 	if (dst->get_port(dst) != IKEV2_UDP_PORT &&
-		src->get_port(src) != IKEV2_UDP_PORT)
+		src->get_port(src) != charon->socket->get_port(charon->socket, FALSE))
 	{
 		chunk_t data, marker = chunk_from_chars(0x00, 0x00, 0x00, 0x00);
 
--- src/libcharon/encoding/message.c_orig	2021-03-29 22:08:57.000000000 +0300
+++ src/libcharon/encoding/message.c	2021-03-29 23:35:59.000000000 +0300
@@ -2008,7 +2008,7 @@
 	/* 8 (UDP header) */
 	REDUCE_FRAG_LEN(frag_len, 8);
 	if (dst->get_port(dst) != IKEV2_UDP_PORT &&
-		src->get_port(src) != IKEV2_UDP_PORT)
+		src->get_port(src) != charon->socket->get_port(charon->socket, FALSE))
 	{	/* reduce length due to non-ESP marker */
 		REDUCE_FRAG_LEN(frag_len, 4);
 	}