[Swan] ip address assignment

Paul Wouters paul at nohats.ca
Mon May 14 15:10:33 UTC 2018


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


More information about the Swan mailing list