[Openswan Users] L2TP response unencrypted

[Peter Laczko]

Hi,

I am trying to set up an l2tp/ipsec connection between a Windows XP SP2 PC
and a Linux Openswan server. The (very helpful) guide I'm following is
http://www.jacco2.dds.nl/networking/freeswan-l2tp.html  . However, I ran
into a problem.

The ipsec part of the connection _seems_ to be up and running, the l2tp
server gets the packets from the client. But the response leaves the server
unencrypted. I confirmed this by sniffing the traffic on both the server and
the client. What can be the problem? I'd really appreciate some help as I
have no idea what went wrong.


Details:
 - Client is behind a NAT (no ipsec settings available)
 - Client is Win XP with SP2. I did not apply the registry change since...
 - ...Server is not behind NAT (it does serve a private net as a gateway,
but that should not matter (?))
 - I'm using preshared keys
 - Client is on subnet 192.168.2.0/24 locally
 - Subnet "behind" server is 162.168.1.0/24, although this should not matter
(?)
 - Server software:
    - Openswan 2.5.17, with kernel L2TP support
    - Openl2tp 1.2
    - pppd 2.4.4
    - Kernel 2.6.24.3 with NETKEY
 - For the OpenL2TP part I followed mostly
http://opensource.katalix.com/openl2tp/quick_start.html

Symptoms:
  - IPSEC connection _seems_ to come up fine
  - When I start OpenL2TP in the foreground, it is apparent that it receives
the packets from the client
  - It tries to respond, but the response doesn't make it back to the client
  - When capturing the traffic on the SERVER I see the following:
     - Incoming packet from client, ESP encapsulated into an UDP packet,
fine. I don't see it decrypted, but I read that's okay with NETKEY.
     - Outgoing packet from server, L2TP, plain text: UDP, src and dst ports
1701.
  - When capturing the traffic on the CLIENT I see the following:
     - Outgoing ESP packet to server, the exact same one as received there.
     - And nothing else, since the client is behind NAT, and since the
server doesn't respond in a NAT-T encapsulated packet, the response is
dropped by the NATting router and never reaches the client.
     - If I set in the NATting router that the client PC is a Virtual
Demilitarized Zone, the response packets do show up - in plain L2TP text as
sent. This confirms for me that the capture results on the server are not
due to some NETKEY vs. sniffer artifact, but indeed, the packets are not
encrypted by IPSEC.
  - Since there is no communication on the L2TP level, the connection
doesn't build up and eventually times out.

Configuration:
  - 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.1.0/24

conn L2TP-PSK-NAT
        authby=secret
        pfs=no
        keyingtries=3
        rekey=no
        ikelifetime=8h
        keylife=1h
        type=transport

        left=89.a.b.c
        leftprotoport=17/1701
        leftid="89.a.b.c"

        right=%any
        rightprotoport=17/1701
        rightsubnet=vhost:%no,%priv

        auto=add

 - ipsec.secrets:
89.a.b.c: PSK "mysecret"

 - l2tp.conf
tunnel profile modify profile_name=default \
        our_udp_port=1701

ppp profile modify profile_name=default \
        local_ipaddr=192.168.1.123

# NOTE: I know that this last line is probably incorrect, but I didn't get
to think about IP assignment yet... I wanted to use the dynamic IP pooling
support of OpenL2TP as described in (
http://opensource.katalix.com/openl2tp/quick_start.html ), but it somehow
kept the server from responding anything. I probably messed that up and I'll
fix it once I can get the two L2TP entities to talk.


I'll be happy to post other config files or logs as needed. Thank you again
for your help.

Best regards,
Peter Laczko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080406/ecb884a3/attachment.html