Dead Peer Detection

[David Woodhouse]

On Thu, 2011-05-12 at 22:12 +0200, jonathan_jung at web.de wrote:
> Thanks for the help and sorry for the strange/bad english!

The English is perfectly sufficient, but please could you post plain
text email only, not HTML? I accepted the message after it was trapped
for moderation, but now I'm regretting it as I try to make sense of your
output :)


> Connected tun0 as 141.89.47.28, using SSL
> No work to do; sleeping for 20000 ms...
> DTLS handshake timed out
> DTLS handshake failed: 2
> Send CSTP Keepalive
> No work to do; sleeping for 10000 ms...
> Send CSTP DPD
> No work to do; sleeping for 15000 ms...
> Send CSTP DPD
> No work to do; sleeping for 15000 ms...
> Send CSTP DPD
> No work to do; sleeping for 15000 ms...
> CSTP Dead Peer Detection detected dead peer!

The 'dead peer detection' is just a simple ping/pong. We send a DPD
request to the server, and we expect it to reply so that we know we're
still connected.

Except we're *not* still connected. We never get the reply.

> Failed to reconnect to host wlanvpn.uni-potsdam.de
> sleep 10s, remaining timeout 300s

... and we don't even manage to reconnect.

Your tcpdump seems to start just before the dead peer message, and shows
that we keep sending SYN packets to the server to make a new connection,
but they never get a response.

> Nr. 2 - sbin/route -n before the dead peer detection happens:
> /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 172.16.3.251 172.16.3.254 255.255.255.255 UGH 0 0 0 wlan0
> 141.89.46.0 141.89.46.106 255.255.255.0 UG 0 0 0 tun0
> 172.16.0.0 0.0.0.0 255.255.252.0 U 0 0 0 wlan0
> 0.0.0.0 141.89.46.106 0.0.0.0 UG 0 0 0 tun0

Ick that's unreadable. I'll try undoing the HTML-damage, and it looks
like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.3.251    172.16.3.254    255.255.255.255 UGH   0      0        0 wlan0
141.89.46.0     141.89.46.106   255.255.255.0   UG    0      0        0 tun0
172.16.0.0      0.0.0.0         255.255.252.0   U     0      0        0 wlan0
0.0.0.0         141.89.46.106   0.0.0.0         UG    0      0        0 tun0

This looks suspicious.

Your local wireless network is 172.16.0.0/22, so every host from
172.16.0.0 through to 172.16.3.255 is directly on that network segment?

Your VPN server is 172.16.3.251, so shouldn't it be *directly* on the
same network as you? But you have a route to the VPN server *through*
the gateway at 172.16.3.254?

That might explain why your packets aren't reaching the server.

What does your routing table look like after you join the VPN, *before*
you try to connect?

We have special logic in the vpnc-script to preserve your route to the
VPN server, but route everything *else* through the VPN tunnel. I bet
that isn't very well-tested with a VPN server that is actually *on* your
local subnet, and that's why you end up with this strange routing.

If you just run '/sbin/route del 172.16.3.251' as soon as it's
connected, and before it times out, that should delete the rogue route
to the VPN server via that gateway, and let you route to the VPN server
normally. I suspect that'll fix it?

I'll try connecting to my own VPN server through a *proxy* on the local
network, which should trigger the same kind of routing situation for
vpnc-script to screw up, and see if I can reproduce and fix it properly.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation