Beta-Test LCOS/LCMS 10.00

[beki]

Hallo Jirka,

Ich kriege es zum verrecken nicht hin, auch nach 3 Stunden nicht

I hear you! Ich hab nicht erwähnt, dass die Einrichtung, bis es dann funktioniert, lästig werden kann -- sorry. Falls es dich tröstet, ich hab länger als 3h gebraucht um ein Setup zu finden, das so funktioniert wie ich es mir gewünscht habe.

Kann ich dich für die Android App Strongswan begeistern? Ein Vorteil diese App zu nutzen wäre sicherlicht die Portabilität. Denn IKEv2 Untestützung ist nur deshalb in deinem Handy drin, weil Samsung sie noch dazugebastelt hat. Nativ fehlt eine Implementierung (zumindest bis v6, weiß nicht ob sich das inzwischen doch noch geändert hat).

Mit der strongswan App ist das Setup sehr einfach. Du musst lediglich darauf achten, dass der CN (common name) des VPN-Server-Zertifikats dem Hostnamen entspricht mit dem du dich zum Server verbindest,

und dass dieser Hostname auch als DNS alternative Name im Zertifikat steht

Generierst du deine Zertifikate im LCOS über die WebApp? So sieht das aus wie im Anhang certificate.png.

Dies könnte die passende Konfiguration im LCOS sein:

Code: Alles auswählen

add /Setup/VPN/IKEv2/Peers/"PHONE" {Active} Yes {SH-Time} 0 {Remote-Gateway} "0.0.0.0" {Rtg-tag} 0 {Encryption} "STRONGSWAN_DROID" {Authentication} "PHONE" {General} "DEFAULT" {Lifetimes} "DEFAULT" {IKE-CFG} Server {IPv4-CFG-Pool} "PHONE" {IPv6-CFG-Pool} "" {Rule-creation} manually {IPv4-Rules} "PHONE-RULE" {IPv6-Rules} "" {Routing} "" {RADIUS-Authorization} "" {RADIUS-Accounting} "" {Comment} "strongSwan on smartphone"

add /Setup/VPN/IKEv2/Encryption/"STRONGSWAN_DROID" {DH-Groups} DH16 {PFS} Yes {IKE-SA-Cipher-List} AES-CBC-256 {IKE-SA-Integ-Alg-List} SHA-256 {Child-SA-Cipher-List} AES-CBC-256 {Child-SA-Integ-Alg-List} SHA-256

add /Setup/VPN/IKEv2/Auth/Parameter/"PHONE" {Local-Auth} RSA-Signature {Local-Dig-Sig-Profile} "DEFAULT" {Local-ID-Type} Distinguished-Name {Local-ID} "CN=vpn.yourdomain.de/C=DE/L=YourCity/SN=Server/ST=NRW" {Local-Password} "" {Remote-Auth} RSA-Signature {Remote-Dig-Sig-Profile} "DEFAULT" {Remote-ID-Type} Distinguished-Name {Remote-ID} "CN=Phone/C=DE/L=Mobile/SN=Client/ST=Mobile" {Remote-Password} "" {Addit.-Remote-ID-List} "" {Local-Certificate} "VPN1" {Remote-Cert-ID-Check} Yes {OCSP-Check} No

add /Setup/VPN/IKEv2/IKE-CFG/IPv4/"PHONE" {Start-Address-Pool} "192.168.22.220" {End-Address-Pool} "192.168.22.220" {Primary-DNS} "192.168.22.11" {Secondary-DNS} "8.8.8.8"

add /Setup/VPN/Networks/IPv4-Rules/"PHONE-RULE" {Local-Networks} "0.0.0.0/0" {Remote-Networks} "192.168.22.220"

Die Einrichtung der strongwan App ist zwar IMHO sehr simpel, dennoch hab ich einen passenden Screenshot angehängt.

Freut mich, dass dir (jemandem) das hilft. Was bei der Verhandlung zwischen deinem Samsung und dem LANCOM schief geht, kann ich leider nicht sagen.

Es gibt im Übrigen auch einen Knowledgebase-Artikel zur Einrichtung einer IKEv2 PSK Verbindung: https://www2.lancom.de/kb.nsf/1275/39FA ... enDocument. Ich würde dir wohl zu einer Zertifikatsbasierten IKEv2 Verbindung raten. Da kommst du nicht in Verlegenheit ein schwaches Passwort zu wählen. Musst dann wohl auf dein Smartphone aufpassen...

Gruß

[cpuprofi]

Hallo Beki,

...Es gibt im Übrigen auch einen Knowledgebase-Artikel zur Einrichtung einer IKEv2 PSK Verbindung: https://www2.lancom.de/kb.nsf/1275/39FA ... enDocument...

ich habe es mal eben nach der LANCOM Anleitung probiert und bekomme im VPN-IKE Trace folgenden Fehler:

"Invalid ENCR/INTEG algorithms"

Kann da der Lancom etwas nicht , was das Handy haben möchte...?

Grüße
Cpuprofi

[beki]

Kann da der Lancom etwas nicht , was das Handy haben möchte...?

Oder anders herum. Jedenfalls gibt es wohl keine Überschneidung von angebotenen und akzeptierten Verschlüsselungsparametern (bin kein VPN Profi).

Mach doch einen neuen Thread auf und poste einen aussagekräftigen Trace. Der wird verraten, wer was anbietet/akzeptiert. Anschließend solltest du das LANCOM insofern anpassen, als dass es ein Angebot des Smartphones akzeptiert.

[Jirka]

Hallo Dr. Einstein, hallo beki,

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.

da war der Stand der Dinge ja der, dass das Paket mit dem DH-14 nicht kam, immer nur DH-24. Aber irgendwann erinnerte ich mich an meine eigene Frage:

Übrigens: IKEv2 am Android Handy mit SIP funktioniert bei mir wunderbar!

über WLAN. Oder auch über Mobilfunk?

...und versuchte es über WLAN (zweiter Internetzugang) statt über Mobilfunk. Und kaum war das der Fall, kam nach dem ersten Paket mit DH-24 eines mit DH-14. Dann musste ich zwar noch ein paar Kleinigkeiten ändern, aber das war nicht das Thema und zügig erledigt (z. B. Identitätstyp). Die VPN-Verbindung funktionierte dann endlich, also über Android/Samsung-Standard-VPN und auch noch nicht mit Zertifikaten (das kommt als nächstes). Aber es ging erst mal! Schön.

I hear you!

Schön. Vielen Dank für Deine Ausführungen! Auch wenn ich jetzt strongSwan noch nicht drauf hab, heißt es nicht, dass ich es nicht installieren werde. Ich habe jetzt erst mal versucht, mit dieser vorhandenen VPN-Geschichte klarzukommen. Und ich finde, dass das ganz gut geglückt ist. Nun weiß ich immerhin, dass das zumindest erst mal geht.

Ich hab nicht erwähnt, dass die Einrichtung, bis es dann funktioniert, lästig werden kann -- sorry.

In der Tat, Dein Satz, hier oben war er ja noch mal im Zitat mit drin, klang nach 5 Minuten und da habe ich gedacht, ach die 5 Minuten hast Du noch. Und dann wurde es immer mehr und immer später...

Falls es dich tröstet, ich hab länger als 3h gebraucht um ein Setup zu finden, das so funktioniert wie ich es mir gewünscht habe.

Ja, das tröstet mich - ehrlich. Und es beruhigt mich, dass es anderen auch so geht.

Kann ich dich für die Android App Strongswan begeistern?

Sobald hier ein Android VPN-mäßig zu konfigurieren ist, was nicht von Samsung ist, führt da ja sowieso kein Weg dran vorbei. Ich schaue mir es demnächst auch an, muss nur die Zeit finden, im Augenblick stapelt sich hier schon wieder alles.

Du musst lediglich darauf achten, dass der CN (common name) des VPN-Server-Zertifikats dem Hostnamen entspricht mit dem du dich zum Server verbindest, und dass dieser Hostname auch als DNS alternative Name im Zertifikat steht

Oha, das sind aber doch schon ganz schöne Anforderungen/Einschränkungen, wenn man bedenkt, dass manche Router über verschiedene WAN-Verbindungen erreichbar sind (und ich dann für jede Verbindung ein eigenes Zertifikat brauche).

Generierst du deine Zertifikate im LCOS über die WebApp?

Nö. Ich habe schon Zertifikate verwendet, da gab es diese Funktionalität noch nicht und dann bin ich beim XCA geblieben. Ich glaube sogar, dass die Verwendung von XCA Vorteile bietet.

Was bei der Verhandlung zwischen deinem Samsung und dem LANCOM schief geht, kann ich leider nicht sagen.

Die Antwortpakete des LANCOMs scheinen beim Smartphone nicht anzukommen. Abenteuerlich. Über Mobilfunk geht die VPN auch nach wie vor nicht.

Vielen Dank und viele Grüße,
Jirka

[cpuprofi]

Hallo Beki, hallo Jirka, hallo LANCOM-Management,

Die Antwortpakete des LANCOMs scheinen beim Smartphone nicht anzukommen. Abenteuerlich. Über Mobilfunk geht die VPN auch nach wie vor nicht.

tja und da sind wir wieder bei meinem Problem mit der SIP-Client-Anbindung von WAN-Seite zum VCM... ohne WAN-Freigabe am VCM ist dieses nicht möglich

Bitte dieses Problem endlich mal auch als Fehler ansehen und beheben.

Grüße
Cpuprofi

[LoUiS]

Hi cpuprofi,

Du kannst hier noch so oft in allen moeglichen Threads darauf rum reiten, wie Beki Dir aber schon geschrieben hat, ist das Thema abgeschlossen! Daran wirst Du mit deinem Verhalten hier im Board sicherlich nichts aendern. Wenn Dir soviel daran liegt, wende Dich bitte direkt an LANCOM, aber "spamme" bitte hier nicht unnoetig die Threads voll.


Ciao
LoUiS

[beki]

Oha, das sind aber doch schon ganz schöne Anforderungen/Einschränkungen, wenn man bedenkt, dass manche Router über verschiedene WAN-Verbindungen erreichbar sind (und ich dann für jede Verbindung ein eigenes Zertifikat brauche).

Solange du alle FQDN kennst, unter denen du den VPN Server erreichen möchtest, brauchst du nur ein VPN Server Zertifikat (so wie es das verstanden habe). Das heißt du trägst alle FQDN, unter denen der Server erreichbar ist, als Subject Alternative Name ins VPN-Serverzertifikat ein.

Es kann aber auch sein, dass das nicht mehr nötig ist, weil es seit Version 1.6.0 den Schalter "Server identity" in der App gibt: https://wiki.strongswan.org/projects/st ... dVpnClient Da kann ich aber nichts versprechen, hab damit noch nicht gespielt (eigentlich soll der Schalter ermöglichen, eine spezielle strongswan Instanz auf einem Rechner mit mehreren Instanzen als Gegenstelle auszuwählen). Im Zweifel bräuchtest du dann aber ein VPN-Profil für jede WAN Schnittstelle deines LANCOMs.

Die verlinkte Wiki-Seite sagt auch:

Important: The hostname/IP of the VPN server, as configured in the VPN profile, has to be contained as subjectAltName extension in the VPN server's certificate. Since 1.6.0 the server identity may also be configured explicitly.

Das lese ich so: Ab Version 1.6.0 der App kann man auch auf Subject Alternative Names im VPN Serverzertifikat verzichten, man muss aber dann die erwartete Server-Identität konfigurieren und diese entspricht dann (vermutlich) dem CN des Serverzertifikats. Dann ist es dafür aber egal, zu welchem FQDN oder zu welcher IP-Adresse man sich verbindet.

Siehe auch https://wiki.strongswan.org/issues/813.

Über Mobilfunk geht die VPN auch nach wie vor nicht.

Da mache ich dann deinen Mobilfunkbetreiber verantwortlich. Welchen nutzt du denn? Mit congstar (T-Mobile) tuts.

[Jirka]

Hallo zusammen,

nochmal eine kleine Rückmeldung zu meiner Smartphone-VPN (derzeit mit PSK über Samsung-integriertes-Android-IKEv2).
Nachdem die VPN nun schon von einigen WLANs aus funktionierte, über Mobilfunk, wie geschrieben, aber nicht, heute das nächste Problem.
War heute Vormittag im örtlichen eduroam-WLAN-Netz der Uni und die VPN baut sich erfolgreich auf, danach geht jedoch gar nichts. Kein Ping, kein DNS, keine Webseite. Ob die VPN-Implementation da mit der 21-er-Netzmaske im WLAN nicht klar kommt, ich weiß es nicht. Grundsätzlich erhält man in dem eduroam-WLAN eine öffentliche WAN-IP für jeden WLAN-Client. Und VPN mit Notebook geht ja auch. Aber mit dem Handy ist nichts zu machen. Kann man also so noch niemandem anbieten. Sobald ich mehr Zeit habe (wonach es im Augenblick leider nicht aussieht), werde ich weiter experimentieren...

Viele Grüße,
Jirka

[Jirka]

Hallo beki,

danke für die Infos. Komme demnächst drauf zurück.

Da mache ich dann deinen Mobilfunkbetreiber verantwortlich. Welchen nutzt du denn? Mit congstar (T-Mobile) tuts.

Das mache ich auch. Ist callmobile über T-Mobile (inzwischen bietet der Anbieter nur noch über Vodafone an, ich bin aber noch bei T-Mobile).

Vielen Dank und viele Grüße,
Jirka

[cpuprofi]

Lieber LoUiS,

Hi cpuprofi,

Du kannst hier noch so oft in allen moeglichen Threads darauf rum reiten, wie Beki Dir aber schon geschrieben hat, ist das Thema abgeschlossen! Daran wirst Du mit deinem Verhalten hier im Board sicherlich nichts aendern. Wenn Dir soviel daran liegt, wende Dich bitte direkt an LANCOM, aber "spamme" bitte hier nicht unnoetig die Threads voll.


Ciao
LoUiS

was meinst Du was ich schon seit Jahren (!!!) mache? Aber leider traut sich keiner Koenzen-(Fehl-)Entscheidung in Frage zu stellen...

Das gleiche war ja schon mal so bei LANCOM, beim VCM, da wurde ja damals auch entschieden diesen nicht weiter zu "pflegen" weil Telefonie können "andere" ja besser Und was war dann? Dann kam "auf einmal" die Telekom und wollte "ALL-IP"... Und auf einmal mußte LANCOM den VCM "wiederbeleben"...

Hätte LANCOM bezüglich VCM auf seine Kunden und Händler gehört, wäre LANCOM heute Marktführer für "ALL-IP Router" und hätte nicht fast ein 3/4 Jahr benötigt, bevor TR114 (einigermaßen) mit LANCOM-Routern "nutzbar" war!

Fehler hat LANCOM ja schon immer gemacht, aber es kommt heutzutage mehr denn je darauf an, diese schnell zu korrigieren und nicht erst mal wieder diese jahrelang aus "politischen Gründen" abzulehnen!

Soviel dazu...

Grüße
Cpuprofi

[cpuprofi]

Hallo Beki,

Über Mobilfunk geht die VPN auch nach wie vor nicht.

Da mache ich dann deinen Mobilfunkbetreiber verantwortlich.

ich nutze hier Vodafone (Premium-Vertrag postpaid) und da geht es nicht. Die NCP-App geht aber ohne Probleme...

Somit möchte ich jetzt mal den Mobilfunkbetreiber als Fehler ausschließen...

Grüße
Cpuprofi

[beki]

Die NCP-App geht aber ohne Probleme...

Du verbindest dich mittels https://www.ncp-e.com/de/produkte/ipsec ... r-android/ zu einem LANCOM IKEv2 Server? Oder meinst du dass es für dich mit dieser App funktioniert wenn du dich bei einem NCP Server über Mobilfunk anmeldest?

<offtopic>

Hätte LANCOM bezüglich VCM auf seine Kunden und Händler gehört, wäre LANCOM heute Marktführer für "ALL-IP Router" [...]

Fehler hat LANCOM ja schon immer gemacht, aber es kommt heutzutage mehr denn je darauf an, diese schnell zu korrigieren und nicht erst mal wieder diese jahrelang aus "politischen Gründen" abzulehnen!

LANCOM hat seinen Umsatz in den letzten drei Jahren um jeweils (pro Jahr) zweistellige Prozentpunkte gesteigert. Unsere Mitarbeiterzahl hat sich in den letzten drei Jahren um mehr als 30% gesteigert. Unsere Unternehmensentscheidungen trifft und verantwortet dabei unser Management, nicht die Menschen im Internet. Unserem wirtschaftlichen Erfolg zufolge haben wir wohl vieles gut gemacht und richtig entschieden.

Leider kann keine Firma die Wünsche jedes Kunden erfüllen. Machst du bei deinem Smartphone keine Kompromisse? Oder bei deinem Auto? Anmeldung über WAN am VCM wird es in absehbarer Zeit nicht geben. Bitte arrangiere dich damit.
</offtopic>

[cpuprofi]

Hallo Beki,

die VPN kommt mit der "normalen NCP-App" mit IKEv1 zustande und daher gehe ich mal davon aus, daß Vodafone die Ports 500 und 4500 und das IP-Protokoll ESP nicht blockiert... Somit sollte ja auch dann mit Android und IKEv2 ein Verbindungsaufbau über Mobilfunk möglich sein. Oder habe ich da jetzt was übersehen?

<offtopic>

Mein Unmut darüber, daß LANCOM eine gute und oft genutzte Funktion (welche über zig Jahre einwandfrei lief) einfach mal so "aus politischen Gründen" abschafft, richtet sich nicht gegen die Entwickler, Programmierer und anderen LANCOM Mitarbeiter, sondern gegen das LANCOM Management!

</offtopic>

Grüße
Cpuprofi

[LoUiS]

@cpuprofi, ich wiederhole mich nur ungern: "... wende Dich bitte direkt an LANCOM, aber "spamme" bitte hier nicht unnoetig die Threads voll"!
Mach wegen mir einen eigenen Thread auf, da kannst Du Dich gerne darueber auslassen, aber muell hier nicht alle moeglichen Threads damit voll.
Weitere Beitraege zu dem Thema werde ich dann gesammelt ausschneiden und entsorgen!

Btw. auch die VPN Beitraege haben nichts mit dem Beta Status des LCOS 10.00 zu tun, also bitte alle Anderen auch "Back To Topic!" MAcht bei VPN Problemen einen eigenen Thread im entsprechenden Bereich auf. Danke!

[booker]

Guten Abend,

bei meinem ersten Test der 10.00.0063RC1 sind mir folgende zwei Dinge aufgefallen.

1. Die IPv6-Firewall bring nun ja eine passende Regel ALLOW_SIP mit. Aber selbst wenn ich diese Regel aktiviere landen eingehende Pakete (zumindest manchmal) in der DENY-ALL Regel.

2. Alle paar Sekunden sehe ich im SIP Trace folgende Einträge. Weiter vorne in diesem Thread (4. November 2016, Gerald und LoUiS) habe ich vergleichbare Beträge gelesen. Allerdings auch der Hinweis, dass es bereits als Bug bekannt ist. Ob das nun im getesteten RC1 schon behoben sein sollte, keine Ahnung. Falls nein, dann einfach ignorieren.

Code: Alles auswählen

[SIP-Connection] 2017/03/26 19:09:43,703  Devicetime: 2017/03/26 19:09:45,903 [SIP UDP Transport (192.168.235.17:5062)]: Processing new inbound SIP message

[SIP-Connection] 2017/03/26 19:09:43,703  Devicetime: 2017/03/26 19:09:45,903 [SIP UDP Transport (192.168.235.17:5062)]: Could not decode SIP message (invalid message), dropping it

[SIP-Connection] 2017/03/26 19:09:43,703  Devicetime: 2017/03/26 19:09:45,903 [UDP Server]: Processing message failed

[SIP-Connection] 2017/03/26 19:09:43,703  Devicetime: 2017/03/26 19:09:45,903 [SIP UDP Transport (192.168.235.17:5062)]: Discarding (local socket was 192.168.235.254:5060, Tag 0)

[SIP-Connection] 2017/03/26 19:10:02,407  Devicetime: 2017/03/26 19:10:04,616 [SIP UDP Transport (192.168.235.18:5060)]: Processing new inbound SIP message

[SIP-Connection] 2017/03/26 19:10:02,407  Devicetime: 2017/03/26 19:10:04,617 [SIP UDP Transport (192.168.235.18:5060)]: VCM registrar proceeds with REGISTER request

[SIP-Connection] 2017/03/26 19:10:02,407  Devicetime: 2017/03/26 19:10:04,617 [SIP UDP Transport (192.168.235.18:5060)]: Discarding (local socket was 192.168.235.254:5060, Tag 0)

[SIP-Connection] 2017/03/26 19:10:03,187  Devicetime: 2017/03/26 19:10:05,397 [SIP UDP Transport (192.168.235.16:5065)]: Processing new inbound SIP message

[SIP-Connection] 2017/03/26 19:10:03,187  Devicetime: 2017/03/26 19:10:05,397 [SIP UDP Transport (192.168.235.16:5065)]: Could not decode SIP message (invalid message), dropping it

[SIP-Connection] 2017/03/26 19:10:03,187  Devicetime: 2017/03/26 19:10:05,397 [UDP Server]: Processing message failed

[SIP-Connection] 2017/03/26 19:10:03,187  Devicetime: 2017/03/26 19:10:05,397 [SIP UDP Transport (192.168.235.16:5065)]: Discarding (local socket was 192.168.235.254:5060, Tag 0)

[SIP-Connection] 2017/03/26 19:10:04,154  Devicetime: 2017/03/26 19:10:06,356 [SIP UDP Transport (192.168.235.16:5065)]: Processing new inbound SIP message

[SIP-Connection] 2017/03/26 19:10:04,154  Devicetime: 2017/03/26 19:10:06,357 [SIP UDP Transport (192.168.235.16:5065)]: VCM registrar proceeds with REGISTER request

[SIP-Connection] 2017/03/26 19:10:04,170  Devicetime: 2017/03/26 19:10:06,357 [SIP UDP Transport (192.168.235.16:5065)]: Discarding (local socket was 192.168.235.254:5060, Tag 0)

Gruß
booker