LCOS 9.20RC1 - IKEv2 Verständnisfrage

[Dr.Einstein]

Hallo zusammen,

aufgrund von erhofften Performance Verbesserungen mache ich aktuell erste Tests mit IKEv2. Im Testszenario ist auch ein Apple iPhone/iPad dabei mit iOS9, VPN über IKEv2 mit PSK.

Wenn ich mir die Aushandlung anschaue, unterstützt der VPN Client
- AES128bit/SHA1 (beide Phasen) + DH-2, kein PFS
- AES256bit/SHA256 (beide Phasen) + DH-5, kein PFS
- 3DES/SHA1 (beide Phasen) + DH-2, kein PFS

Übermittelt wird zusätzlich ein KE Payload mit einem DH-2 Key + Nonce. Wenn ich im Lancom Router AES128bit/SHA1 (beide Phasen) + DH-2, kein PFS hinterlege, bekomme ich die VPN Verbindung problemlos zum Laufen. Jetzt will ich natürlich die sichere Variante wählen, scheinbar verträgt sich das aber nicht. Ich erhalte folgende Meldung:

Code: Alles auswählen

IKE info: save_g_x not o.k.
...
Received 4 notifications: 
  +REDIRECT_SUPPORTED
  +STATUS_NAT_DETECTION_SOURCE_IP
  +STATUS_NAT_DETECTION_DESTINATION_IP
  +IKEV2_FRAGMENTATION_SUPPORTED
  -KE Payload'S group 5 does not fit to the negotiated group type 2 => Sending INVALID_KE_PAYLOAD

In meinem Verständnis war das KE nur für den erstmaligen Verbindungsaufbau notwendig, die eigentlich konfigurierte DH-Gruppe greift für den späteren Tunnel?

Zweite Frage: Wenn ich einen IPv4 Pool für die VPN Clients konfiguriere, erhält der Client die korrekte IP, kann aber nicht mit dem LAN kommunizieren. Laut Trace kommen Pakete an der Zielstation an, aber die MAC-Adresse passt nicht für eine Rückantwort. Wenn ich statt IPv4 Pool einfach die Routing Tabelle verwende mit Bezug auf die VPN Gegenstelle, geht's sofort. ProxyARP ist logischerweise durchgängig an.

Ideen? Vielen Dank

Ansonsten fehlt mir unter status/vpn/ike die Versionsnummer von IKE als Spalte. Steht zwar bei Connections, aber bei IKE passt es vermutlich auch rein?

Gruß Dr.Einstein

[MariusP]

Hi,

Ansonsten fehlt mir unter status/vpn/ike die Versionsnummer von IKE als Spalte. Steht zwar bei Connections, aber bei IKE passt es vermutlich auch rein?

Interessante Frage. Eine Gegenfrage, zu nachhorchen: Worin würdest du den Vorteil einer doppelten Hinterlegung der verwendeten IKE-Version sehen? Der Vollständigkeits halber?
Interessant ist die Frage auch: Braucht man die Anzeige wenn es zwar zu einer IKE_SA gekommen ist aber noch zu keiner CHILD_SA und daher kein Eintrag unter Connections hinterlegt wäre?

Übermittelt wird zusätzlich ein KE Payload mit einem DH-2 Key + Nonce. Wenn ich im Lancom Router AES128bit/SHA1 (beide Phasen) + DH-2, kein PFS hinterlege, bekomme ich die VPN Verbindung problemlos zum Laufen. Jetzt will ich natürlich die sichere Variante wählen, scheinbar verträgt sich das aber nicht. Ich erhalte folgende Meldung:

Ich bin mir nicht sicher inwiefern das IPad PFS unterstützt.

Jetzt will ich natürlich die sichere Variante wählen, scheinbar verträgt sich das aber nicht.

Meinst du mit sicher PFS oder die höheren AES/SHA Algorithmen?
Bitte poste dein IKEv2/Encryption.

In meinem Verständnis war das KE nur für den erstmaligen Verbindungsaufbau notwendig, die eigentlich konfigurierte DH-Gruppe greift für den späteren Tunnel?

Hier würde uns ein IKE-Trace in helfen um somit die eingehenden Pakete und die ausgehende Pakete zu sehen.

Zu deinen anderen Frage muss ich mich erstmal umhören da ich mit Config und Radius Featuren selber wenig zu tun hatte.

aber die MAC-Adresse passt nicht für eine Rückantwort

Steht das im IP-R-Trace?

Gruß

[Dr.Einstein]

Hallo MariusP,

danke für deine Antwort, viele Fragen...

Interessante Frage. Eine Gegenfrage, zu nachhorchen: Worin würdest du den Vorteil einer doppelten Hinterlegung der verwendeten IKE-Version sehen? Der Vollständigkeits halber?

Ja, nur zur Vollständigkeit, mehr nicht. War nur so ne Frage nebenbei.

Meinst du mit sicher PFS oder die höheren AES/SHA Algorithmen?

PFS unterstützt das iOS nicht, ich meinte das höhere AES/SHA. Dient mir auch zum Verständnis von IKEv2.

Bitte poste dein IKEv2/Encryption.

root@LANCOM-1781EF+:/Setup/VPN/IKEv2/Encryption/IPHONE
> dir

Code: Alles auswählen

Name                     INFO:    IPHONE
DH-Groups                VALUE:   DH2
PFS                      VALUE:   No
IKE-SA-Cipher-List       VALUE:   AES-CBC-128
IKE-SA-Integ-Alg-List    VALUE:   SHA1
Child-SA-Cipher-List     VALUE:   AES-CBC-128
Child-SA-Integ-Alg-List  VALUE:   SHA1

-> als Default ausgewählt, läuft

Code: Alles auswählen

root@LANCOM-1781EF+:/Setup/VPN/IKEv2/Encryption/IPHONE
> dir

Name                     INFO:    IPHONE
DH-Groups                VALUE:   DH5
PFS                      VALUE:   No
IKE-SA-Cipher-List       VALUE:   AES-CBC-256
IKE-SA-Integ-Alg-List    VALUE:   SHA-256
Child-SA-Cipher-List     VALUE:   AES-CBC-256
Child-SA-Integ-Alg-List  VALUE:   SHA-256

-> läuft nicht, siehe Meldung 1. Post.

Aushandlungsvorschläge iPhone (Lob an Lancom für die tollen Tracemöglichkeiten):

Code: Alles auswählen

| PROPOSAL Payload
| | Next Payload    : PROPOSAL
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 1
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 128
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 2
| | | Attributes    : NONE
| PROPOSAL Payload
| | Next Payload    : PROPOSAL
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 2
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-256
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-256
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 5
| | | Attributes    : NONE
| PROPOSAL Payload
| | Next Payload    : NONE
| | Reserved        : 0x00
| | Length          : 40 Bytes
| | Proposal number : 3
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : 3DES
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 2
| | | Attributes    : NONE
KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 136 Bytes
| DH Group          : 2
| Reserved2         : 0x0000
| DH-Key(1024 bits) : ... Key ...

Steht das im IP-R-Trace?

Im IP-Routertrace sieht man ja bekanntlich keine MAC-Adressen. In diesem Trace sehe ich aber zumindest das Quellpaket + Zielpaket ins LAN auskoppelnd. Wireshark mit der falschen MAC-Adresse muss ich noch erstellen, dass geht jetzt nicht ad hoc.

Vielen Dank soweit.

Gruß Dr.Einstein

P.S. iPhone / Windows mittels IKEv2 Radius/ EAP bekomme ich noch nicht hin siehe Koppelfelds Thread

[findler]

PFS unterstützt das iOS nicht,

Wie man VPN auf iOS und OSX konfiguriert siehe hier: https://help.apple.com/deployment/ios/#/ior9f7b5ff26

[Dr.Einstein]

Hallo MariusP,

aber die MAC-Adresse passt nicht für eine Rückantwort

Steht das im IP-R-Trace?

Hm, wenn ich jetzt im Netzwerk mitschneide, fragen Geräte im Netzwerk nach der VPN Client IP-Adresse via ARP, keine Reaktion vom Lancom. Wenn ich jetzt genau die gleiche IP vom Pool in die Routing Tabelle kopieren, antwortet der Lancom auf die ARP Request sofort mit seiner MAC, Kommunikation kommt zustande.

@findler: Danke für den Link, aber irgendwie hilft der mir nicht weiter. Steht zwar vieles schön da, aber auch immer nur so halbherzig.

Gruß Dr.Einstein

[MariusP]

Hi,

Lob an Lancom für die tollen Tracemöglichkeiten

Danke, Wird weitergegeben.

PFS unterstützt das iOS nicht, ich meinte das höhere AES/SHA. Dient mir auch zum Verständnis von IKEv2.

IKEv2 bietet dir ja auch die Möglichkeit der Auswahl, du kannst also auch AES 128 und AES 256 gleichzeitig anbieten und die Gegenseite sucht sich sich dann einen aus.
Wenn du ein "set ?" in der Tabelle eingibst siehst du das die Tabelle eine Bitmaske ist, somit kannst du alle Algorithmen die du unterstützen und anbieten möchtest dort hinterlegen.
Dabei kannst du sowohl mit Zahlen als auch mit den Texten arbeiten.
Dies ist ein Vorteil von IKEv2 da man nichtmehr die Kombination in je ein eigenes Proposal packen muss um diese dann alle zu übermitteln. IKEv2 würde sogar auch die Möglichkeit dazubieten mehrere Vorschlagslisten zu "proposen", allerdings hätte dies das Menu weiter komplizierter gemacht und der Nutzen wäre doch sehr gering gewesen. (Ziel des IKEv2 Menu war es simpler zu gestalten und mit den Defaulteinträgen ein hohes Maß an Easy-to-Setup zu bieten.)
Lesematerial: http://tools.ietf.org/html/rfc5996#section-3.3

Code: Alles auswählen

Name                     INFO:    IPHONE
DH-Groups                VALUE:   DH2, DH5
PFS                      VALUE:   No
IKE-SA-Cipher-List       VALUE:   AES-CBC-128, AES-CBC-256
IKE-SA-Integ-Alg-List    VALUE:   SHA1, SHA-256
Child-SA-Cipher-List     VALUE:   AES-CBC-128, AES-CBC-256
Child-SA-Integ-Alg-List  VALUE:   SHA1, SHA-256

Du kannst natürlich wenn du dich nicht mit DH2 zufrieden geben möchtest es weglassen, dann sollte nurnoch 256er Paar greifen.
Das IPad scheint sogar die Proposals einzeln zusammenzubauen. Also spielt es ein "Entweder Oder" und kein "Sowohl als Auch".
In IKEv2 um den Aufbau zu beschleunigen wird direkt im dem ersten Paket auch schon ein KE in Form eines DHs mitgesendet. Sollte dann die gegenstelle nicht das wie in diesem Fall DH2 verhandeln wollen antwortet es mit seinem gewünschten DH5 und der Aufbauer schickt nochmal ein neues KE diesmal mit DH5.
Somit können im optimalen Fall, sprich beide wollen das selbe DH, 2 Pakete gespart werden.
Leider hast du nur den IKE-Traces des IPad gepostet und nicht die Antwort des Lancoms und die erneute Antwort des IPads. Daher muss ich atm ein bissel raten.

Gruß

[Dr.Einstein]

Hi,

ok, dass mit dem "vorschicken" war mir noch nicht bekannt.

Code: Alles auswählen

[VPN-IKE] 2016/03/16 13:09:14,960  Devicetime: 2016/03/16 13:09:15,541
Sending packet:
IKE 2.0 Header:
Source/Port         : x.y.z.q:500
Destination/Port    : z.x.y.q:500
VLAN-ID             : 0
HW switch port      : 2
Routing-tag         : 0
Com-channel         : 2147483648
Loopback            : NO
| Initiator cookie  : A0 0C 5F 65 69 C9 .. ..
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : NOTIFY
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x20 Response  
| Msg-ID            : 0
| Length            : 38 Bytes
NOTIFY Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 10 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : INVALID_KE_PAYLOAD
| Notif. data       : 00 05

bedeutet unten die Notif. data : 00 05 -> schick mir bitte Gruppe 5 DH KE?

Das iPhone antwortet wieder mit dem Paket, was ich schon geschickt habe, also beide Vorschläge, wieder DH2 KE. Debuglog am iPhone wird länger dauern, falls die Baustelle da liegen sollte?

Das mit mehrere Prop Zusammenstellungen hat ich vor den Tests schon gemacht, und dabei ist mir der Fallback auf die schlechteren Ency's aufgefallen. Nun wollte ich halt das iPhone zu seinem Glück zwingen.

Gruß Dr.Einstein

[MariusP]

Hi,

ok, dass mit dem "vorschicken" war mir noch nicht bekannt.

bedeutet unten die Notif. data : 00 05 -> schick mir bitte Gruppe 5 DH KE?

Code: Alles auswählen

Because the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups.  If the
initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group.  The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could
trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer.

http://tools.ietf.org/html/rfc7296#section-1.2
Ich kann dir nur wärmsten empfehlen den RFC durchzulesen. Er ist btw auch die aktuellste Revision von IKEv2. Der 5996 ist etwas älter. Alle Änderungen kann man http://tools.ietf.org/html/rfc7296#section-1.7 hier nachlesen wenn man einen "alten" IKEv2-RFC gelesen hat.
Gruß

[Dr.Einstein]

Danke, wenn die Zeit da ist, müsste ich mir mal alle x000 RFCs durchlesen bei all den offenen Baustellen

Hatte vorhin selbst die RFC überflogen, sogar in dem Teil, aber scheinbar genau das Feld überlesen -.- Sorry

Hast du eine Idee für das Routing / Pool Thema, was ich ebenfalls angesprochen hatte?

Gruß Dr.Einstein

[MariusP]

Hi,

Hast du eine Idee für das Routing / Pool Thema, was ich ebenfalls angesprochen hatte?

Zu deinen anderen Frage muss ich mich erstmal umhören da ich mit Config und Radius Featuren selber wenig zu tun hatte.

Ich werde wie gesagt mich informieren wie man die Informationen die du benötigst am besten an die User bringst.

P.S. iPhone / Windows mittels IKEv2 Radius/ EAP bekomme ich noch nicht hin siehe Koppelfelds Thread

LCOS kann noch kein EAP auf IKEv2 Ebene.
Gruß

[Dr.Einstein]

Mit dem Radius hat sich erledigt, da gibt es extra ein KB Artikel für.

Der IP Pool vs. IP-Routingtabelle ist dann noch Baustelle, Iphone Log kommt später.

Gruß Dr.Einstein

[MariusP]

Hi,
Und da wollte ich ihn gerade posten.^^
Da du keinen Link gepostet hast:
https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument
Dazu gibst noch einen für ein allgemeines IKEv2-Site2Site:
https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument
Und noch einen für den VPN Client und IKEv2:
https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument
Gruß

[GrandDixence]

aufgrund von erhofften Performance Verbesserungen mache ich aktuell erste Tests mit IKEv2.

Beim Einsatz von IKEv2 statt IKEv1 ist keine Performance-Verbesserung zu erwarten. Da die Aushandlung des symmetrischen Verschlüsselungsschlüssels und die Identifizierung des Kommunikationspartner Aufgabe von IKE ist, kann einzig ein um mehrere Mikrosekunden schnellerer VPN-Tunnelaufbau beim Einsatz von IKEv2 erwartet werden. Dies wird auch in der Feature Notes zu LCOS v9.20 so beschrieben.

Die Verschlüsselung des Datenstroms wird durch IPSec abgewickelt. Beim Einsatz von IPSec kommt üblicherweise die symmetrische AES-Verschlüsselung zum Einsatz. Die AES-Verschlüsselung und AES-Entschlüsselung wird bei LANCOM 1781-Geräten ziemlich sicher in speziellen Hardwarekreisen des Freescale-Prozessors abgewickelt.

Die Fehlermeldung ist ziemlich eindeutig. Das iOS9-Gerät unterstützt keine Diffie Hellmann-Schlüsselaushandlung mit einer "Schlüssellänge" > 1024 Bit (DH-Gruppe > 2). Generell sei auf die Technische Richtlinie TR-02102-3 vom BSI verwiesen:

https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

welche aus Sicherheitsgründen den Einsatz von DH-Gruppe > 13 empfiehlt.

[GrandDixence]

Hier noch einige Informationen zum Apple iOS 9 IKEv2 DH-Gruppe > 2-Problem:

https://forum.pfsense.org/index.php?topic=100948.0

https://wiki.strongswan.org/projects/st ... 28Apple%29

Ist also wieder einmal ein Apple-Problem und kein LANCOM-Problem...

[findler]

Mit iOS9.2.1 & Mac OSX El Capitan klappt (richtig konfiguriert) der Verbindungsaufbau mit IKEv2 gegen Lancom ohne Fehler.
Getestet mit AES-256, SHA-256, DH14, PFS und Zertifikat Auth.