On Wed, 9 May 2018, Thomas Stein wrote:
What does "ipsec whack --trafficstatus" show for the traffic counters?
rather ~ # ipsec whack --trafficstatus
006 #2: "my-vpn", username=myself, type=ESP, add_time=1525892039, inBytes=0,
outBytes=95061
Looks like you are sending and encrypting traffic fine, just not
receiving any back. So the problem is more likely to me on the other
end.
May 9 20:53:49 rather pluto[31225]: "my-vpn" #1: STATE_AGGR_I2: sent AI2,
ISAKMP SA established {auth=PRESHARED_KEY cipher=3des_cbc_192 integ=sha group=MODP1536}
3des-sha1 is pretty ancient and modp1536 is the lowest still allowed by
RFC's. So this is a pretty dated configuration.
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: DPD: received old or
duplicate R_U_THERE
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: DPD: received less than 3
duplicate R_U_THERE's - will reluctantly answer
We had some interop issues with implementations sending old/bad DPDs. It
seems triggered here. Likely because it is send before XAUTH completed.
So I think the remote end might be buggy/old.
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: STATE_XAUTH_I1: XAUTH client
- possibly awaiting CFG_set {auth=PRESHARED_KEY cipher=3des_cbc_192 integ=sha
group=MODP1536}
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: modecfg: Sending IP request
(MODECFG_I1)
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: Received IPv4 address:
xxx.xxx.xxx.193/32
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: Received DNS server
xxx.xxx.xxx.116
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: Received DNS server
xxx.xxx.xxx.117
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: Received subnet 0.0.0.0/0
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: Subnet 0.0.0.0/0 already has
an spd_route - ignoring
May 9 20:53:59 rather pluto[31225]: "my-vpn" #1: STATE_MAIN_I4: ISAKMP SA
established {auth=PRESHARED_KEY cipher=3des_cbc_192 integ=sha group=MODP1536}
May 9 20:53:59 rather pluto[31225]: "my-vpn" #2: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO
{using isakmp#1 msgid:f792899c proposal=AES_CBC_256-HMAC_SHA1_96-MODP1536
pfsgroup=MODP1536}
May 9 20:53:59 rather pluto[31225]: "my-vpn" #2: ignoring informational
payload IPSEC_RESPONDER_LIFETIME, msgid=f792899c, length=28
May 9 20:53:59 rather pluto[31225]: | ISAKMP Notification Payload
May 9 20:53:59 rather pluto[31225]: | 00 00 00 1c 00 00 00 01 03 04 60 00
May 9 20:53:59 rather pluto[31225]: "my-vpn" #2: up-client output: updating
resolvconf
May 9 20:53:59 rather pluto[31225]: "my-vpn" #2: up-client output: backup
resolv.conf exists, but current resolv.conf is not generated by Libreswan
May 9 20:53:59 rather pluto[31225]: "my-vpn" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established tunnel mode {ESP/NAT=>0x45356086 <0x8689505c xfrm=AES_CBC_256-HMAC_SHA1_96
NATOA=none NATD=xxx.xxx.xxx.5:4500 DPD=passive username=myself}
Connection came up but...
May 9 20:54:01 rather pluto[31225]: "my-vpn" #2: retransmitting in response to
duplicate packet; already STATE_QUICK_I2
May 9 20:54:05 rather pluto[31225]: "my-vpn" #2: retransmitting in response to
duplicate packet; already STATE_QUICK_I2
May 9 20:54:13 rather pluto[31225]: "my-vpn" #2: discarding duplicate packet
-- exhausted retransmission; already STATE_QUICK_I2
the other end seem to think it did not come up. So it tries again to get
a real reply from you. But they keep not liking our identical reply. so
really look on the other end what's in the logs there. There is
something they don't like.
May 9 20:54:24 rather pluto[31225]: "my-vpn" #1: received Delete SA payload:
self-deleting ISAKMP State #1
And 9 seconds later they give up and delete.
May 9 20:54:24 rather pluto[31225]: "my-vpn" #1: deleting state
(STATE_MAIN_I4) and sending notification
May 9 20:53:22 rather pluto[31225]: NSS DB directory: sql:/etc/ipsec.d
Looks like either you restarted libreswan here, or we crashed and
restarted. In it crashed, it would be good to get a backtrace of this
so we can look at it (but it won't resolve your problem)
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
