[Openswan Users] XL2TPD/Double NAT issue

Gerald Vogt vogt at spamcop.net
Wed Oct 10 06:30:53 EDT 2007


Paul Wouters wrote:
> On Sat, 6 Oct 2007, Gerald Vogt wrote:
> 
>> O.K. I have tested the Windows XP SP2 client now. I expected Windows to
>> be the lesser problem that's why I have used the Mac before. However,
>> Windows is even worse. Windows does not connect regardless whether the
>> client is NATed or not. The windows client seems to start all over again
>> although the IPsec SA gets established (see Logs below). This happens
>> always, whether I change the configuration from %any to 1701 or not.
> 
> Then you have very likely misconfigured L2TP, either on the server or the client.

O.K. I did not set the AssumeUDPEncapsulationContextOnSendRule registry 
key on the Windows computer. That's why windows established one ipsec sa 
after another. I have set the value to 2 and now I have the same results 
on mac and windows:

I get a successful connection to the server behind a nat router as long 
as the client is not also behind another nat router. When the client is 
behind a nat router as well, i.e. I have double nat, it does not work 
anymore.

I have posted the configs before and noone could tell me where it is 
misconfigured. All suggested changes so far did not solve the problem... 
  I have attached the current config below. The server is running on 
192.168.4.2/24. The router is 192.168.4.1/24 & 1.0.0.1/24 (test public 
IP address). Forwarding of udp ports 500 and 4500 from 1.0.0.1 to 
192.168.4.2.

I can see in gdb or with strace that xl2tpd gets an read event in its 
select call on the server_socket in network_thread() each time the first 
UDP packet for port 1701 comes through the tunnel. However, a few lines 
later the recvmsg() calls returns EAGAIN. IMHO there is an inconsistency 
as the select() should never think there is something to read while 
recvmsg() thinks not.

Could this be an MTU issue? It is kind of weird that xl2tpd gets a 
read-ready in select() on a socket but the next recv reports it would 
still block. Or is this a kernel issue?

Gerald

Current config:

ipsec.conf:


version    2.0    # conforms to second version of ipsec.conf specification

config setup
     nat_traversal=yes
 
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.4.0/24
     dumpdir=/tmp

conn L2TP-PSK
     authby=secret
     pfs=no
     left=%defaultroute
     leftprotoport=17/1701
     right=%any
     rightprotoport=17/%any
     auto=add
     keyingtries=3
     rekey=no

include /etc/ipsec.d/examples/no_oe.conf

---------------------------------

xl2tpd.conf

[global]

[lns default]
ip range = 192.168.5.101-192.168.5.110
local ip = 192.168.5.100
require chap = yes
refuse pap = yes
require authentication = yes
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes


More information about the Users mailing list