[Openswan Users] L2TP response unencrypted
peetie470 at gmail.com
Sat Apr 5 19:04:39 EDT 2008
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.
- 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 18.104.22.168/24, although this should not matter
- Server software:
- Openswan 2.5.17, with kernel L2TP support
- Openl2tp 1.2
- pppd 2.4.4
- Kernel 22.214.171.124 with NETKEY
- For the OpenL2TP part I followed mostly
- 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
- 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.
version 2.0 # conforms to second version of ipsec.conf specification
89.a.b.c: PSK "mysecret"
tunnel profile modify profile_name=default \
ppp profile modify profile_name=default \
# 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users