The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
I have installed openswan on a linksys WRT 54GS running openwrt RC4 and I am using a Windows XP Pro SP2 machine as a L2TP /IPSEC client. I have setup openswan according to the instructions given on the IPSEC/OPenwrt page but I keep getting the following message from pppd.
LCP:timeout sending Config-Requests
I have attempted to change the ppp version to the previous one (2.4.2) but no luck.
Any ideas?
If you need any further info on my setup please let me know.
Same problem here with WhiteRussian RC5 ...
IPsec tunnel created fine then,
l2tp started and selected IP address then,
pppd started and begin LCP negotiation ... actualy receive first LCP packet and resend the reply 10 times follow by same message:
"LCP: timeout sending Config-Requests"
I haven't tried openswan as L2TP/IPSEC terminator(*), but I can suggest some things to look for:
- tcpdump -i eth0 -n -s1500 -v gives surprisingly useful information (for openwrt, install 'tcpdump' and 'libpcap' packages; they're quite large, make sure you have enough space and if necessary prune your system first)
- try to work out if phase 1 and phase 2 exchanges are fully successful, and your L2TP HELLO and/or PPP LCP config-requests are actually being encapsulated in ESP (tcpdump will show you if some ESP packets are being sent)
- if not, then turn on IKE debugging at the Windows side: this is described at http://www.microsoft.com/technet/prodte … pstep.mspx. Then look in \windows\debug\oakley.log for hints
- check that l2tpd is starting, and whether the tunnel has come up and pppd is started. If so, you can turn on debugging for the ppp daemon.
- if your machine has multiple IP addresses, check that the responses to the L2TP packets have the expected source address; in some cases it's possible for packets to be sent from 1.1.1.1 to 2.2.2.2, but the responses to be from 3.3.3.3 to 1.1.1.1. If so, try pointing the client at 3.3.3.3, or binding the l2tpd to a specific IP address
Incidentally, I discovered that ipsec-tools doesn't support transport mode and NAT-T at the time time. I don't know if this same restriction applies to openswan.
HTH, Brian.
(*) however I have tested Cisco IOS, Juniper Netscreen and ipsec-tools as L2TP/IPSEC terminators with XP and 2K clients
When you say "the instructions given on the IPSEC/OPenwrt page", do you mean these?
http://wiki.openwrt.org/IPSec#head-8353 … 5691d04c7e
This page which says "l2tpd doesn't work yet" ? :-)
OK, I have tried setting this up the other way round, with OpenWRT (openswan/l2tpd) as the client, and a Cisco 72xx as the terminator.
I see a problem very similar to yours: logread shows just "LCP Conf-Request" being sent. However there are some other useful things I've found:
* If I tcpdump on ipsec0, I can see the LCP Conf-Ack's coming back from the far end correctly. They're just not making it to pppd.
* If I use "netstat -au" I can see:
# netstat -au
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 localhost:34954 *:*
udp 0 0 10.71.32.1:4500 *:*
udp 10612 0 *:1701 *:*
^^^^^^^^^^^^
udp 0 0 10.71.32.1:500 *:*
netstat: no support for `AF INET6 (udp)' on this system.I have highlighted the suspicious line: there are packets waiting in the UDP receive queue for port 1701 which l2tpd has simply not eaten up.
Do you see the same symptoms? If so we're probably looking at the same problem.
l2tpd is pretty old; it might be worth trying rp-l2tp instead - http://sourceforge.net/projects/rp-l2tp/
However, as it's not straightforward for me to cross-compile this right now, I might dig a bit more on the existing l2tpd first.
l2tpd seems to be getting stuck in its receive loop, network_thread() in network.c. This is based on the following observations:
# echo "s" >/var/run/l2tp-control
--- this works before the l2tp session is started (run "logread" to see the output)
# echo "c peername" >/var/run/l2tp-control
--- starts the tunnel OK, but at that point "netstat -au" shows the UDP Recv-Q incrementing;
--- also a further echo "s" >/var/run/l2tp-control is ignoredSo you could try this too. Check echo "s" works, then initiate your connection from Windows client, and then try echo "s" again and see if it has stopped working.
I notice that sending a kill -USR1 to the l2tpd process *does* dump the status; this shows some "unknown events" in the scheduler
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: ====== l2tpd statistics ========
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: Scheduler entries:
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: 1: Unknown event
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: 2: Unknown event
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: 3: Unknown event
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: 4: Unknown event
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: 5: HELLO to 58124
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: Total Events scheduled: 5
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: Number of tunnels open: 1
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: Tunnel dc, ID = 32285 (local), 58124 (remote) to X.X.X.X:1701 control_seq_num = 4, control_rec_seq_num = 2, cLr = 4
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: Call dc, ID = 36611 (local), 2611 (remote), serno = 1, data_seq_num = 10, data_rec_seq_num = 0, pLr = -1, tx = 300 bytes (10), rx= 0 bytes (0)
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: ==========Config File===========
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: LAC entry dc, LNS is/are:
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: X.X.X.X
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]:
Jan 1 18:17:56 (none) kern.warn l2tpd[3955]: ================================According to strace, it is blocking on read(). I think this is in read_packet() in call.c, which gets data from the pppd process's pty. I see:
read(6, "... ppp packet ...")
sendto(3, "... l2tp packet ...")
...
read(6, "... ppp packet ...")
sendto(3, "... l2tp packet ...")
read(6,Sending a USR1 signal here interrupts the read system call, but it is restarted.
I can't see why it should block, as the master pty is opened in non-blocking mode, but a workaround is to check there is data available before reading. I have made a patch for this and it seems to work; I have an L2TP/IPSEC tunnel running now.
You can find the patch at http://psg.com/~brian/software/openwrt/ … lock.patch (put into buildroot in the package/l2tpd/packages/directory) and a replacement package for WhiteRussian as http://psg.com/~brian/software/openwrt/ … mipsel.ipk
See if this works for you... regards, Brian.
Ticket opened at https://dev.openwrt.org/ticket/455
I would like to thank everyone who read and even replied to my post and candlerb for providing a patch.
I haven't tried applying the patch yet but thank you all.
I applied the patch provided by candlerb and it works fine for me on whiterussian RC4 using certificates (haven't checked it on RC5 yet but I intend to). It works for clients behind NAT too.
Thank you very much once more.
After searching Google for three days trying to figure out how to make IPSec + L2TP work, I am thankful that I came across this post. If it helps anyone, I am running WhiteRussian RC5 and am able to get IPSec + L2TP to work with PSK. I have been failing miserably to get certificates to work. I also came across a post that claimed it was possible to get both PSK and Certs to work.
If it helps anyone, here are some notes on getting IPSec + L2TP with PSK (PreShared Keys) to work on WhiteRussion RC5.
It makes no difference in the configuration below, but I choose to separate my wireless network from my wired network. The instructions for doing that are here: http://wiki.openwrt.org/OpenWrtDocs/Configuration. Search for "To separate the LAN from the WIFI".
(1) I started with WhiteRussian RC5 on a WRT54GS v1.1 (8 MB flash and 32 MB memory). I used the micro squashfs install.
(2) You will need to install all of the packages listed below. If you prefer a different time package over openntpd, feel free to substitute. It may be that the list below is not enough. I apologize in advance if I missed something.
cd /tmp
ipkg install openntpd
ipkg install openswan
ipkg install ppp
ipkg install l2tpd
wget http://psg.com/~brian/software/openwrt/l2tpd_0.70pre-2_mipsel.ipk
ipkg install l2tpd_0.70pre-2_mipsel.ipk(3) Assuming that you installed openntpd, you will need to properly configure it. Since I live in the United States, I choose to use us.pool.ntp.org. If you don't live in the United States, you can visit http://www.pool.ntp.org/ to find a better value than the default. I edited the file /etc/ntpd.conf and changed the line that read servers pool.ntp.org to:
servers us.pool.ntp.org(3) This next step is dangerous I am comfortable with doing this because my WRT54GS is sitting on an isolated testbed network. I have not yet gotten around to learning how to write firewall rules, so I totally disabled the firewall ruleset. Do not do this on an OpenWRT that is supposed to be protecting something. I would deeply appreciate it someone posted a set of firewall rules for allowing IPSec + L2TP traffic. My basic understanding that the ruleset needs to allow protocol 50 (ESP), protocol 51 (AH), port 500 (ISAKMP?) and port 4500 (only needed for NAT-T).
cd /etc/init.d
mkdir .disabled
mv S45firewall .disabled(4) Create/edit /etc/modules.d/60-l2tp. This will cause the thee PPP kernel modules to get loaded automatically at boot.
slhc
ppp_generic
ppp_async(5) At this point, you need to reboot your router to make sure that everything is properly set up. After reboot, check that your router has the current time with:
root@OpenWrt:~# date
Fri Apr 14 04:32:06 PDT 2006
root@OpenWrt:~#Check that the proper modules got loaded. Depending on the packages that you have loaded, you may see more modules loaded. It only important (for our purposes) that you see slhc, ppp_generic, and ppp_async have been loaded.
root@OpenWrt:~# lsmod
Module Size Used by Tainted: P
ppp_async 7948 0 (unused)
ppp_generic 22868 0 [ppp_async]
slhc 6352 0 [ppp_generic]
wlcompat 14896 0 (unused)
wl 423640 0 (unused)
switch-adm 6132 0 (unused)
switch-core 4896 0 [switch-adm]
diag 3320 0 (unused)
root@OpenWrt:~#There is no point in going on if both of these test do not pass.
(6) Create/edit the /etc/ipsec.secrets file. Please change the password from "my-preshared-key" to something only you know. As soon a some little cracker comes along and reads this post, you can be sure "my-preshared-key" is going to be part of the default password that hacking toolkits will try. Why would you want to make life easy for a cracker?
: PSK "my-preshared-key"(7) Create/Edit the /etc/ipsec.conf file. Replace the 172.16.27.2 with the WAN interface IP address for your router.
version 2.0
config setup
interfaces="ipsec0=vlan1"
plutodebug=none
nat_traversal=no
conn L2TP-PSK
authby=secret
pfs=no
ike=aes-sha,3des-sha
esp=aes-sha1,3des-sha1
left=172.16.27.2
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
auto=add
### Disable Opportunistic Encryption
## OE does not work unless it is properly configured. Since we are not
## properly configuring it, we are disabling it instead.
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore(8) Create/Edit the /etc/l2tpd/l2tpd.conf file. Here are some important notes. The listen-addr is the WAN address of your router. The local-ip address is a special address on your inside/protected network that is reserved just for L2TP. The local-ip address will be used by L2TP clients for their default route (at least that what I found in various bits of docs). The ip-range is supposed to be a range of IP addresses handed out to the clients as they connect. I found, in my testing, that the clients were just DHCP'ing for addresses from DNSmasq. Your mileage may vary. While you are testing, you may want to set the ppp debug to on. I turned off all of the debugging once things worked because it sped it up the connection time. Why this is, I'm not sure, but I think it is "expensive" to write the debugging information to the system log. The name parameter serves no purpose as far as I can tell. It is not referenced anywhere else.
;
; This is a minimal sample l2tpd configuration file for use
; with L2TP over IPsec.
;
; The idea is to provide an L2TP daemon to which remote Windows L2TP/IPsec
; clients connect. In this example, the internal (protected) network
; is 192.168.1.0/24. A special IP range within this network is reserved
; for the remote clients: 192.168.1.128/25
; (i.e. 192.168.1.128 ... 192.168.1.254)
;
; The listen-addr parameter can be used if you want to bind the L2TP daemon
; to a specific IP address instead of to all interfaces. For instance,
; you could bind it to the interface of the internal LAN (e.g. 192.168.1.98
; in the example below). Yet another IP address (local ip, e.g. 192.168.1.99)
; will be used by l2tpd as its address on pppX interfaces.
[global]
listen-addr = 172.16.27.2
[lns default]
ip range = 172.16.45.96-172.16.45.127
local ip = 172.16.45.2
require chap = yes
refuse pap = yes
require authentication = yes
name = ARoseByAnyOtherName
ppp debug = no
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes(9) Create/edit /etc/ppp/chap-secrets. There are versions of PPP that can use radius to get the secrets. Obviously, these instructions don't cover those versions. In fact, my personal plan, now that I was able to get PSK (pre-shared keys) working is to get Certs working. I hope that it is obvious that you need to protect the information in this file. From various bits of experimentation, I found that L2TP did not use the IP address that I set in this file. I don't know if that is something I'm doing wrong or a bug.
As noted above, please change the usernames and passwords in this file. Why would you want to make a crackers life easier?
#USERNAME PROVIDER PASSWORD IPADDRESS
narzola * "password" *
bteed * "wordpass" *(10) Create/edit /etc/ppp/options.l2tp. Uncomment #debug if you want debugging messages. The ipcp-max-configure 5, lcp-echo-interval 5, and lcp-echo-failure 5 cause the link to fail faster when you have something misconfigured. It is harmless to remove all three if you prefer the defaults.
ipcp-accept-local
ipcp-accept-remote
ipcp-max-configure 5
lcp-echo-interval 5
lcp-echo-failure 5
auth
idle 1800
mtu 1410
mru 1410
proxyarp
lock
#debug(11) Rename l2tpd to S61l2tpd. This is just good form. By renaming this file, you will be certain that l2tpd will be started after ipsec (S60ipsec).
cd /etc/init.d
mv l2tpd S61l2tpd(12) Reboot your router. Log in and use the logread command to see the system log file. You need to make sure that OpenSwan started. The following two sets of messages should be in your logfile (but not necessarily next to each other). Instead of 172.16.27.2, you will see your WAN interface IP address in the messages.
Apr 14 05:01:06 (none) kern.warn pluto[3495]: Starting Pluto (Openswan Version 2.4.4 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEz}FFFfgr_e)Apr 14 05:01:10 (none) kern.warn pluto[3495]: listening for IKE messages
Apr 14 05:01:10 (none) kern.warn pluto[3495]: adding interface ipsec0/vlan1 172.16.27.2:500You need to make sure that the L2TP daemon started correctly:
Apr 14 05:03:34 (none) kern.info l2tpd[3597]: This binary does not support kernel L2TP.
Apr 14 05:03:34 (none) kern.info l2tpd[3598]: l2tpd version 0.69 started on OpenWrt PID:3598
Apr 14 05:03:34 (none) kern.info l2tpd[3598]: Linux version 2.4.30 on a mips, listening on IP address 172.16.27.2, port 1701(13) Configure your NT or MacOS computer to make the VPN connection. I don't have the time to write instructions for that at the moment. I can say that my 10.4.6 PowerBook and my Windows XP Pro (fully patched) were both able to make a connection. It took a few tries, but everything works. On the MacOS side, there are fewer options and everything worked pretty much the first time (after I installed the lock patch). On the Windows side, it was a little more complicated, but with a little tweaking, it worked.
I hope this helps someone. Many thanks to all of the folks who made OpenWRT possible.
Nelson
The discussion might have continued from here.