[Openswan Users] L2TP/IPsec problem

[Nico Schmoigl]

Hi Paul,
hi rest of the list members,

> IPsec has two modes. Transport mode and Tunnel mode. Almost all type of
> IPsec connections are Tunnel mode. Microsoft's L2TP implementation uses
> IPsec in Transport mode.
> 
> You can try to setup a simple 'standard' tunnel, which implies type=tunnel
> and see if the problem is there or not. Then change it to type=transport 
> and see if the problem reappears. I think it will.

Here's the interesting part of it: my current tests (further results 
below) show that the sequence

transport (1), tunnel (2), transport (3)

(1) does not work
(2) works
(3) works (!)

But please: Don't ask me why!

>> And there another point drops in, what I do not understand in this 
>> scenario: If I decrease the MTU, then I decrease the size of the 
>> packets I can accept. Thus, fragementation will occur "earlier". Why 
>> could it then happen, that IKE packets suddenly get accepted? From my 
>> point of view, the certificates must even be smaller than that to be 
>> accepted. I could understand the system, if I had to *increase* the 
>> MTU size which would allow bigger certificates to send (doesn't get 
>> fragemented then).
> ppp packets only flow after the IPsec tunnel is up. There are two different
> layers of fragmentation happening here. Or perhaps even three or four, 
> depending on the packet sizes. (ppp, l2tp, esp, udpinesp)

mmhm... my current tests don't really show the impact of MTU/MRU values 
on this issue. I think, that I observered another, more overlaying 
issue. If using "big certificates", rebooting of the Windows client does 
matter!

>> I am not that far into the code, that I could fix it, but I am willing 
>> to help you with documentation.
>> Is there any existing documentation on that besides the bug notes 
>> #401? Does it make sense to also add my data to this bug report?
> I think the key issue is to see hwo all these bug reports on similar errors
> fit together or not. Are they the same bug.
> 
> If you can do the testing I described above with tunnel and transport mode,
> and give us the results of that, it might be very useful to understand this
> issue.

At http://www.schmoigl-online.de/ipsec/debugging.tar.bz2 you'll find a 
documentation package of my latest testings on this issue. Here's the 
environment in which these tests happend:

* Linux box, Kernel v2.4.31 with openswan 2.3.1, NAT-T patch applied to 
the kernel
* Road Warrior with Windows 2000 SP4, patch #818043 applied and 
activated, IPCOMP_DEFLATE not activated
* Connection of the Linux Box is done through eth1; direct Internet 
connection (no NAT involved)
* Road Warrior is connected via GPRS mobile celluar phone provider which 
only sends intranet IPs (namely 10.x.x.x) which are then NATed on 
leaving the cellular network.
* setup files on the linux box are within the documentation package
* private keys and used certificates are in an extra file (downloadable 
from http://www.schmoigl-online.de/ipsec/keys.tar.bz2). If applying, the 
password is '1234' (please note: my system does not accept these keys 
anymore!)
* with every setup, there is a corresponding subdir in the documentation 
package. There you'll find the used setup files (ipsec.conf, 
options.l2tpd, ...) and the generated debug messages both from the VPN 
server (/var/log/message excerpt) and from the OAKLEY of the client 
(%SYSTEMROOT%\debug\oakley.log).
* ipsec on the VPN server will be restarted via the command 'ipsec setup 
--restart' between each setup
* restarts of the client (and therefor restarts of the OAKLEY) are 
written expicitly in the description of the setup

Here's what I did:

setup 1:
* Client with big certificate (just reinstalled; no reboot so far)
* Server with big certificate (just reinstalled; no reboot so far)
* ipsec in transport mode
* mtu of PPPD is 1500
* mru of PPPD is standard
result: connection established

setup 2:
* same as setup 1
* but after a restart of the client (same key/certificates)
result: connection timed out

setup 3:
* same as setup 2
* but with "type=tunnel" instead
result: connection established

setup 4:
* same as setup 2
* but with mru and mtu set to 800 in options.l2tpd
result: connection established

setup 5:
* same as setup 2 for verification
result: connection established (!)

setup 6:
* same as setup 5
* just again after a normal rebooting of the client (nothing else changed)
result: connection timed out

setup 7:
* same as setup 6
* deleting the old Client's Certificate and its key
* adding the new small certificate to the client's repository
* deleting the old Server's Certificate and its key
* adding the new small certificate to the server's repository
result: connection established

setup 8:
* same as setup 7
* but client just rebooted
result: connection established



In short: If you have a big certificate installed and you reboot your 
client, chances are good, that you may not connect anymore. However, 
with small certificates, it doesn't matter to reboot the client.

So far, this sounds to be a Windowsish problem, not purely ipsec related.

Oh, just a short note: I just read in the bug database, that someone 
said that a very silimar issue could be solved by using strongswan 
instead of openswan (compare bug issue #401). I must confess, that this 
is not true for the issue I am just observing: I already had strongswan 
running on my box, however experiencing the same problems as described 
here. That is also why I am not adding my findings to this bug report.

I hope that my work helps you a bit with debugging this issue...

73
    Nico