[Openswan Users] Unreliable VPN - SCCR problem?

Dom Latter openswan-users at latter.org
Fri May 3 21:49:01 UTC 2013


Hi again,

I'll repeat my introduction from last time:

I have installed ipsec and xl2tpd on an openwrt [1] server [2].

We are currently focused on getting iOS devices connected so
that they can connect to the internet through the VPN.  (I.e.
all traffic is routed).

The server is NATed behind a domestic router; in general the
client device is also NATed.

We are testing with an iPad.

After a boot or soft boot (i.e. restarting ipsec and xl2tpd)
on the server we are able to connect and reconnect a variable
number of times (between two and ten, put one way, or for an
hour or two, or even up to 24 or so, put another way), before
it starts failing, after which it will always fail.

Any help / ideas with the following will be much appreciated!

It seems to be at the point of Start-Control-Connection-Request.

I've got logging turned up to the max (AFAICT) and I have this
on a successful connection:

network_thread: recv packet from 94.172.30.12, size = 74, tunnel = 0, 
call = 0 ref=0 refhim=0

get_call: allocating new tunnel for host 94.172.30.12, port 53229.

handle_avps: handling avp's for tunnel 61075, call 792
message_type_avp: message type 1 (Start-Control-Connection-Request)

protocol_version_avp: peer is using version 1, revision 0.
framing_caps_avp: supported peer frames: async sync

hostname_avp: peer reports hostname 'Ipad-3'
assigned_tunnel_avp: using peer's tunnel 3
receive_window_size_avp: peer wants RWS of 4.  Will use flow control.

control_finish: message type is Start-Control-Connection-Request(1). 
Tunnel is 3, call is 0.

control_finish: Peer requested tunnel 3 twice, ignoring second one.
build_fdset: closing down tunnel 61075

network_thread: recv packet from 94.172.30.12, size = 20, tunnel = 
48954, call = 0 ref=0 refhim=0
handle_avps: handling avp's for tunnel 48954, call 57785


On a failed connection it's the same up until the last line,
at which we get:

network_thread: recv packet from 94.172.30.132, size = 74, tunnel = 0, 
call = 0 ref=0 refhim=0

which would appear (?) to be the iPad issuing another SCCR rather than
moving on to the next stage.  NB the "size = 74" rather than "size =
20".


Versions:
openwrt: 12.09 (final release, it's out of beta and release candidate)
ip - 3.3.0-1
ipsec-tools - 0.8.0-2
iptables - 1.4.10-4
iptables-mod-ipsec - 1.4.10-4
kmod-crypto-* - 3.3.8-1
kmod-ipsec - 3.3.8-1
xl2tpd - 1.3.1-1


Configuration info: NB that "ipsec auto --status" reports:
" Either virtual_private= is not specified, or there is a syntax
  error in that line. 'left/rightsubnet=vhost:%priv' will not work!
  Disallowed subnets in virtual_private= is empty. If you have
  private address space in internal use, it should be excluded!"

but I figure that's a problem I can come back to later.
Although I would appreciate advice here. Given that the
remote device (iPad) can connect from anywhere, I cannot
predict what sort of network it will be on.

# /etc/ipsec.conf - IPsec configuration file
version	2.0
# basic config borrwed from AWS setup
config setup
         nat_traversal=yes
         oe=off
         protostack=netkey
         nhelpers=0
         interfaces=%defaultroute
conn L2TP-PSK
         authby=secret
         pfs=no
         compress=no
         rekey=no
         keyingtries=3
         type=tunnel
         left=%defaultroute
	leftnexthop=%defaultroute
         leftprotoport=17/1701
         right=%any
	rightsubnet=vhost:%no,%priv
         # rightprotoport=17/%any
         rightprotoport=17/0
         auto=add
	# DL : from AWS setup
         # Apple iOS doesn't send delete notify so we need dead peer
         # detection to detect vanishing clients
         dpddelay=10
         dpdtimeout=10
         dpdaction=clear


xl2tpd.conf:

	[global]
	port = 1701
	auth file = /etc/xl2tpd/xl2tp-secrets
	access control = no
	; DL: removed ipsec saref = yes;
	; DL: trying listen-addr
	listen-addr = 192.168.1.100
	debug network = yes
	debug tunnel = yes
	debug avp = yes
	debug packet = yes
	debug state = yes

	[lns default]
	; DL: I've tried exclusive = no
	exclusive = yes
	ip range = 192.168.1.202-192.168.1.220
	local ip = 192.168.1.200
	;hidden bit = no
	length bit = yes
	name = VPNServer
	ppp debug = yes
	require authentication = yes
	;unix authentication = no
	refuse chap = no
	refuse pap = yes
	pppoptfile = /etc/ppp/options.xl2tpd

/etc/ppp/options.xl2tpd

	#DL: copied from amazon AWS setup
	ipcp-accept-local
	ipcp-accept-remote
	ms-dns 192.168.1.1
	noccp
	auth
	crtscts
	idle 1800
	mtu 1280
	mru 1280
	defaultroute
	#debug
	lock
	proxyarp
	connect-delay 5000





[1] https://openwrt.org/
[2] TPLink domestic router; mips chip, 32MB RAM.


More information about the Users mailing list