VPN im WLAN der Bahn

Die Bahn bietet in den ICE Strecken Internetzugang über das WLAN WIFIONICE. Über die Qualität des Zugangs wurde an anderer Stelle schon genug gesagt. Hier will ich über ein Problem beim Aufbau eines IPsec VPN, dessen Ursache und die Lösung berichten.

Problem

Wir haben auf auf unserer Firewall einen neuen VPN Zugang eingerichtet. Die Kollegen wollten OpenVPN und ich selbst nutze IPsec. Unsere Firewall bietet beides an.

Beides funktioniert auch gut, wenn ich von zu Hause oder mit meinem mobilen Telefon arbeite. Nur bei Reisen mit der Deutschen Bahn hatte ich Probleme das IPsec VPN aufzubauen. Letzte Woche war ich mal wieder unterwegs und beschloss dem Problem auf den Grund zu gehen.

Hintergrund: Wir nutzen strongSwan auf beiden Seiten, also auf unserer Firewall als auch auf den Endgeräten. Wir nutzen ausschließlich IKEv2.

Ursache

Nach dem alten Grundsatz "The truth is in the logs" habe ich die Log Einträge auf beiden Seiten genauer angesehen. Verkürzt steht folgendes in den Dateien:

client charon: 15[IKE] initiating IKE_SA sys4[3] to server
client charon: 15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
client charon: 15[NET] sending packet: from client[500] to server[500] (1428 bytes)

Der Server erhält dieses Paket und macht sich an die Verarbeitung:

server charon: 06[NET] <702> received packet: from client[21604] to server[500] (1428 bytes)
server charon: 06[ENC] <702> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
server charon: 06[IKE] <702> client is initiating an IKE_SA
server charon: 06[IKE] <702> local host is behind NAT, sending keep alives
server charon: 06[IKE] <702> remote host is behind NAT
server charon: 06[IKE] <702> sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"

Dieses Paket geht beim Client ein, der es beantwortet:

client charon: 05[NET] received packet: from server[500] to client[500] (609 bytes)
client charon: 05[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(HASH_ALG) N(MULT_AUTH) ]
client charon: 05[IKE] local host is behind NAT, sending keep alives
client charon: 05[IKE] remote host is behind NAT
client charon: 05[IKE] received cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
(...)
client charon: 05[IKE] sending cert request for "C=DE, ST=BY, L=Munich, O=sys4 AG, E=user@sys4.de, CN=sys4CA"
cleint charon: 05[IKE] establishing CHILD_SA sys4
client charon: 05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr CPRQ(ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
client charon: 05[NET] sending packet: from client[4500] to server[4500] (448 bytes)

Derver Server empfängt dieses er beantwortet es ordnungsgemäß:

server charon: 06[NET] <702> received packet: from client[17533] to server[4500] (448 bytes)
server charon: 06[ENC] <702> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr CPRQ(ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
server charon: 06[IKE] <702> received cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
server charon: 06[CFG] <702> looking for peer configs matching server[server]...client[user@sys4.de]
server charon: 06[CFG] <con2|702> selected peer config 'con2'
server charon: 06[IKE] <con2|702> initiating EAP_IDENTITY method (id 0x00)
server charon: 06[IKE] <con2|702> authentication of 'server' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful
server charon: 06[IKE] <con2|702> sending end entity cert "CN=server"
server charon: 06[ENC] <con2|702> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
server charon: 06[NET] <con2|702> sending packet: from server[4500] to client[17533] (2432 bytes)

Dieses Paket erreicht den Client nie. Der Client versucht verzweifelt noch zwei Mal Kontakt zum Server aufzunehmen aber scheitert immer daran, dass er keine IKE_AUTH Antwort erhält.

client charon: 10[IKE] retransmit 1 of request with message ID 1
client charon: 10[NET] sending packet: from client[4500] to server[4500] (448 bytes)
(...)
client charon: 12[IKE] retransmit 2 of request with message ID 1
client charon: 12[NET] sending packet: from client[4500] to server[4500] (448 bytes)

Schließlich geben beide mit einem timeout Fehler auf.

Dieses Verhalten hat mich zuerst verwirrt. Sollte der Dienstleister der Bahn gezielt Pakete zum Aufbau des VPN verwerfen?

Lösung

Aber die Lösung war viel einfacher. In der letzten Logzeile des Servers steht schon die Ursache. Weil der Server für die Authentifizieriung die ganze Zertifikatskette mitschickt ist das Paket 2432 Byte groß. Und das geht natürlich nicht über das Transportnetzwerk. Die Bahn gibt auf diversen Webseiten eine MTU von 1300 bis 1350 Byte an, so dass unterwegs nicht fragmentiert werden muss.

Schöner ist natürlich, wenn das Protokoll selbst die Alternative zur Fragmentierung beinhaltet. StrongSwan bietet genau das an, so dass die Option

fragmentation=yes

im passenden conn Abschnitt Wunder wirkt. Die Kommunikation läuft nun wie unten dargestellt. Ich zeige nur noch die wichtigen Änderungen im Log.

client charon: 17[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]

Wichtig ist hier die Option N(FRAG_SUP) beim ersten IKE Paket. Der Server zerlegt darauf hin die IKE_AUTH Antwort:

server charon: 09[IKE] <con2|730> sending end entity cert "CN=server"
server charon: 09[ENC] <con2|730> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
server charon: 09[ENC] <con2|730> splitting IKE message with length of 2432 bytes into 3 fragments
server charon: 09[ENC] <con2|730> generating IKE_AUTH response 1 [ EF(1/3) ]
server charon: 09[ENC] <con2|730> generating IKE_AUTH response 1 [ EF(2/3) ]
server charon: 09[ENC] <con2|730> generating IKE_AUTH response 1 [ EF(3/3) ]
server charon: 09[NET] <con2|730> sending packet: from server[4500] to client[36376] (1236 bytes)
server charon: 09[NET] <con2|730> sending packet: from server[4500] to client[36376] (1236 bytes)
server charon: 09[NET] <con2|730> sending packet: from server[4500] to client[36376] (116 bytes)

Der Rest der Einträge zeigt den erfolgreichen Verbindungsaufbau.

Michael Schwartzkopff, 21. January 2019