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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
