[Swan] problem connect shrew vpn client version 3.29

[Paul Wouters]

On Thu, 27 Jun 2019, António Silva wrote:

> Sorry forget to add the log from the client:

First, fix all the visible errors in your configuration, eg:

Jun 27 13:30:12 cmhome addconn[23652]: duplicate key 'ikev2' in conn tunnel3-aggr while processing def tunnel3
Jun 27 13:30:12 cmhome addconn[23652]: duplicate key 'ikev2' in conn tunnel3 while processing def tunnel3
Jun 27 13:30:12 cmhome addconn[23652]: addconn, in config '/etc/ipsec.conf', ignoring: duplicate key 'ikev2' in conn tunnel3-aggr while processing def tunnel3
Jun 27 13:30:12 cmhome addconn[23652]: duplicate key 'ikev2' in conn tunnel3 while processing def tunnel3
Jun 27 13:30:12 cmhome _stackmanager[23656]: duplicate key 'ikev2' in conn tunnel3-aggr while processing def tunnel3
Jun 27 13:30:12 cmhome libipsecconf[23664]: duplicate key 'ikev2' in conn tunnel3-aggr while processing def tunnel3
Jun 27 13:30:12 cmhome _stackmanager[23656]: duplicate key 'ikev2' in conn tunnel3 while processing def tunnel3
Jun 27 13:30:12 cmhome libipsecconf[23664]: duplicate key 'ikev2' in conn tunnel3 while processing def tunnel3
Jun 27 13:30:12 cmhome _stackmanager[23656]: addconn, in config '/etc/ipsec.conf', ignoring: duplicate key 'ikev2' in conn tunnel3-aggr while processing def tunnel3

note also:

Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[1] 192.168.1.66 #1:
WARNING: connection tunnel3 PSK length of 4 bytes is too short for md5
PRF in FIPS mode (8 bytes required)

I really hope "test" is not your PSK, not even for testing :P

Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1: Peer ID is ID_FQDN: '@'

that seems a weird ID? blanc?

However, the IKE SA came up:

Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY
cipher=AES_CBC_256 integ=HMAC_MD5 group=MODP2048}

But it got deleted by the other endpoint before it could setup an IPsec
SA:

Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1:
received Delete SA payload: self-deleting ISAKMP State #1

So you should check the other end to see why it send a delete request.

> In the logs i do see libreswan sending xauth request:
> 
> Jun 27 13:30:35 cmhome pluto[23927]: | XAUTH: Sending XAUTH Login/Password Request

The above did not show any trace of XAUTH, so it seems various logs do
not match the same exchange attempt between client and server?

> Is there a change from previous version that could affect auth with xauth?

Yes, we continiously update the algorithms in the default proposal and
obsolete things, so perhaps you were using MD5 or 3DES or DH2 which are
no longer in the default proposal set, even for IKEv1.

> or is just that the shrew client is to old and i should stop using it?

That to probably. But it should still work.

> On 27/06/2019 13:36, António Silva wrote:
>       Hi,
>
>       In version 3.29 i cannot connect shrew vpn client and i don't get why, probably something with new
>       ike negotiation.
>
>       other clients (android, cisco client) are working ok.
>
>       the configuration (client and server) was working in previous versions:
>
>       ipsec.conf:
>
>       conn tunnel3
>           pfs=no
>           type=tunnel
>           auto=add
>           ikev2=no
>           phase2=esp
>           sha2-truncbug=yes
>           authby=secret
>           keyingtries=3
>           ikelifetime=1h
>           salifetime=1h
>           left=192.168.1.10
>           leftsubnet=0.0.0.0/0
>           leftid=192.168.1.10
>           leftupdown=/scripts/ipsec_monitor.php
>           right=%any
>           rightid=%any
>           rightaddresspool=192.168.168.80-192.168.168.80
>           rightupdown=/scripts/ipsec_monitor.php
>           dpddelay=30
>           dpdtimeout=60
>           dpdaction=hold
>           leftxauthserver=yes
>           rightxauthclient=yes
>           leftmodecfgserver=yes
>           rightmodecfgclient=yes
>           modecfgpull=yes
>           ike-frag=yes
>           ikev2=never
>           xauthby=pam

looks fine.

>
>       The output of the connection is:
>
>       Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1: STATE_MAIN_R3: sent MR3, ISAKMP
>       SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_MD5 group=MODP2048}
>
>       Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1: received Delete SA payload:
>       self-deleting ISAKMP State #1
>       Jun 27 13:30:35 cmhome pluto[23927]: "tunnel3"[2] 192.168.1.66 #1: deleting state (STATE_MAIN_R3)
>       aged 0.585s and sending notification
>       Jun 27 13:30:35 cmhome pluto[23927]: packet from 192.168.1.66:50591: deleting connection
>       "tunnel3"[2] 192.168.1.66 instance with peer 192.168.1.66 {isakmp=#0/ipsec=#0}
>
>       I guess that is something related to the new changes for IKE negotiation.
>
>       Full log can be found at : https://pastebin.com/D8aQNWHN

So yeah, find out why the other end send a delete.

Paul