On 10 June 2016 at 10:19, Paul Wouters <[email protected]> wrote: > 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;
This works great; you can add my: Tested-by: Daniel J Blueman <[email protected]> Many thanks Paul and Antony! Daniel -- Daniel J Blueman _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
