[Openswan Users] xl2tpd timeouts over openswan ipsec

Thu Aug 21 13:09:04 EDT 2008

Still time outs while connecting to xl2tpd.

This is even after turning compress=no and binding xl2tpd to the same
interface as the ipsec connection.

Any other thoughts?  People have emailed me directly after seeing my
post to say they have the same problem.

My tcpdump of the connection from a Windows XP SP2 box looks like this:

09:58:57.194953 IP 99-99-99-99-smc-wa.hfc.comcastbusiness.net.isakmp >
vpn.safety.net.isakmp: isakmp: phase 1 I ident
09:58:57.196932 IP vpn.safety.net.isakmp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.isakmp: isakmp: phase 1 R
ident
09:58:57.626851 IP 99-99-99-99-smc-wa.hfc.comcastbusiness.net.isakmp >
vpn.safety.net.isakmp: isakmp: phase 1 I ident
09:58:57.638462 IP vpn.safety.net.isakmp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.isakmp: isakmp: phase 1 R
ident
09:58:57.753991 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: NONESP-encap: isakmp: phase 1 I ident[E]
09:58:57.754345 IP vpn.safety.net.ipsec-nat-t >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t: NONESP-encap:
isakmp: phase 1 R ident[E]
09:58:57.782994 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: NONESP-encap: isakmp: phase 2/others I
oakley-quick[E]
09:58:57.785574 IP vpn.safety.net.ipsec-nat-t >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t: NONESP-encap:
isakmp: phase 2/others R oakley-quick[E]
09:58:57.811298 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: NONESP-encap: isakmp: phase 2/others I
oakley-quick[E]
09:58:57.816199 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: UDP-encap: ESP(spi=0xc6301078,seq=0x1),
length 140
09:58:58.809784 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: UDP-encap: ESP(spi=0xc6301078,seq=0x2),
length 140
09:58:59.816510 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
09:58:59.816749 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 ZLB
09:59:00.813893 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: UDP-encap: ESP(spi=0xc6301078,seq=0x3),
length 140
09:59:00.814432 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 ZLB
09:59:00.816521 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
09:59:01.816543 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
09:59:02.816569 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
09:59:03.816594 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
09:59:04.816718 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(34297)
*RESULT_CODE(1/0 Timeout)
09:59:04.819472 IP
99-99-99-99-smc-wa.hfc.comcastbusiness.net.ipsec-nat-t >
vpn.safety.net.ipsec-nat-t: UDP-encap: ESP(spi=0xc6301078,seq=0x4),
length 140
09:59:04.819994 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=0,Nr=1 ZLB
09:59:05.816749 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(34297)
*RESULT_CODE(1/0 Timeout)
09:59:06.816776 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(34297)
*RESULT_CODE(1/0 Timeout)
09:59:07.816804 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(34297)
*RESULT_CODE(1/0 Timeout)
09:59:08.816826 IP vpn.safety.net.l2tp >
99-99-99-99-smc-wa.hfc.comcastbusiness.net.l2tp:
l2tp:[TLS](7/0)Ns=1,Nr=1 *MSGTYPE(StopCCN) *ASSND_TUN_ID(34297)
*RESULT_CODE(1/0 Timeout)

On Wed, Aug 20, 2008 at 11:33 PM, Tuomo Soini <tis at foobar.fi> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rob Emanuele wrote:
> | Greetings,
> |
> | I'm running Fedora 9 with openswan and xl2tpd as a VPN server.  My
> | ipsec transport comes up fine but xt2tpd timesout.
> |
> | I see some questions about this online but no firm solutions.  The
> | only solution I've seen talks about setting leftnexthop which errors
> | out if set to %defaultroute.
>
> if you are using openswan from fedora 9 that's normal because fedora has
> patch which totally removes support for %defaultroute with netkey. But I
> can see some other problems with your config.
>
> | config setup
> |         # Debug-logging controls:  "none" for (almost) none, "all" for
> | lots.
> |         # klipsdebug=none
> |         #plutodebug="control parsing"
> |         # For Red Hat Enterprise Linux and Fedora, leave
> | protostack=netkey
> |         protostack=netkey
> |         nat_traversal=yes
> |
> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
> |         uniqueids=yes
> |
> | conn %default
> |      keyingtries=1
> |      compress=yes
> |      disablearrivalcheck=no
> |      authby=secret
> |      pfs=no
> |
>
> compress=yes doesn't work with windows... That makes it impossible to
> communicate with road warriors. Default setting, compress=no is only
> valid option here.
>
> | conn roadwarrior-l2tp
> |      pfs=no
> |      leftprotoport=17/0
> |      rightprotoport=17/1701
> |      also=roadwarrior
> |
> | conn macintosh-l2tp
> |      pfs=no
> |      leftprotoport=17/1701
> |      rightprotoport=17/%any
> |      also=roadwarrior
>
> I think this must be rightprotoport=17/0
>
> | conn roadwarrior
> |      left=66.66.66.66
> |      right=%any
> |      rightsubnet=vhost:%priv,%no
> |      auto=add
> |      type=transport
>
> vhost:%priv,%no doesn't seem to work for me. It's a bug, work-around is:
>
> conn roadwarriornat
>        left=66.66.66.66
>        right=%any
>        rightsubnet=vhost:%priv
>        auto=add
>        type=transport
>
> conn roadwarrior
>        left=66.66.66.66
>        right=%any
>        rightsubnet=vhost:%no
>        auto=add
>        type=transport
>
> | ===============xl2tpd=========
> |
> | [global]
> | debug tunnel = yes
> | debug network = yes
>
> listen-addr = 66.66.66.66 <- This might help if xl2tpd is using wrong ip
> ~ for answer.
>
> | [lns default]
> | ip range = 192.168.113.150-192.168.201.175
> | local ip = 192.168.113.253
> | require chap = yes
> | refuse pap = yes
> | require authentication = yes
> | name = LinuxVPNserver
> | ppp debug = yes
> | pppoptfile = /etc/ppp/options.xl2tpd
> | length bit = yes
> | _______________________________________________
> | Users at openswan.org
> | http://lists.openswan.org/mailman/listinfo/users
> | Building and Integrating Virtual Private Networks with Openswan:
> | http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
> - --
> Tuomo Soini <tis at foobar.fi>
> Foobar Linux services
> +358 40 5240030
> Foobar Oy <http://foobar.fi/>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFIrQxETlrZKzwul1ERAs4KAJ4/4ZCbISMpxM8cZkLafsCOHpsEtACgmPM7
> ZZaQ4W1b/6O3zAda7GCXMN8=
> =OtMm
> -----END PGP SIGNATURE-----
>