You may find that occasionally that the L2TPD daemon falls over which will stop any one logging in. The simplest way to solve this is to create a script called /root/l2tpd_check.sh
Containing the following code
if [ $(ps -fu root | grep " l2tpd" | grep -v grep | wc -l) -eq 0 ]
then
echo "L2TPD daemon down... restarting"
/etc/rc.d/rc.l2tpd start
fi
Then call this script from cron job every 30 mins or so.
e.g. issue command
#$ fcrontab -e
And add the following:
# l2tpd daemon running check 00,30 * * * * /root/l2tpd_check.sh > /var/log/l2tpd_check.log 2>&1
You can see which road warriors are logged in and syntax for removing their conenction with the following simple shell script.
If you get something in your messages log that looks something like: Dec 7 18:20:46 ipcop pluto[3084]: Changing to directory '/etc/ipsec.d/cacerts' Dec 7 18:20:46 ipcop pluto[3084]: loaded cacert file 'cakey.pem' (1679 bytes) Dec 7 18:20:46 ipcop pluto[3084]: error in X.509 certificate Dec 7 18:20:46 ipcop pluto[3084]: loaded cacert file 'cacert.pem' You can safely ignore it. Openswan tries to load all files found in /etc/ipsec.d/cacerts as X.509 certificates but the file 'cakey.pem' is not a certificate so therefore it (correctly) fails. This is nothing to worry about, not sure why IPCop 1.4.x puts this file here but it does.
When you generate you host certificates ipcop will do the following for you (in vpnmain.cgi)
system('/usr/bin/openssl', 'ca', '-gencrl','-out', "${swroot}/crls/cacrl.pem");
This creates an empty Certificate Revocation List (CRL). IPCop does not specify the -crldays parameter so openswan will expect this file to be update in 30 days (the default). To see the current status of all certificates type:
ipsec auto --listall
The crl will be at the bottom. It will tell you the last updated and next update times. If it has expired you users will still be able to log in unless you have specified the:
config setup strictcrlpolicy=yes paramater, no is default.
To update you crl do the following:
openssl ca -gencrl -crldays 60 -out /var/ipcop/crls/cacrl.pem
The crl will now be valid for another 60 days.
You can do a number of things:
- Increase OpenSWAN logging on IPCop
- Increase Firewall logging
- Increase L2TPD debugging
- Switch on logging on Windows
- Use trace tools
- IPSec commands
Increase OpenSWAN logging on IPCOP
Edit the /var/ipcop/ipsec.conf file Change:
klipsdebug=none
plutodebug=none
to:
klipsdebug=all
plutodebug=all
For additional IPsec logging
Increase Firewall logging
You could try logging everything from the external ip you expect the roadwarrior to be connecting from e.g. iptables -A CUSTOMINPUT -s [roadwarrior extip="extip"] -j LOG
to restore firewall config type
iptables -D CUSTOMINPUT -s [roadwarrior extip="extip"] -j LOG
Increase L2TPD debugging Make sure that 'debug' is present in the /etc/ppp/options.l2tp file Rather than running L2TPD as a daemon process run it with the '-D' option. As well as keeping the process in the foreground it will also write additional output to the screen. e.g. /usr/sbin/l2tpd -D
Switch on logging on Windows
See this article at microsoft support
Use trace tools
[Click command for manpage]
IPSec Commands
For more info on what ipsec is doing you can try the following commands:
ipsec tncfg
ipsec eroute
ipsec look
ipsec whack --status
If that fails you can get ipsec to show all information that effects it:
ipsec barf
If you want your Windows 2k clients to connect to another IPSec Machine using X509 certificates and find that upon starting the IPSec Policy Agent service that the cpu jumps to 100% and the windows machine becomes unusable you have probably hit this bug. The solution is to deinstall 3rd party VPN clients or apply a hotfix. The hotfix does not appear on microsoft's website but can be found here. Only apply this patch if you hit this issue and cannot deinstall 3rd Party VPN clients. Try on a test machine first or make a backup of your windows machine first. Try at your own risk as microsoft offer no additional support on this patch.
Have you started the 'Ipsec Policy Agent'? This handles passing the X509 certificates to the IPSec connection. Before you start the above if not already started check that you don't have any 3rd party VPN clients installed. (See Next Question)
No you can get ppp to talk to a Radius server. A Radius server can uses local passwords, samba, ldap and many others. Instructions on getting IPCop to use this are in the Wiki.
This basically tells ipsec via the ipsec.conf file that the connection uses protocol 17 (aka UDP) and port 1701 (L2TP) Older version of windows strangely uses 17/0, this was probably a bug as they all now use 17/1701. Therefore if you are getting problems building the ipsec tunnel before it even connects to the L2TPD daemon check you have the lines:
leftprotoport=17/1701
rightprotoport=17/1701
in your ipsec.conf file.
No. The problem being this solution removes the ip-up/ip-down scripts used by IPCop to rebuild the RED interface with the ISP PPP connection. This is a lot of code and I can't test any of it. Feel free to investigate. It is probably possible to run the ip-up/ip-down for ISP PPP related stuff and drop out of these scripts before they do anything if the PPP connection is a L2TP roadwarriior connection
I'm currently not developing either but other people are. Once someone releases something I'll let you know. You can try out the Beta Addon for Addon Server, but this still does not have a GUI.
This is unknown requests have been raised by various people to integrate L2TP, PPTP, Radius Authentication etc. in the next version of IPCop. Time will tell if the IPCop Dev team have time to add these features.
You can join the IPCop mailing lists or you can try the unofficial IPCop Support Site
No. Somewhere you will need an L2TP Daemon running and you will need to do some exrta config at the command line. See Wiki Page on how to do this for IPCop IPCop L2TP Howto And for anything else you could take a look at: Jacco de Leeuw's HOWTO on using L2TP/IPsec with Windows 2000/XP/9x/Me/NT