Beta-Test LCOS/LCMS 10.00

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

DirkK
Beiträge: 555
Registriert: 13 Jun 2005, 15:49

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von DirkK »

LCOS 10.00/Build 0104 SIP über TLS geht nicht mehr.
Die Clients können sich nicht mehr registrieren.
Fallback auf LCOS 10.00/Build 0101 funktioniert alles wieder normal.

Beste Grüße
Dirk
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5031
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von LoUiS »

Danke fuers Feedback Dirk. Ich konnte das auch mit der aktuellen Build 0105 nachstellen.


Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von beki »

Hallo Dirk! Das von dir beschriebene Problem hat seine Ursache in der Beseitigung einer Race-Condition. Dabei ist ein Programmierfehler unterlaufen, der die TCP und TLS Funktionalität für SIP Clients unbrauchbar machte.

Der Fehler wurde verstanden und behoben, die Anmeldung eines SIP Users per TCP/TLS ist ab LCOS 10.00.0106 wieder möglich. Danke für Deinen Hinweis!
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5031
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von LoUiS »

Die Build 0106 liegt nun auf dem FTP Server.
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von cpuprofi »

Hallo beki, hallo LoUiS,

da nun TCP und TLS für SIP-Clients wieder geht, wäre es super, wenn man diese auch wieder per WAN anbinden könnte :wink:

Eine Anbindung nur über VPN zuzulassen ist in vielen Szenarien sinnfrei... :shock:

Grüße
Cpuprofi
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von beki »

> wenn man diese auch wieder per WAN anbinden könnte
Das kann ich gut verstehen.

Ein Angreifer kann bei unvorsichtigen Kunden (unzureichendes Passwort zum Beispiel) durch ungewollte Anrufe hohe Kosten verursachen. Im Gegensatz zu den Menschen welche SIP über WAN vermissen, hätten diese unvorsichtigen Kunden einen (schnell sehr hoch werdenden) finanziellen Schaden erlitten, der schwerer wiegt als der Wunsch einzelner Kunden nach SIP über WAN.

Für die Umbauten in LCOS 10.00 wurde zwecks Vereinfachung angenommen, dass SIP über WAN nicht wiederkommen wird. Insofern manifestiert es sich dass dein Wunsch nicht erfüllt werden kann um unserem Claim "Sicher. Vernetzt." gerecht zu werden.

Ein solcher Angriff könnte leicht länger unbeobachtet bleiben und auch LANCOM-Experten waren schon Opfer. Lieber die Türe geschlossen lassen!

Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von cpuprofi »

Hallo beki,

erstmal Danke für Deine Antwort.
beki hat geschrieben:...Ein Angreifer kann bei unvorsichtigen Kunden (unzureichendes Passwort zum Beispiel) durch ungewollte Anrufe hohe Kosten verursachen. Im Gegensatz zu den Menschen welche SIP über WAN vermissen, hätten diese unvorsichtigen Kunden einen (schnell sehr hoch werdenden) finanziellen Schaden erlitten, der schwerer wiegt als der Wunsch einzelner Kunden nach SIP über WAN...
Erstens: Für die Dummheit anderer Leute hat sich Lancom nicht zu verantworten und auch Lancom's "Angst ums Image" ist unbegründet. Siehe auch: http://www.lancom-forum.de/post84288.ht ... age#p84288

Zweitens: Wenn Lancom den "dummen Anwender" oder auch den "dummen Administrator" vor sich selber schützen möchte, dann wäre dieses "viel einfacher" über passende (sichere) "Zwangspasswortlängen mit Buchstaben/Zahlen/Sonderzeichen" möglich! :roll:

Außerdem, wenn man dieses "weiterdenkt", dann dürfte Lancom auch keinen Administrations-Zugang von WAN-Seite zulassen! Dieses wird aber selbstverständlich gemacht und zwar "schaltbar" (Nicht erlaubt, erlaubt, Nur über VPN). Warum dieses auch nicht so bei den SIP-Clients handhaben (war ja alles schon mal so da!) ? :G)

Drittens: Selbst AVM, wo die Fritz!Boxen ja wirklich schon "gehackt" wurden und dann hohe Kosten durch Telefonmissbrauch entstanden sind, hat den WAN Zugang für SIP-Clients beibehalten!
beki hat geschrieben:...Für die Umbauten in LCOS 10.00 wurde zwecks Vereinfachung angenommen, dass SIP über WAN nicht wiederkommen wird. Insofern manifestiert es sich dass dein Wunsch nicht erfüllt werden kann um unserem Claim "Sicher. Vernetzt." gerecht zu werden...
Das ist sehr schade zu hören... :cry:
beki hat geschrieben:...Ein solcher Angriff könnte leicht länger unbeobachtet bleiben und auch LANCOM-Experten waren schon Opfer...
Du meinst damit diese "Experten" :I) http://www.badische-zeitung.de/freiburg ... 04756.html
beki hat geschrieben:...Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
Das Problem dabei ist, dass jede zusätzliche App mehr Strom aus dem Akku verbraucht (und die Akku-Kapazität reich heute schon so nicht für den ganzen Tag aus) . Und umso mehr noch, wenn durch die Ver-und Entschlüsselung bei VPN der Prozessor zusätzlich belastet wird! Außerdem nutzen die meisten Kunden die NCP-VPN-App und diese auch nur bei Bedarf und nicht dauerhaft... Hat Lancom dieses auch mit bedacht? :|

Weiter kann der Lancom VCM ja TLS und SRTP, warum dann noch per VPN verschlüsseln? In meinen Augen ist dieses ziemlich sinnfrei... :G)

Ich sehe es so, dass die Vorteile einer WAN-Anbindung für SIP-Clients die eventuell möglichen Nachteile überwiegen!


Nachtrag: Nicht das dieses hier falsch verstanden wird, ich prangere hier die "Politik von Lancom" an und nicht Dich! Ich finde es sogar sehr gut, dass Du den VCM mal auf "Vordermann" bringst und Deine Kommentare beweisen Deinen Sachverstand.

Grüße
Cpuprofi
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Jirka »

Hallo Cpuprofi,
cpuprofi hat geschrieben:Das Problem dabei ist, dass jede zusätzliche App mehr Strom aus dem Akku verbraucht...
vergiss nicht, dass es nach wie vor Regionen auf der Erde gibt, wo auch der zusätzliche Bandbreitenbedarf durch die VPN-Header ein Problem darstellen könnte. Aus Deinem letzten Urlaub hattest Du glaube ich hier über derartige Probleme berichtet.

Hallo beki,
beki hat geschrieben:Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
über WLAN. Oder auch über Mobilfunk?

Viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Jirka »

Hallo beki, hallo zusammen,
beki hat geschrieben:Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
schön. Bei mir leider nicht. Ich kriege es zum verrecken nicht hin, auch nach 3 Stunden nicht :(

Kann mir jemand helfen?

Code: Alles auswählen

[VPN-Status] 2017/02/17 01:21:17,950
IKE info: save_g_x not o.k.


[VPN-Status] 2017/02/17 01:21:17,950
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 652 bytes
Gateways: 31.16.170.140:500<--80.187.96.208:500
SPIs: 0x22E0E1B395129AB80000000000000000, Message-ID 0
Peer identified: DEFAULT
Received 4 notifications:
  +STATUS_NAT_DETECTION_SOURCE_IP
  +STATUS_NAT_DETECTION_DESTINATION_IP
  +SIGNATURE_HASH_ALGORITHMS
  +REDIRECT_SUPPORTED
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are not behind a NAT. NAT-T is already enabled
+IKE_SA:
  Proposal 1  Protocol IPSEC_IKE
    ENCR : AES_CBC-256
    PRF  : PRF-HMAC-SHA-512
    INTEG: SHA-512
    DH   : 14
-KE Payload's group 24 does not fit to the negotiated group type 14 => Sending INVALID_KE_PAYLOAD(14)

[VPN-Status] 2017/02/17 01:21:17,950
Peer DEFAULT: Constructing an IKE_SA_INIT-REPLY  for send
NOTIFY(INVALID_KE_PAYLOAD[14])
Sending an IKE_SA_INIT-RESPONSE of 38 bytes
Gateways: 31.16.170.140:500-->80.187.96.208:500
SPIs: 0x22E0E1B395129AB80000000000000000, Message-ID 0
1. Frage: Was bedeutet IKE info: save_g_x not o.k.?
2. Frage: "-KE Payload's group 24 does not fit to the negotiated group type 14" Wer hat die 24? Das Handy oder der LANCOM? Gibt es überhaupt eine DH-Gruppe 24?! So eine hohe habe ich noch nie gesehen, kenne nur bis 18. Wie kriege ich die 24 weg?

Vielen Dank und viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Dr.Einstein »

Hi Jirka,

Androids mit einer so hohen Verschlüsselung? Naja, wunder geschehen scheinbar auch noch. Also DH-24 gibt's schon länger bei Cisco, nix ungewöhnliches. Mach mal ein Trace auf vpn-ike, dort solltest du im Offerpaket vom Android die unterstützten DH-Gruppen sehen.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Jirka »

Hallo Dr. Einstein,

danke für den Hinweis. Hätte nicht gedacht, dass der Trace auch für IKEv2 ist, da kenne ich mich noch nicht so aus.
So sieht es aus:

Code: Alles auswählen

[VPN-IKE] 2017/02/17 08:15:42,547
[<UNKNOWN>] Received packet:
IKE 2.0 Header:
Source/Port         : 80.187.97.138:500
Destination/Port    : 31.16.170.140:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : C6 40 F3 84 91 D9 86 59
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x08   Initiator
| Msg-ID            : 0
| Length            : 652 Bytes
SA Payload
| Next Payload      : KE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 244 Bytes
| PROPOSAL Payload
| | Next Payload    : PROPOSAL
| | Reserved        : 0x00
| | Length          : 136 Bytes
| | Proposal number : 1
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 15
| | 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        : 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: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-512
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-384
| | | 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  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-512
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-384
| | | Attributes    : NONE
| | 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: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 24>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 20>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 19>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | 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          : 104 Bytes
| | Proposal number : 2
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 11
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_GCM_16
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_GCM_16
| | | 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-SHA-512
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-384
| | | Attributes    : NONE
| | 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: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA1
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 24>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 20>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 19>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 5
| | | Attributes    : NONE
KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 264 Bytes
| DH Group          : 24
| Reserved2         : 0x0000
| DH-Key(2048 bits) : 15 9A 73 DD 54 A2 1F 94 7E 5D EC 2A 33 4D 08 2D
|                     1E FA 76 36 00 B6 3A CC 29 07 94 27 E8 A2 38 63
|                     71 FD B4 93 4C E4 69 FF F2 68 DF 50 CF 57 16 09
|                     9B 89 20 41 D5 18 6C BA 53 5D 72 E3 99 B3 E1 7E
|                     B3 FE 65 25 B8 4F 6F AA 4C 11 05 80 51 4C A2 80
|                     2B 14 93 BD E3 48 CD E1 B3 44 03 5B 97 DA 5F 6E
|                     73 7A 93 28 64 53 59 52 DB F2 31 BD 19 5D 48 6D
|                     6C 00 2A 33 3A 39 DC 6D 2C 1A 21 23 68 D0 2A 7E
|                     31 4F A6 9D 76 A0 57 22 5C D4 DC D4 18 D5 A6 53
|                     D0 D5 CF 7D 36 6C 94 4D CA 15 A8 14 A4 CD BD 94
|                     C7 DD DA 38 76 78 7E 6E 8A A2 2C 11 23 6F FC 46
|                     F8 CA CB AE 08 66 E0 81 E7 DB AC A2 5C B0 C6 19
|                     3E EF 8C 45 EE 4D 3C 43 3E BB A3 F3 3F A6 39 71
|                     0E 2E 9D C7 D2 CD 90 C7 33 95 3D 98 0A 8C 95 95
|                     62 10 A0 02 9F 82 96 D9 BE 2F 35 0A A5 0B 02 5A
|                     D6 1D CB 19 EE 1A A0 32 00 65 66 B0 08 30 0B 77
NONCE Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 36 Bytes
| Nonce(256 bits)   : 2D C3 BA D4 9F 09 C1 5D CF 77 DF E0 8F 93 CC 78
|                     8A E7 05 5E 86 FD 40 7D BE 2F BC 54 4F 46 0D 10
NOTIFY Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 28 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : STATUS_NAT_DETECTION_SOURCE_IP
| Notif. data       : 9D 78 28 A0 A1 69 5C 12 0E 2E F7 19 E3 59 90 66
|                     BF 07 FB D5
NOTIFY Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 28 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : STATUS_NAT_DETECTION_DESTINATION_IP
| Notif. data       : 2D E2 C4 CE 70 AE 80 52 F7 0B F4 EC E5 DB 32 88
|                     E3 2E 26 F9
NOTIFY Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 16 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : SIGNATURE_HASH_ALGORITHMS
| Sign. Hash Algs.  : SHA1, SHA-256, SHA-384, SHA-512
NOTIFY Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 8 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : REDIRECT_SUPPORTED

[VPN-IKE] 2017/02/17 08:15:42,555
[DEFAULT] Sending packet:
IKE 2.0 Header:
Source/Port         : 31.16.170.140:500
Destination/Port    : 80.187.97.138:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : C6 40 F3 84 91 D9 86 59
| 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 0E
Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Jirka »

Hmm,

wenn ich mir das so anschaue, dann wird die DH-Gruppe beim KE Payload mit 24 angegeben, obwohl der Schlüssen nur 2048 bits lang ist?! Das wäre doch dann ein Fehler im Handy, oder? Es ist übrigens ein Samsung Galaxy A3 (2016) mit Android 6.0.1.

Viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Dr.Einstein »

Hey Jirka,

Code: Alles auswählen

| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 24>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 20>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : <Unknown 19>
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 14
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 5
| | | Attributes    : NONE
Mit DH 5 und 14 solltest du erfolg haben. Das Androidteil hat halt das Sicherste als Favorit und schickt direkt den Eingangsschlüssel mit. Dieser ist bei DH-24 etwas anders aufgebaut, also nicht maximale Länge, sondern Mischung aus 2048 Bits und einer Untergruppe weiterer Bits. Wenn du Pech hast, schickt das Endgerät kein neues Paket mit dem DH-14 Key, das hatte ich mal bei iPhone. Man müsste jetzt den weiteren Verlauf der IKE Nachrichten durchforsten.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Jirka »

Hallo Dr. Einstein,

danke für Deine Antwort.
Dr.Einstein hat geschrieben:Mit DH 5 und 14 solltest du Erfolg haben.
Das ist im LCOS eigentlich (defaultmäßig) so eingestellt.

Liegt das Problem nicht an folgender Stelle:?

Code: Alles auswählen

KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 264 Bytes
| DH Group          : 24
| Reserved2         : 0x0000
| DH-Key(2048 bits) : 15 9A 73 DD 54 A2 1F 94 7E 5D EC 2A 33 4D 08 2D
...
Dr.Einstein hat geschrieben:Dieser ist bei DH-24 etwas anders aufgebaut, also nicht maximale Länge, sondern Mischung aus 2048 Bits und einer Untergruppe weiterer Bits.
Deswegen ist die Stelle, die ich hier eben angegeben habe, also dann wohl soweit in Ordnung. Hmm.
Dr.Einstein hat geschrieben:Wenn du Pech hast, schickt das Endgerät kein neues Paket mit dem DH-14 Key, das hatte ich mal bei iPhone.
Das könnte sein. Das wäre blöd, oder?
Dr.Einstein hat geschrieben:Man müsste jetzt den weiteren Verlauf der IKE Nachrichten durchforsten.
Das was ich oben angegeben hatte (die beiden Tracepakete) wiederholen sich ca. 10 Mal. Dann hört das Handy auf zu versuchen.

Vielen Dank und viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: Beta-Test LCOS/LCMS 10.00

Beitrag von Dr.Einstein »

Hi Jirka,

schau dir mal meinen alten Post dazu an http://www.lancom-forum.de/post84191.html. Habe das Thema damals nicht weiter verfolgt da der Lancom die geforderte Apple Gruppe konnte. Fands nur komisch, hab aber MariusP und der RFC geglaubt ;)

Gruß Dr.Einstein
Antworten