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&#39;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&#39;ve made  is that you pointed out.<br>&gt;<br>&gt;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 &gt; $i; done<br>============================================================<br>
<br>Then, restart the tunnel, problem solved!  About half year ago, when I was playing with klips, I&#39;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>
&gt; <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 &quot;ipsec verify&quot; when running with klips/mast stack? Because that may help some newbies who can&#39;t/doesn&#39;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)------&gt;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)------&gt;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 &#39;ip&#39; command                                       [OK]<br>
Checking /bin/sh is not /bin/dash                               [OK]<br>Checking for &#39;iptables&#39; 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&#39;s eth0 is external interface, just opposite of ubuntu<br><br>========================================================================<br>
xp1(192.168.9.106)------&gt;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)------&gt;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&#39;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&#39;s reply message can&#39;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&#39;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&#39;s always this  error message whenever ipsec service restarted<br>I don&#39;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">&lt;<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>&gt;</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&#39;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 &#39;^&#39; 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 &gt; $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]: &quot;xl2tp-gw1&quot;[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]: &quot;xl2tp-gw1&quot;[1] A.A.A.A #1: Main mode peer ID is ID_FQDN: &#39;@xp1&#39;<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]: &quot;xl2tp-gw1&quot;[1] A.A.A.A #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3<br>
<br>
It&#39;s still on the wrong connection....<br>
<br>
Jul 23 06:27:05 tvpn pluto[10304]: &quot;xl2tp-gw1&quot;[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]: &quot;xl2tp-gw1&quot;[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]: &quot;xl2tp-gw1&quot;[1] A.A.A.A #1: the peer proposed: S.S.S.108/32:17/1701 -&gt; <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]: &quot;xl2tp-gw1&quot;[1] A.A.A.A #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=&gt;0x4c86814f &lt;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&#39;m not happy<br>
it picked xl2tp-gw1, which is not the &quot;real&quot; 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>