[Openswan Users] libreswan 3.15 replying with dstport 500 during IKEv2 setup

[Daniel J Blueman]

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 [1]. Rewriting the port number [2]
fixes the behaviour, though shouldn't be expected?

Thanks,
  Daniel

-- [1]

find_host_connection me=195.119.250.13:500 him=175.156.179.109:1024
policy=RSASIG+IKEV2_ALLOW
find_host_pair: comparing 195.119.250.13:500 to 0.0.0.0:500
find_host_pair_conn: 195.119.250.13:500 175.156.179.109:1024 -> hp:none
find_next_host_connection policy=RSASIG+IKEV2_ALLOW
find_next_host_connection returns empty
find_host_connection me=195.119.250.13:500 him=%any:1024
policy=RSASIG+IKEV2_ALLOW
find_host_pair: comparing 195.119.250.13:500 to 0.0.0.0:500
find_host_pair_conn: 195.119.250.13:500 %any:1024 -> hp:tunnel
find_next_host_connection policy=RSASIG+IKEV2_ALLOW
found policy = RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_PROPOSE+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
(tunnel)
find_next_host_connection returns tunnel
find_host_pair: comparing 195.119.250.13:500 to 0.0.0.0:500
connect_to_host_pair: 195.119.250.13:500 175.156.179.109:500 -> hp:none
rw_instantiate() instantiated "tunnel"[1] 175.156.179.109 for 175.156.179.109
found connection: tunnel with policy RSASIG+IKEV2_ALLOW
find_host_pair: comparing 195.119.250.13:500 to 175.156.179.109:500
find_host_pair: comparing 195.119.250.13:500 to 0.0.0.0:500
find_host_pair_conn: 195.119.250.13:500 %any:1024 -> hp:tunnel

-- [2]

--- a/programs/pluto/connections.c
+++ b/programs/pluto/connections.c
@@ -2558,6 +2558,7 @@ stf_status ikev2_find_host_connection( struct
connection **cp,
                                                        !(d->policy &
POLICY_OPPORTUNISTIC)) {
                                                /* must be Road
Warrior: we have a winner */
                                                c = d;
+                                               c->spd.that.host_port
= his_port;
                                                break;
                                        }

On 1 June 2016 at 17:51, Daniel J Blueman <daniel at quora.org> wrote:
> Hi to all,
>
> Has anyone found a solution to libreswan replying to IKEv2 setup
> packets with port 500, rather than the source port [1]? This obviously
> cause them to be dropped by stateful firewalls.
>
> I'm 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 with cert auth.
>
> The some of port assignments look suspicious in the output of 'ipsec
> pluto --stderrlog --config /etc/ipsec.conf --nofork --debug-all', but
> the output without '--debug-all' looks good:
>
> Jun  1 19:52:33: "tunnel"[1] 66.96.193.199 #1: STATE_PARENT_R1:
> received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_256 integ=sha384_192
> prf=OAKLEY_SHA2_384 group=MODP1024}
>
> Let me know of any tips and thanks!
>   Daniel
>
> -- [1] tcpdump -i eth0 -nn udp
>
> 19:45:16.061582 IP 66.96.193.199.1024 > 195.159.250.13.500: isakmp:
> parent_sa ikev2_init[I]
> 19:45:16.071924 IP 195.159.250.13.500 > 66.96.193.199.500: isakmp:
> parent_sa ikev2_init[R]
>
> -- [2] /etc/ipsec.d/tunnel.conf
>
> conn tunnel
>         left=195.159.250.13
>         leftcert=box
>         leftid=@box.foo
>         leftsendcert=always
>         leftsubnet=0.0.0.0/0
>         leftrsasigkey=%cert
>         right=%any
>        rightaddresspool=192.168.66.10-192.168.66.199
>         rightca=%same
>         rightrsasigkey=%cert
>         ike=aes256-sha2_384;modp1024 # Windows 10
>         narrowing=yes
>         dpddelay=30
>         dpdtimeout=120
>         dpdaction=clear
>         auto=add
>         ikev2=insist
>         rekey=no
>         fragmentation=yes
-- 
Daniel J Blueman