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

[Antony Antony]

Hi Daniel,
It is good that you reported this issue. The fix you send is changing a TEMPLATE connection, c->spd.that.host_port. I am not sure that is optimal. Also it should work for POLICY_OPPORTUNISTIC. It seems libreswan always respond to UDP port 500 (or the ikeport configured in pluto) and not to the sender's source port. In  testing the odds are very high NAT box never changed port 500:) However as I started testing OE with multiple clients I noticed the issue poping up intermittently.

Do you also see source port UDP port 4500 getting translated?

I have seen many cases where DPD/liveness send by the responder does not arrive at the initiator behind NAT... But that is another discussion.

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?

regards,
-antony

On Wed, Jun 08, 2016 at 08:56:12PM +0800, Daniel J Blueman wrote:
> On 8 Jun 2016 8:52 p.m., "Paul Wouters" <paul at nohats.ca> wrote:
> >
> > On Thu, 2 Jun 2016, Daniel J Blueman wrote:
> >
> >> Using the current libreswan release in the core CentOS 6 repo
> >> (libreswan-3.15-5.3) with a road-warrior configuration [1] with a
> >> Windows 10 client and cert auth, I'm seeing libreswan reply to the
> >> initial IKEv2 setup packets on port 500, rather than the correct
> >> source port, needed to pass through routers; we see:
> >>
> >> 19:45:16.061582 IP 66.96.193.199.1024 > 195.119.250.13.500: isakmp:
> >> parent_sa ikev2_init[I]
> >> 19:45:16.071924 IP 195.119.250.13.500 > 66.96.193.199.500: isakmp:
> >> parent_sa ikev2_init[R]
> >
> >
> > That should not happen. It is clearly a bug.
> >
> >
> >> This issue occurs on libreswan 3.17 also, so I traced back the
> >> incorrect remote port number to the connection lookup code, clearly
> >> the right section in the debug logs [2]. Rewriting the port number [3]
> >> fixes the behaviour.
> >
> >
> > If we are not switching connections, it should not have the wrong port.
> > But since this is IKE_INIT, I would not expect it to switch connections
> > at all.
> >
> > I'm looking into issue.
> 
> Thanks for taking a look!
> 
> I can test out any changes as and when.
> 
> Dan

> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan

-------------- next part --------------
commit 1fc3a0745dfd5b7a89f06a28e79b37d7b6d195f0
Author: Antony Antony <antony at phenome.org>
Date:   Wed Jun 8 17:20:54 2016 +0200

    pluto:  ikev2 NAT respond to sender's source port insted
    ikeport (500). ikeport is configurable

diff --git a/programs/pluto/ikev2.c b/programs/pluto/ikev2.c
index d347d0a..cc1a0cf 100644
--- a/programs/pluto/ikev2.c
+++ b/programs/pluto/ikev2.c
@@ -1523,6 +1523,14 @@ static void success_v2_state_transition(struct msg_digest *md)
 			nat_traversal_change_port_lookup(md, st);
 		}
 
+
+		if (nat_traversal_enabled && (
+				st->st_state == STATE_PARENT_R1 ||
+				st->st_state == STATE_PARENT_R2)) {
+			if  (md->sender_port > 0)
+				st->st_remoteport = md->sender_port;
+		}
+
 		DBG(DBG_CONTROL, {
 			    ipstr_buf b;
 			    DBG_log("sending V2 reply packet to %s:%u (from port %u)",