[Swan] problem connect shrew vpn client version 3.29

Fri Jun 28 10:04:51 UTC 2019

Hi Paul,

Thanks for the reply, yes the psk is "test" :S ... it is a virtual 
machine not connect to internet...

Solved the configuration errors.

After looking into the shrew errors, i found out that the tunnel was  
closed because misconfigure IDs:

19/06/28 11:54:03 !! : phase1 id type mismatch ( received ipv4-host but 
expected fqdn )
19/06/28 11:54:03 ii : sending peer DELETE message

Problem solved by adjusting to the right configuration. Also force a 
"local ID" in shrew client so it doesn't send an empty one.

Sorry for the noise.

On 27/06/2019 17:32, Paul Wouters wrote:
> 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

-- 
Saludos / Regards / Cumprimentos
António Silva