[strongSwan] received 250000000 lifebytes, configured 0

[Dr. Rolf Jansen]

During connection attempts of a Windows 7 client by IKEv1 in transport mode, I see the following:

...
[NET] <L2TP/IPsec-PSK|1> received packet: from Y.Y.Y.Y[4500] to X.X.X.X[4500] (284 bytes)
[ENC] <L2TP/IPsec-PSK|1> parsed QUICK_MODE request 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
[IKE] <L2TP/IPsec-PSK|1> received 250000000 lifebytes, configured 0
[ENC] <L2TP/IPsec-PSK|1> generating QUICK_MODE response 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
...

It takes about 1 or 2 seconds up to the 250 Million lifebytes message. Doesn't sound quite reasonable, 1-2 GiBit/s over a 100 Mbit line, does it?

Does "configured 0" mean that all these lifebytes were useless?


A same connection attempt using Mac OS X gives in this phase:

[NET] <L2TP/IPsec-PSK|1> received packet: from Y.Y.Y.Y[4500] to X.X.X.X[4500] (316 bytes)
[ENC] <L2TP/IPsec-PSK|1> parsed QUICK_MODE request 2983414279 [ HASH SA No ID ID NAT-OA NAT-OA ]
[ENC] <L2TP/IPsec-PSK|1> generating QUICK_MODE response 2983414279 [ HASH SA No ID ID NAT-OA NAT-OA ]

The Mac doesn't seem to send any useless lifebytes, and this turns out to work much better.


Is it possible to teach Windows 7 somehow to send its useless lifebytes to somewhere else, or perhaps send at least 1 useful lifebyte and let charon dump only 2499999999 useless bytes?

Best regards

Rolf

[Martin Willi]

Hi Rolf,

Post by Dr. Rolf Jansen
[IKE] <L2TP/IPsec-PSK|1> received 250000000 lifebytes, configured 0

These lifebytes refer to the number of bytes the peer allows over this
Quick Mode before it expires, as sent in its proposal. It allows 250MB
of data, and usually should create a new Quick Mode before the old one
expires.

strongSwan prints this line because it does not match to what you have
configured, i.e. no volume limit. We currently don't enforce such
received lifetimes, but only those configured.

Regards
Martin

[Dr. Rolf Jansen]

Post by Martin Willi

Post by Dr. Rolf Jansen
[IKE] <L2TP/IPsec-PSK|1> received 250000000 lifebytes, configured 0

These lifebytes refer to the number of bytes the peer allows over this
Quick Mode before it expires, as sent in its proposal. It allows 250MB
of data, and usually should create a new Quick Mode before the old one
expires.

Many thnak for the explanation, next time my brain will auto-translate the message to:

peer proposed 250000000 for the lifebytes parameter, configured was 0 (no limit)


Anyway, in the logs this were the most apparent difference between a working L2TP/IPsec-PSK connection initiated by Mac OS X, and a non-working initiated by Windows 7. Another difference is, that the serial number, or ID, or whatever of the QUICK_MODE requests/responses which are exchanged in the same phase as the negotiation of the lifebytes parameter, seems to be a uint32_t random number in the case of Mac OS X, while this is always 1 in the case of Windows 7.

Both, Windows 7 and Mac OS X succeed with the IPsec connection. Windows 7 is stale then, while Mac OS X enters happily into the L2TP negotiation. (one connection at a time, no multiple conn's).

Well, I have Windows 7 working with IKEv2 (machine certificates) now. This was my last attempt on IKEv1/transport mode and Windows. For me it is very clear now that Microsoft never got this straight. This is reminding me to: "When you discover that you are riding a dead horse, the best strategy is to dismount."

Best regards

Rolf