[Openswan Users] Vista l2tp

[Toby Chamberlain]

Hi,

I have fixed this problem, and just in case someone is having the same 
problem, I fixed it like this:

listen-addr = <Public IP>
(in the [global] section of xl2tpd.conf)

tcpdump showed that xl2tpd was sending the l2tp packets out unencrypted and 
with ports 1024->1701 instead of the expected 1701->1701. Further 
investigation discovered that xl2tpd was using the internal 172.16.x.x 
interface instead of the public IP that the IPSec tunnel was set up on. The 
firewall was then NATting them to the public IP with the different source 
port. OpenSWAN (rightly) didn't consider them part of the IPSec tunnel and 
so they were being sent in the clear...  the SCCRP message was either never 
getting to the other end, or getting there and being rejected, causing the 
remote end to continually retry and the server end to eventually timeout.

Setting listen-addr forced xl2tpd to bind to the public IP and everything is 
working now.

Toby


--------------------------------------------------
From: "Toby Chamberlain" <toby at webtechservices.com.au>
Sent: Saturday, August 09, 2008 9:44 PM
To: <users at openswan.org>
Subject: [Openswan Users] Vista l2tp

> Hi,
>
> I have a NATted Vista client that I'm trying to set up with Openswan. I 
> have
> successfully setup a number of XP boxes but I can't get this Vista to 
> work.
> I first tried my preferred straight IPSEC connection, but Vista won't 
> allow
> IPSEC tunnels behind NAT, so I've switched to setting up an L2TPD which
> succeeds with the initial IKE and IPSEC SA's but then I see this in the
> syslog:
>
> Jul 30 07:42:20 mitchell xl2tpd[16815]: network_thread: recv packet from
> 59.167.53.166, size = 100, tunnel = 0, call = 0 ref=0 refhim=0
> Jul 30 07:42:20 mitchell xl2tpd[16815]: get_call: allocating new tunnel 
> for
> host 59.167.53.166, port 1701.
> Jul 30 07:42:20 mitchell xl2tpd[16815]: handle_avps: handling avp's for
> tunnel 41665, call 61340
> Jul 30 07:42:20 mitchell xl2tpd[16815]: message_type_avp: message type 1
> (Start-Control-Connection-Request)
> Jul 30 07:42:20 mitchell xl2tpd[16815]: protocol_version_avp: peer is 
> using
> version 1, revision 0.
> Jul 30 07:42:20 mitchell xl2tpd[16815]: framing_caps_avp: supported peer
> frames: sync
> Jul 30 07:42:20 mitchell xl2tpd[16815]: bearer_caps_avp: supported peer
> bearers:
> Jul 30 07:42:20 mitchell xl2tpd[16815]: firmware_rev_avp: peer reports
> firmware version 1536 (0x0600)
> Jul 30 07:42:20 mitchell xl2tpd[16815]: hostname_avp: peer reports 
> hostname
> 'Mui-XPS'
> Jul 30 07:42:20 mitchell xl2tpd[16815]: vendor_avp: peer reports vendor
> 'Microsoft'
> Jul 30 07:42:20 mitchell xl2tpd[16815]: assigned_tunnel_avp: using peer's
> tunnel 1
> Jul 30 07:42:20 mitchell xl2tpd[16815]: receive_window_size_avp: peer 
> wants
> RWS of 8.  Will use flow control.
> Jul 30 07:42:20 mitchell xl2tpd[16815]: control_finish: message type is
> Start-Control-Connection-Request(1).  Tunnel is 1, call is 0.
> Jul 30 07:42:20 mitchell xl2tpd[16815]: control_finish: sending SCCRP
> Jul 30 07:42:22 mitchell xl2tpd[16815]: network_thread: recv packet from
> 59.167.53.166, size = 100, tunnel = 0, call = 0 ref=0 refhim=0
> Jul 30 07:42:22 mitchell xl2tpd[16815]: get_call: allocating new tunnel 
> for
> host 59.167.53.166, port 1701.
> Jul 30 07:42:22 mitchell xl2tpd[16815]: handle_avps: handling avp's for
> tunnel 10014, call 45388
> <repeat of _avp messages>
> Jul 30 07:42:22 mitchell xl2tpd[16815]: control_finish: message type is
> Start-Control-Connection-Request(1).  Tunnel is 1, call is 0.
> Jul 30 07:42:22 mitchell xl2tpd[16815]: control_finish: Peer requested
> tunnel 1 twice, ignoring second one.
> Jul 30 07:42:22 mitchell xl2tpd[16815]: build_fdset: closing down tunnel
> 10014
> Jul 30 07:42:23 mitchell xl2tpd[16815]: network_thread: recv packet from
> 59.167.53.166, size = 100, tunnel = 0, call = 0 ref=0 refhim=0
> Jul 30 07:42:23 mitchell xl2tpd[16815]: get_call: allocating new tunnel 
> for
> host 59.167.53.166, port 1701.
> Jul 30 07:42:23 mitchell xl2tpd[16815]: handle_avps: handling avp's for
> tunnel 7506, call 23414
> <repeat of _avp messages>
> Jul 30 07:42:23 mitchell xl2tpd[16815]: control_finish: message type is
> Start-Control-Connection-Request(1).  Tunnel is 1, call is 0.
> Jul 30 07:42:23 mitchell xl2tpd[16815]: control_finish: Peer requested
> tunnel 1 twice, ignoring second one.
> Jul 30 07:42:23 mitchell xl2tpd[16815]: build_fdset: closing down tunnel
> 7506
> <repeat of new connection to requested tunnel twice messages>
> Jul 30 07:42:27 mitchell xl2tpd[16815]: Maximum retries exceeded for 
> tunnel
> 41665.  Closing.
> Jul 30 07:42:27 mitchell xl2tpd[16815]: build_fdset: closing down tunnel
> 41665
> Jul 30 07:42:27 mitchell xl2tpd[16815]: Connection 1 closed to
> 59.167.53.166, port 1701 (Timeout)
> Jul 30 07:42:32 mitchell xl2tpd[16815]: Unable to deliver closing message
> for tunnel 41665. Destroying anyway.
> Jul 30 07:42:32 mitchell xl2tpd[16815]: build_fdset: closing down tunnel
> 41665
> <and so on and so forth>
>
> Something is failing in the l2tpd negotiation - it looks like we are
> receiving the initial request but Vista isn't seeing our reply or at least
> not following up on it. I have had this same setup successfully working 
> with
> XP boxes, can someone please tell me if there's something different I need
> to do for Vista or where I should be looking to fix this.
>
> Toby
>