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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
