[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