Thank you very much, Paul.<br><br>I used to setup l2tp-ipsec tunnels using x509, and I thought that with PSK, only one connection can up at the same time, so I used two connection xl2tp-gw1 and xl2tp-gw2 for test. In fact, I was wondering, if we can not use PSK with multiple client at the same time, how can microsoft's vpn server accomplish that? <br>
<br>Given your advice, I have adjust my config to this(removed all the former conns)<br>=======================================================<br>conn l2tp-ipsec<br> left=S.S.S.S<br> leftprotoport=17/1701<br>
right=%any<br> rightprotoport=17/%any<br> rightsubnet=vhost:%no,%priv<br> pfs=no<br> rekey=no<br> #for SAref + MAST<br> sareftrack=yes<br> overlapip=yes<br> #dead peer detection<br>
dpddelay=30<br> dpdtimeout=120<br> dpdaction=clear<br> #l2tp works in transport<br> type=transport<br> authby=secret<br> auto=add<br>===================================================<br>
<br>In fact, the one big mistake I've made is that you pointed out.<br>><br>>You have not fully disabled rp_filter. Please do so in /etc/sysctl.conf and optionally<br>
to fix the current assignments<br><br>fix it with<br>============================================================<br>for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $i; done<br>============================================================<br>
<br>Then, restart the tunnel, problem solved! About half year ago, when I was playing with klips, I've noticed how important a role rp_filter plays when use klips(my blog post <a href="http://www.linuxplayer.org/2011/02/openswan-use-the-klips-stack/">http://www.linuxplayer.org/2011/02/openswan-use-the-klips-stack/</a>). But I forgot this time! Forgive me for not found/saw the wiki doc:<br>
> <a href="https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd" target="_blank">https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd</a><br>
But I have a suggestion, can we add the check of rp_filter to "ipsec verify" when running with klips/mast stack? Because that may help some newbies who can't/doesn't find a proper doc/guide for their initial config.<br>
<br>Finally, I confirmed the test passed for my scenaro:<br>=============================================================================<br> <br>xp1(192.168.9.106)------>NAT GW1(A.A.A.A)----------l2tp/ipsec VPN GW(eth0:S.S.S.S)<br>
| |_(eth1:<a href="http://192.168.6.18/24">192.168.6.18/24</a>)<br>xp2(192.168.9.106)------>NAT GW2(B.B.B.B) ___________|<br>
<br>after successfully connection, xp1 get ip 192.168.6.128, xp2 get ip 192.168.6.129, I can successfully ping each<br>other(to confirm that the two tunnels with PSK can be up at the same time)<br>
<br>==============================================================================<br><br>I also tested in the following environment,with nearly the same network topology as the above(tell the difference later)<br>====================================================<br>
CentOS 6.0<br>vanilla kernel 2.6.35.13 with SAref patch<br><br>#ipsec verify<br>Checking your system to see if IPsec got installed and started correctly:<br>Version check and ipsec on-path [OK]<br>
Linux Openswan 2.6.35rc1 (klips)<br>Checking for IPsec support in kernel [OK]<br> KLIPS: checking for NAT Traversal support [OK]<br> KLIPS: checking for OCF crypto offload support [OK]<br>
Kernel: IPsec SAref kernel support [OK]<br> Kernel: IPsec SAref Bind kernel support [OK]<br>Checking that pluto is running [OK]<br> Pluto listening for IKE on udp 500 [OK]<br>
Pluto listening for NAT-T on udp 4500 [OK]<br>Two or more interfaces found, checking IP forwarding [OK]<br>Checking NAT and MASQUERADEing [OK]<br>Checking for 'ip' command [OK]<br>
Checking /bin/sh is not /bin/dash [OK]<br>Checking for 'iptables' command [OK]<br>Opportunistic Encryption Support [DISABLED]<br>
<br>====================================================<br><br>The topology difference between the centos one and the ubuntu one is that on centos<br>it's eth0 is external interface, just opposite of ubuntu<br><br>========================================================================<br>
xp1(192.168.9.106)------>NAT GW1(A.A.A.A)----------l2tp/ipsec VPN GW(<b>eth1</b>:S.S.S.S)<br>
| |_(<b>eth0</b>:<a href="http://192.168.6.18/24">192.168.6.18/24</a>)<br>
xp2(192.168.9.106)------>NAT GW2(B.B.B.B) ___________|<br>========================================================================<br><br>openswan and xl2tpd configuration is completely identical. However, it failed. <br>
check /var/log/secure, it confirms that IPSec SA can be established without any problem. <br>check /var/log/messages about xl2tpd's log message<br>=======================================================================<br>
Jul 23 14:37:50 localhost xl2tpd[5299]: Enabling IPsec SAref processing for L2TP transport mode SAs<br>Jul 23 14:37:50 localhost xl2tpd[5299]: IPsec SAref does not work with L2TP kernel mode yet, enabling forceuserspace=yes<br>
Jul 23 14:37:50 localhost xl2tpd[5299]: IPsec SAref does not work with L2TP kernel mode yet, enabling forceuserspace=yes<br>Jul 23 14:37:50 localhost xl2tpd[5299]: This binary does not support kernel L2TP.<br>Jul 23 14:37:50 localhost xl2tpd[5299]: This binary does not support kernel L2TP.<br>
Jul 23 14:37:50 localhost xl2tpd[5300]: xl2tpd version xl2tpd-1.3.0rc1 started on localhost.localdomain PID:5300<br>Jul 23 14:37:50 localhost xl2tpd[5300]: xl2tpd version xl2tpd-1.3.0rc1 started on localhost.localdomain PID:5300<br>
Jul 23 14:37:50 localhost xl2tpd[5300]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Forked by Scott Balmos and David Stipp, (C) 2001<br>
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked by Scott Balmos and David Stipp, (C) 2001<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Inherited by Jeff McAdams, (C) 2002<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Inherited by Jeff McAdams, (C) 2002<br>
Jul 23 14:37:50 localhost xl2tpd[5300]: Forked again by Xelerance (<a href="http://www.xelerance.com">www.xelerance.com</a>) (C) 2006<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Forked again by Xelerance (<a href="http://www.xelerance.com">www.xelerance.com</a>) (C) 2006<br>
Jul 23 14:37:50 localhost xl2tpd[5300]: Listening on IP address 0.0.0.0, port 1701<br>Jul 23 14:37:50 localhost xl2tpd[5300]: Listening on IP address 0.0.0.0, port 1701<br>Jul 23 14:38:21 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel 61483. Closing.<br>
Jul 23 14:38:21 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel 61483. Closing.<br>Jul 23 14:38:21 localhost xl2tpd[5300]: Connection 18 closed to 192.168.9.106, port 1701 (Timeout)<br>Jul 23 14:38:21 localhost xl2tpd[5300]: Connection 18 closed to 192.168.9.106, port 1701 (Timeout)<br>
Jul 23 14:38:36 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel 55277. Closing.<br>Jul 23 14:38:36 localhost xl2tpd[5300]: Maximum retries exceeded for tunnel 55277. Closing.<br>Jul 23 14:38:36 localhost xl2tpd[5300]: Connection 18 closed to 192.168.9.106, port 1701 (Timeout)<br>
Jul 23 14:38:36 localhost xl2tpd[5300]: Connection 18 closed to 192.168.9.106, port 1701 (Timeout)<br>=======================================================================<br><br>Then I do a tcpdum on mast0 interface of this failed connection, and then another tcpdump of the worked one on ubuntu, and noticed that<br>
for the failed one:<br>==========================================================================<br>#source destination protocol info<br>192.168.9.106 S.S.S.S L2TP Control Message - SCCRQ (tunnel id=0, session id=0)<br>
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP (tunnel id=14, session id=0)<br>192.168.6.18 192.168.9.106 L2TP Control Message - ZLB (tunnel id=14, session id=0)<br>#seems server's reply message can't reach client, it keep resending<br>
192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP (tunnel id=14, session id=0)<br>192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP (tunnel id=14, session id=0)<br>192.168.6.18 192.168.9.106 L2TP Control Message - SCCRP (tunnel id=14, session id=0)<br>
#client request again...<br>192.168.9.106 S.S.S.S L2TP Control Message - SCCRQ (tunnel id=0, session id=0)<br>...<br>============================================================================<br>
<br>worked one:<br>==========================================================================<br>No. time source destination protocol info<br>2 0.995671 192.168.9.106 S.S.S.S L2TP Control Message - SCCRQ (tunnel id=0, session id=0)<br>
3 2.000284 S.S.S.S 192.168.9.106 L2TP Control Message - SCCRP (tunnel id=15, session id=0)<br>4 2.000436 S.S.S.S 192.168.9.106 L2TP Control Message - ZLB (tunnel id=15, session id=0)<br>
5 2.035904 192.168.9.106 S.S.S.S L2TP Control Message - SCCCN (tunnel id=30282, session id=0)<br>6 2.035969 S.S.S.S 192.168.9.106 L2TP Control Message - ZLB (tunnel id=15, session id=0)<br>
============================================================================<br>the l2tp/ipsec gateway's internal IP 192.168.6.18 is not involved here!<br>Then I change /etc/xl2tpd/xl2tpd.conf on centos, set<br>listen-addr = S.S.S.S<br>
restart xl2tpd, then everything works fine, just like the ubuntu one.<br><br>One more thing, no matter with ubuntu or CentOS, there's always this error message whenever ipsec service restarted<br>I don't know if it matters:<br>
====================================================<br>Jul 23 11:27:34 tvpn pluto[13271]: ERROR: PF_KEY K_SADB_X_PLUMBIF response for configure_mast_device included errno 17: File exists<br><br><br><br><br><div class="gmail_quote">
2011/7/23 Paul Wouters <span dir="ltr"><<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Sat, 23 Jul 2011, Curu Wong wrote:<br>
<br>
For using xl2tpd and openswan as an L2TP/IPsec server, please see:<br>
<br>
<a href="https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd" target="_blank">https://gsoc.xelerance.com/<u></u>projects/openswan/wiki/<u></u>L2TPIPsec_configuration_using_<u></u>openswan_and_xl2tpd</a><div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can not get this work. mainly openswan issue, not xl2tpd.<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
conn xl2tp-gw1<br>
right=A.A.A.A<br>
rightid=@xp1<br>
also=xl2tp-common<br>
auto=add<br>
<br>
conn xl2tp-gw2<br>
right=B.B.B.B<br>
rightid=@vm-xpsp3<br>
also=xl2tp-common<br>
auto=add<br>
<br>
</blockquote></div>
Note those will never establish because l2tp does not work like that.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
conn xl2tp-common<br>
left=%defaultroute<br>
rightprotoport=17/%any<br>
rightsubnet=vhost:%no,%priv<br>
leftprotoport=17/1701<br>
pfs=no<br>
rekey=yes<br>
keyingtries=3<br>
type=transport<br>
sareftrack=yes<br>
overlapip=yes<br>
dpddelay=30<br>
dpdtimeout=120<br>
dpdaction=clear<br>
authby=secret<br>
</blockquote>
<br></div>
Change left= to be the actual IP on the public interface.<br>
Change rekey to no.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the problem is:<br>
if I use protostack=auto or protostack=klips, then client xp1 behind gw1(A.A.A.A) ( IP: 192.168.9.106), vm-xpsp3 behind<br>
gw2(B.B.B.B) (IP: 192.168.9.106) can connect to the l2tp server without any problem, but, the can not connect at the same time. if<br>
one client connect in, the other will be kicked out because of overlapip.<br>
<br>
However, when I set protostack=mast, tunnel mode can't be established, only transport can. Also, the command<br>
ipsec -t mangle -L shows nothing about the IPSEC chain. seems that _updown.mast is never get called.<br>
</blockquote>
<br></div>
_updown.mast is only called when a successfull tunnel has come up.<br>
<br>
Looking through the barf.....<br>
<br>
+ _________________________ /proc/sys/net/ipv4/conf/star-<u></u>rp_filter<br>
+ cd /proc/sys/net/ipv4/conf<br>
+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter eth1/rp_filter ipsec0/rp_filter lo/rp_filter mast0/rp_filter<br>
all/rp_filter:1<br>
default/rp_filter:1<br>
eth0/rp_filter:1<br>
eth1/rp_filter:1<br>
ipsec0/rp_filter:1<br>
lo/rp_filter:1<br>
mast0/rp_filter:1<br>
<br>
You have not fully disabled rp_filter. Please do so in /etc/sysctl.conf and optionally<br>
to fix the current assignments, run:<br>
<br>
for i in /proc/sys/net/conf/*<br>
do<br>
echo 0 > $i/rp_filter<br>
done<br>
<br>
Jul 23 06:26:46 tvpn pluto[10304]: SAref support [enabled]<br>
Jul 23 06:26:46 tvpn pluto[10304]: SAbind support [enabled]<br>
<br>
good. SAref works.....<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: | find_host_connection2 returns xl2tp-gw1<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: responding to Main Mode from unknown peer A.A.A.A<br>
<br>
That worries me. I strongly recommend removing the two xl2tpd-gw connections and just<br>
have one proper connection for l2tp-ipsec. What happens now it has to correct<br>
itself later to pick the right configuration....<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: Main mode peer ID is ID_FQDN: '@xp1'<br>
<br>
that is a windows box? I would not expect an ID_FQDN, but an ID_IPV4.<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3<br>
<br>
It's still on the wrong connection....<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}<br>
<br>
phase1 is up.<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: IDci was FQDN: :@\224l, using NAT_OA=<a href="http://192.168.9.106/32" target="_blank">192.168.9.106/32</a> 0 as IDci<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #1: the peer proposed: S.S.S.108/32:17/1701 -> <a href="http://192.168.9.106/32:17/0" target="_blank">192.168.9.106/32:17/0</a><br>
<br>
Hmm that FQDN looks odd...<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: "xl2tp-gw1"[1] A.A.A.A #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x4c86814f <0x8a1db925 xfrm=3DES_0-HMAC_MD5 NATOA=192.168.9.106 NATD=A.A.A.A:4500 DPD=none}<br>
<br>
but you get phase2 up. At this point packets on udp port 1701 should be able to flow, though I'm not happy<br>
it picked xl2tp-gw1, which is not the "real" client configuration.<br>
<br>
Jul 23 06:43:47 tvpn pluto[10304]: packet from <a href="http://222.96.156.23:500" target="_blank">222.96.156.23:500</a>: ignoring Delete SA payload: not encrypted<br>
<br>
Then it seems your end hangs up, possible due to an L2TP auth error (or because no packets can flow)<br>
<br>
Try removing your 3 conns, and just have:<br>
<br>
conn xl2tp-psk<br>
right=%any<br>
left=A.A.A.A<div class="im"><br>
rightprotoport=17/%any<br>
rightsubnet=vhost:%no,%priv<br>
leftprotoport=17/1701<br>
pfs=no<br>
rekey=yes<br>
keyingtries=3<br>
type=transport<br>
sareftrack=yes<br>
overlapip=yes<br></div>
#dead peer detection<div class="im"><br>
dpddelay=30<br>
dpdtimeout=120<br>
dpdaction=clear<br>
authby=secret<br>
<br></div>
Thanks for testing!<br><font color="#888888">
<br>
Paul<br>
</font></blockquote></div><br>