[Swan] [PATCH, RFC] libreswan 3.17 incorrectly replying with dstport 500 during IKEv2 setup

[Paul Wouters]

On Thu, 9 Jun 2016, Antony Antony wrote:

> Coincidently I have been looking into the same in the past week.
> However I am not sure what the behavior should be if the ikeport is configured by local Admin. One could argue when responding to an initiator behind NAT, the responder  should respond to the source port. However, there may be cases where local policy don't want to respond anything but 500 or the configured ikeport.
>
> At the moment this patch only works for IKEv2.  I want to test liveness/dpd next.
> Would you like to try it?

Your patch does fix the problem, but by working around the fact that if
the st_remoteport is 0, you pull the port from the md. But at that point,
the port should never be 0 but contain the real port used. I think the
proper fix is to do the same as the IKEv1 code, upon calling new_state(),
it should copy the md information such as st_remoteport in the state. So
I would propose this patch:

diff --git a/programs/pluto/ikev2_parent.c b/programs/pluto/ikev2_parent.c
index 0a320a7..e815b6a 100644
--- a/programs/pluto/ikev2_parent.c
+++ b/programs/pluto/ikev2_parent.c
@@ -973,6 +973,13 @@ stf_status ikev2parent_inI1outR1(struct msg_digest *md)
  		st->st_msgid_lastack = v2_INVALID_MSGID;
  		st->st_msgid_nextuse = 0;

+		st->st_remoteaddr = md->sender;
+		st->st_remoteport = md->sender_port;
+		st->st_localaddr = md->iface->ip_addr;
+		st->st_localport = md->iface->port;
+		st->st_interface = md->iface;
+
+
  		if (got_no_tfc)
  			st->st_seen_no_tfc = TRUE;


Paul