[Swan] [PATCH, RFC] libreswan 3.17 incorrectly replying with dstport 500 during IKEv2 setup
Daniel J Blueman
daniel at quora.org
Sat Jun 11 10:09:10 UTC 2016
On 10 June 2016 at 10:19, Paul Wouters <paul at nohats.ca> 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 <daniel at quora.org>
Many thanks Paul and Antony!
Daniel J Blueman
More information about the Swan