[Openswan Users] L2TP/IPsec problem

[Nico Schmoigl]

Hi Paul,

>> L2tpd can't help here. That stuff is still at the phase of ipsec 
>> negotiations. Therefore l2tpd isn't involved here.
>
> It is. By telling l2tp to make smaller packets, the ESP packets will 
> also be smaller and the espinudp will also be smaller.

!? Mmhm... now I am a bit confused about l2tp and certificates. As I 
read it from the currently available howtos and manuals, I understood 
that there two distinct phases during protocol establishment (please 
interrupt me, if I am babbling nonsense). At a first step, OAKLEY setups 
a IPSEC connection based on certificates. IPSEC then allows to securely 
connect the roadwarrior to (local) port 1701 on which a L2TP daemon is 
listening. Via this "bridge" the data then is tunneled to a PPP stack on 
the VPN gateways system.

 From my observations the certificates only come "on stage" during the 
very first phase where an authenticated connection is being established 
via the IPSEC protocol family. At this point, there even is no tunnel 
for a communication between the client and the L2TP process. You can 
even put it harder: IPSEC doesn't care, if L2TP or whatever will be used 
later on. I also could authenticate two IPSEC linux boxes with 
certificates (via a NAT-T connection) and then send raw IP via the 
interfaces. Shouldn't then I have the same problem, won't I? Or am I 
misinterpretating something?

>> As already mentioned on the list, I now got it working. I decreased 
>> the size of the certificates (both of the CA and the used key itself) 
>> to the absolute minimum (I formerly used phpki from 
>> http://phpki.sf.net which adds additional x509v3 values like CRT, 
>> NSComments and all that stuff - look at my patch, which is available 
>> at the project's website!).
>
> This seems a different problem of IKE packets not surviving 
> fragmentation.

At least this makes sense to my understanding: If I decrease the size of 
the certificate, then the certificate's data fits into one packet which 
does not get fragmented, because it is not big enough. It then doesn't 
get spoiled and therefore accepted by the VPN gateway.
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).

>> If it helps you, I can send you a bunch of keys and certificates with 
>> which it works and another bunch with which it doen't work. If the 
>> logfiles are also interesting for you, I can send them, too. Just 
>> drop me a short mail...
>
> I think this is a known problem, but needs to be documented better. 
> And fixed.

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?

Thanks!

73
  Nico

--

EMail: nico at schmoigl-online.de
PGP-fingerprint: 5DDB 09E4 3FF3 CD09 7559  1117 9C03 46E3 38FC 9E03
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s-:-- a-- C++ UL++ P L+++ E- W++ N+ o- K- w
O- M- V- PS PE Y+ PGP++ t+ 5++ X R tv- b- DI- D
G e h-- r- y+
------END GEEK CODE BLOCK------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please note my special spam and email virus information at
http://www.schmoigl-online.de/spam/spam.html . Thank you!

Bitte beachten Sie meine speziellen Informationen zu Spam und
EMail-Viren auf der Seite
http://www.schmoigl-online.de/spam/spam.html .
Vielen Dank!

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPwk70ZwDRuM4/J4DEQKc2gCg73ROAg86gwuECwjbOu8eRxMPRasAoI9Q
IZoZSWmFmSz0Dq53f7CsReUz
=1U0h
-----END PGP SIGNATURE-----