Beta-Test LCOS/LCMS 10.00
Moderator: Lancom-Systems Moderatoren
Re: Beta-Test LCOS/LCMS 10.00
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
Die Clients können sich nicht mehr registrieren.
Fallback auf LCOS 10.00/Build 0101 funktioniert alles wieder normal.
Beste Grüße
Dirk
Re: Beta-Test LCOS/LCMS 10.00
Danke fuers Feedback Dirk. Ich konnte das auch mit der aktuellen Build 0105 nachstellen.
Ciao
LoUiS
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.
Re: Beta-Test LCOS/LCMS 10.00
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!
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!
Re: Beta-Test LCOS/LCMS 10.00
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.
Re: Beta-Test LCOS/LCMS 10.00
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
Eine Anbindung nur über VPN zuzulassen ist in vielen Szenarien sinnfrei...
Grüße
Cpuprofi
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
Eine Anbindung nur über VPN zuzulassen ist in vielen Szenarien sinnfrei...
Grüße
Cpuprofi
Re: Beta-Test LCOS/LCMS 10.00
> 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!
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!
Re: Beta-Test LCOS/LCMS 10.00
Hallo beki,
erstmal Danke für Deine Antwort.
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!
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!) ?
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!
Weiter kann der Lancom VCM ja TLS und SRTP, warum dann noch per VPN verschlüsseln? In meinen Augen ist dieses ziemlich sinnfrei...
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
erstmal Danke für Deine Antwort.
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#p84288beki 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...
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!
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!) ?
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!
Das ist sehr schade zu hören...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...
Du meinst damit diese "Experten" http://www.badische-zeitung.de/freiburg ... 04756.htmlbeki hat geschrieben:...Ein solcher Angriff könnte leicht länger unbeobachtet bleiben und auch LANCOM-Experten waren schon Opfer...
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?beki hat geschrieben:...Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
Weiter kann der Lancom VCM ja TLS und SRTP, warum dann noch per VPN verschlüsseln? In meinen Augen ist dieses ziemlich sinnfrei...
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
Re: Beta-Test LCOS/LCMS 10.00
Hallo Cpuprofi,
Hallo beki,
Viele Grüße,
Jirka
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.cpuprofi hat geschrieben:Das Problem dabei ist, dass jede zusätzliche App mehr Strom aus dem Akku verbraucht...
Hallo beki,
über WLAN. Oder auch über Mobilfunk?beki hat geschrieben:Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
Viele Grüße,
Jirka
Re: Beta-Test LCOS/LCMS 10.00
Hallo beki, hallo zusammen,
Kann mir jemand helfen?
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
schön. Bei mir leider nicht. Ich kriege es zum verrecken nicht hin, auch nach 3 Stunden nichtbeki hat geschrieben:Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!
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
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
-
- Beiträge: 2893
- Registriert: 12 Jan 2010, 14:10
Re: Beta-Test LCOS/LCMS 10.00
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
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
Re: Beta-Test LCOS/LCMS 10.00
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:
Vielen Dank und viele Grüße,
Jirka
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
Jirka
Re: Beta-Test LCOS/LCMS 10.00
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
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
-
- Beiträge: 2893
- Registriert: 12 Jan 2010, 14:10
Re: Beta-Test LCOS/LCMS 10.00
Hey Jirka,
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
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
Gruß Dr.Einstein
Re: Beta-Test LCOS/LCMS 10.00
Hallo Dr. Einstein,
danke für Deine Antwort.
Liegt das Problem nicht an folgender Stelle:?
Vielen Dank und viele Grüße,
Jirka
danke für Deine Antwort.
Das ist im LCOS eigentlich (defaultmäßig) so eingestellt.Dr.Einstein hat geschrieben:Mit DH 5 und 14 solltest du Erfolg haben.
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
...
Deswegen ist die Stelle, die ich hier eben angegeben habe, also dann wohl soweit in Ordnung. Hmm.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.
Das könnte sein. Das wäre blöd, oder?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 was ich oben angegeben hatte (die beiden Tracepakete) wiederholen sich ca. 10 Mal. Dann hört das Handy auf zu versuchen.Dr.Einstein hat geschrieben:Man müsste jetzt den weiteren Verlauf der IKE Nachrichten durchforsten.
Vielen Dank und viele Grüße,
Jirka
-
- Beiträge: 2893
- Registriert: 12 Jan 2010, 14:10
Re: Beta-Test LCOS/LCMS 10.00
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
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