Horror-Release 10.12: VPN mit "Rückschlagventil"

[tom63]

Wie schon erwähnt, man kann nur davor warnen, eine Konfig "einzuspielen". Wenn es dieses blöde ".lcf"-Format ist, sowieso.
Dann hat der Kunde aber Spaß.

wie gesagt bin ich im vergleich zu euch allen ein komplett ahnungsloser. aber dass man in den neueren geraeten immer zwei firmwares speichern kann und auch noch zum beispiel eine konifiguration die nach einem reset des routers dann automatisch geladen wird find ich schon super. ich lass da in dem speicherplatz 1 immer die allererste drin die einwandfrei funktioniert hat. und selbst wenn ich dann mal alles vermurkst hab und nichtmal mehr auf den entfernten router komm kann ich den kollegen im aussenbuero anrufen und ihm am handy sagen er soll a streichhoelzerl fuer 5 sekunden in das reset-loch stecken bis alles rot leuchtet und dann wieder loslassen. und das hat immer funktioniert und schwupp-die-wupp war ich wieder drauf ...

[AS1306]

@All ... auch ich habe so meine Schwierigkeiten mit dieser Version. Seit der Aktualisierung bekomme ich keine wirklich stabile Verbindung mehr hin. Permanent kommt es zum dargestellten Verbindungsabbau (Dead Peer Detection Timeout). Wenn ich es mal schätzen sollte - 2 x pro Minute. Da wir viel über RDP-Verbindungen arbeiten kommt es somit zu ständigen Aussetzern. Hinzu kommt auch noch ein 2. Verhalten. Seitdem ist es schwierig geworden, über eben diese Verbindung per VoIP Telefonate zu führen. Nach ca. 32-33 Sekunden erfolgt eine 1-2 sekündige Unterbrechung. Sehr unangenehm, da man sich ständig wiederholen muss. Bin eigentlich davon ausgegangen, dass die Version als Release für das produktive Umfeld ausgegeben worden ist.

Leider wurde es notwendig, da nun auch der letzte Anschluss bei uns auf All IP umgestellt worden ist und damit verbunden der Austausch meines alten 1823 VoIP gegen einen neuen 1783 VAW. Für Ideen und Anregungen bin ich gern zu haben, da ich eigentlich ungern auf frühere Versionen zurückgehen möchte. Stichwort: inkonsistente DB ...

Mal ganz nebenbei, VPN musste manuell per Assistent angelegt werden, da die viel gepriesene 1-Click VPN Lösung nicht mehr funktioniert. Es werden aktuell keine Zeiten (Keepalive) und auch keine Gegenstellen eingetragen bzw. berücksichtigt. Schade, lief vorher etliche Jahre - genaugenommen seit 2013 ohne Schwierigkeiten ... auch die VPN-Verbindung!

Grüße aus Berlin

[Dr.Einstein]

Hi zusammen,

ihr müsst wirklich für jeden Krams Case bei Lancom einkippen, idealerweise nicht als Endkunde sondern mit entsprechenden Service Leveln. Gefühlt wird die 10.12 gaaaaanz langsam etwas, aber wenn jeder direkt auf die 9.24 zurückspringt, bekommen wir nie ein 10.xxer Build, der etwas taugt und stabil ist... und der Support der 9.24 fliegt garantiert in nächster Zeit raus, wenn die 10.20er kommt

Gruß Dr.Einstein

[AS1306]

@Dr. Einstein - yep, sehe ich auch so. Mein Problem ist allerdings Endkunde zu sein. Habe zwar so 30-40 Geräte in der Verwaltung, allerdings nicht auf Service-Level Niveau. Grundsätzlich bin ich absoluter Lancom-Fan der ersten Stunde. Ich stelle nur fest, dass bei den Veröffentlichungen es zunehmend irgendwie hapert. O.K. stecke nicht drin, will auch nicht weiter meckern, da ich eher lösungsorientiert gestrickt bin. Zur Problematik zurück - alle Verweise auf VPN in allen Geräten gelöscht und neu via Anleitung IKEv2 angelegt. Gleiche Symptomatik, Trace bis auf die permanenten DPD unauffällig. Habe mir noch einmal die Unterschiede IKEv1 und IKEv2 angesehen ... Entscheidung gefallen, dass ich IKEv1 verwende, da Leitungsprobleme offensichtlich hier besser gehändelt werden. Alles wieder raus aus den Geräten und via LANconfig 1-Click-VPN Assistenz verbunden ... mhh, soweit so gut - die GATEWAYs werden nicht eingetragen bzw. übernommen (falls hier die Frage kommt - ja, diese sind unter den Geräteeigenschaften im Bereich VPN hinterlegt!). Diese habe ich also manuell eingetragen ... und was soll ich sagen: stabile Verbindung seit der Zwangstrennung!!! Fax über VPN geht wieder, Telefon muss ich noch vor Ort testen. RDP folgt sofort!

Bitte die LANconfig wieder "reparieren", so dass die Einträge wieder übernommen werden! Der zweite Punkt ist schwieriger, da stecke ich ehrlich gesagt zu wenig drin. IKEv2 korrekt implementiert bzw. unterstützt? Leitungsfehler oder IKEv2 scheinen hier Probleme zu machen. Ist eigentlich eine Mischung IKEv1 und IKEv2 ohne weiteres möglich? Hintergrund sind die tatsächlich vorhandenen mobilen Clients, die über IKEv1 angebunden sind. Schwierig für mich ist zusätzlich, dass der Trace hierzu keine kernigen Rückmeldungen gibt. Einzig die periodische DPD Meldung, die auch schon im LANmonitor zu sehen war. Anyway, hoffe dass es jetzt stabil läuft und ich doch nicht unbedingt auf die 9.24 zurück muss.

THX für das offene Ohr ...

[Koppelfeld]

Dir ist mitunter schwer zu helfen...
Im Normalfall stimmen bei sowas die Netzbeziehungen nicht.

Es ist alles noch viel schlimmer.

Das VPN funktionierte die ganze Zeit. Bloß: VOM ROUTER SELBST erzeugte Verbindungen gehen ins Leere. Ins Internet - ok, in mein Wartungs - VPN - ok, lokal - ok. Aber nicht zur Zentrale.

Sic stantibus rebus habe ich die Empfehlung von "Bernie" befolgt und die VPNs neu erzeugt.
Mit dem Wizard. Der ist übrigens ziemlich kaputt.

Ergebnis: VPN funktioniert nach wie vor tadellos, bloß zeigt jetzt auch der Zentrale-Router die gleiche verrückte Eigenschaft: Keine Verbindung zum Niederlassungs-VPN, wenn diese auf dem Router selbst originiert wurde.


Was kann da los sein ?

[Koppelfeld]

Keine Verbindung zum Niederlassungs-VPN, wenn diese auf dem Router selbst originiert wurde.

Tell me on a sunday ...

Hingegen aber: (192.168.116.1 ist Niederlassungs-Router, 192.168.115.246 ist Zentralrouter)

Code: Alles auswählen

bo@osho:~$ telnet 192.168.115.246
[...]
root@KGW:/
> ping 192.168.116.1


 ---192.168.116.1 ping statistic---
 56 Bytes Data, 7 Packets transmitted, 0 Packets received, 100% loss 

root@KGW:/
> ping -a 192.168.115.99 192.168.116.1

    56 Byte Packet from 192.168.116.1 seq.no=0 time=27.342 ms 
    56 Byte Packet from 192.168.116.1 seq.no=1 time=27.408 ms 
    56 Byte Packet from 192.168.116.1 seq.no=2 time=26.589 ms 

 ---192.168.116.1 ping statistic---
 56 Bytes Data, 3 Packets transmitted, 3 Packets received, 0% loss 

Man könnte mit dem Verhalten ja fast leben. Bloß eines ist Scheiße:
Wenn man, vom Voice Call Manager aus, eine ISDN-Leitung in die Zentrale "exportiert", ist man gekniffen. Daher noch eine Frage nach einem Würgaround:
Bestünde die Möglichkeit, dem VCM eine alternative IP-Adresse zu vergeben ?

[Koppelfeld]

ihr müsst wirklich für jeden Krams Case bei Lancom einkippen, idealerweise nicht als Endkunde sondern mit entsprechenden Service Leveln.

Dreimal gemacht, dreimal formlos, fristlos, fruchtlos.

Ich kann ja wirklich verstehen, daß LANCOM nicht mit Endkunden sprechen möchte, die Thematik ist mittlerweile sehr umfassend. Aber dann müßte LANCOM hergehen und vorsorgen:
1. Verkauf nur an Kunden mit entsrechender Zertifizierung.
Hach, was wäre das schön, wenn Router und ähnliches Zeugs nur an Menschen mit Qualifizierung verkauft würden ! Und vernünftig ist das obendrein: Du darfst ja auch keine Funkgeräte betreiben ohne vernünftige Funkamateurlizenz. Und die hat sich übrigens gewaschen.
DAS sorgt für Fortschritte bei "Deutschlands Digitalisierung".

2. Support nur für Kunden mit nachgewiesener Qualifizierung.

Das vermindert die Supportanfragen und erhöht die Qualität der übrigbleibenden.


Wenn man aber als Unternehmen an Endkunden verkauft, dann muß man, bei offensichtlichen versteckten Mängeln wie diesem hier, auch Support leisten. Und zwar nicht nur, um dem Kunden im Einzelfall zu helfen, sondern um das Produkt zu verbessern.


Der 'cpuprofi' und ich haben seit neuestem einem klagefreudigen Anwalt einen LANCOM hingestellt. Mir juckt es doch in den Fingern, den einmal eine Supportanfrage schicken zu lassen. Wäre sicher gemein, aber interessant: "Erst die Säure, dann das Wasser, und schon wird der Lehrer blasser".

[tom63]

hi koppelfeld,

das is ne sackgasse und bringt nur 'sonntagsfrust'

noch mal die ganz bloede frage: hast du die vpn verbindung jetzt schon mal komplett neu eigerichtet?
weil: wie schon gesagt das ganze bei uns komplett problemlos funktioniert.
und ausserdem: wenn vpn jetzt mit der 10.12 prinzipiell nur noch als einbahnstrasse funktionieren wuerde hier vermutlich hunderte posts dazu kaemen.

netter gruss
tom

[Koppelfeld]

noch mal die ganz bloede frage: hast du die vpn verbindung jetzt schon mal komplett neu eigerichtet?
weil: wie schon gesagt das ganze bei uns komplett problemlos funktioniert.

Klaro. Es funktioniert (und funktionierte) ja auch einwandfrei, bloß, daß jegliche Verbindungen geblockt werden, die vom Filialrouter erzeugt werden.
Nach Neukonfiguration des VPN auf beiden Seiten (mit "Wizard") konnte ich auch vom Zentralerouter keine Verbindung mehr zur Gegenstelle aufbauen.

und ausserdem: wenn vpn jetzt mit der 10.12 prinzipiell nur noch als einbahnstrasse funktionieren wuerde hier vermutlich hunderte posts dazu kaemen.

Wie gesagt, es geht nur um lokal initiierte Verbindungen.

Ich habe ein bißchen in die 10.12 hineingeschnuffelt: "Layer 7 - Erkennung". Weia.
Hub = Repeater => Layer 1
Switch = Multiport - Bridge => maximal Layer 2
Router = IP => Layer 3 (mit NAT auch L4/5)
Bei Firewalls möchte man sich ebenfalls noch die Transport- und Session-Layer ansehen.

Der Rest des ISO/OSI - Modells paßt gar nicht zu TCP/IP.

Das hat aber noch keiner gemerkt und deshalb faseln wir alle von "Layer-5 - Switches" etc. pp..

Die Krönung findet sich in der LANCOM-Werbung zu den neuen Metallroutern:

"Unschlagbare Bandbreiten für die digitale Transformation"

Das soll noch jemand ernstnehmen ?

"Unschlagbar": 'Mal sehen, was Firma Juniper dazu sagt
"Bandbreiten": Nachrichtentechnisch aber eine Frequenzdifferenz, gemessen in Hz.
Hat mit "Durchsatz" nix, aber auch gar nix zu tun. Peinlich für eine Fachfirma.
"digitale Transformation": Wer nicht jetzt spätestens BULLSHIT schreit,
dem ist nicht mehr zu helfen.

Also ganz im Ernst: Wenn ich nicht wüßte, daß das ordentliche Geräte sind (vor allem dank der TOP-Leute hier im Forum), dann würde ich so einen Dummschmus NIE, NIE, NIE kaufen. Ich laß' mich doch nicht verkackarschen!. Diese Werbung ist "friendly fire".

[tom63]

hier mal was um die laune zu verbessern - auch einer der seinen hardware-frust verabeitet: https://www.youtube.com/watch?v=7QpJ_VDbIPA

have a good one
tom

p.s. den beitrag schreib ich grad auf dem getesteten dingsda

[Jirka]

Hallo Koppelfeld,

Wenn man, vom Voice Call Manager aus, eine ISDN-Leitung in die Zentrale "exportiert", ist man gekniffen. Daher noch eine Frage nach einem Würgaround:
Bestünde die Möglichkeit, dem VCM eine alternative IP-Adresse zu vergeben ?

Du kannst (bzw. musst), wenn der "Export" via SIP-Leitung stattfindet, ein Routing-Tag vergeben. Damit sollte das Problem geklärt sein.

Wenn der "Export" via SIP-Benutzer stattfindet, muss man folgende Fälle unterscheiden:
9.24: Hier wird standardmäßig das Routing-Tag 0 verwendet, aber immerhin die richtige IP-Adresse. Man legt dann einfach eine Route zum SIP-Benutzer in der IP-Routing-Tabelle mit Routing-Tag 0 an. Wie Backslash mir gerade letzte Woche schrieb, gehen Routen mit Routing-Tag 0 nicht in die automatische Regelerzeugung ein. Das Problem ist damit also sauber gelöst.
10.12: Hier ist irgendwie ein Bug reingekommen. Bei mehreren lokalen Netzen bindet sich der VCM bzw. der entfernte VCM-Benutzer (entfernt heißt mit einer IP, die nicht in den lokalen Netzen liegt) fälschlicherweise auf die IP-Adresse des LANCOMs, die beim Befehl 'show bind' als erstes erscheint. Hier nützt es dann auch nichts, eine Route mit entsprechendem Tag anzulegen, weil die Quell-IP von der VPN-Strecke dann als ungültig abgelehnt wird (vermute ich jedenfalls; den Trace habe ich mir seinerzeit nicht mehr angeschaut, mir reichte der IP-Router-Trace, wo ich sah, dass die Pakete an die VPN-Verbindung übergeben wurden, am anderen Ende aber nicht ankamen). Hier hilft meines Erachtens dann nur ein zurück zur 9.24, so wie ich es dann auch gemacht habe. Was noch eine sehr eingeschränkte Möglichkeit wäre, ist die Änderung der IP-Adresse des LANCOMs im ersten Netz von 'show bind' derartig, dass das erste Netz hinter den anderen Netzen einsortiert wird. Bei einem Gastnetz ist sowas ja ohne Problem möglich, danach wird es dann meistens anstrengend.

Viele Grüße,
Jirka

[COMCARGRU]

ihr müsst wirklich für jeden Krams Case bei Lancom einkippen, idealerweise nicht als Endkunde sondern mit entsprechenden Service Leveln. Gefühlt wird die 10.12 gaaaaanz langsam etwas, aber wenn jeder direkt auf die 9.24 zurückspringt, bekommen wir nie ein 10.xxer Build, der etwas taugt und stabil ist... und der Support der 9.24 fliegt garantiert in nächster Zeit raus, wenn die 10.20er kommt

Genau das ist der falsche Ansatz! Es ist vollkommen korrekt auf der 9.24 zu bleiben und bei Problemen den Support anzurufen. Wenn der dann sagt gehen sie erst mal auf die neuste Firmware, kann man direkt antworten: "Bin doch nicht bekloppt, dann wird es ja noch schlimmer - entweder sie fixen mein Problem mit 9.24 oder der Lancom fliegt raus..."

Wenn das alle machen, kann auch Lancom nicht mehr ignorieren, das bei der 10er gehörig was schief läuft... Vielleicht ändert sich ja dann etwas. Leider haben die Menschen verlernt mit den Füßen abzustimmen - deshalb muss man es den Menschen immer wieder sagen!

[AS1306]

So nach ein paar Tagen ein kleines Feedback. VPN steht "bombenfest", RDP läuft wie gehabt ohne Aussetzer - super. Fax geht auch, allerdings habe ich Schwierigkeiten mit VoIP. Es sind zwar nicht mehr diese Aussetzer von 1-2 Sekunden, aber eben immer noch deutliche "Lautstärkeschwankungen". Sollte ich es beschreiben sollen, dann wäre eine Sinuskurve tatsächlich die treffende Metapher. VoIP wurde doch immer priorisiert, hat sich da etwas in der 10.12 verändert? Muss jetzt zwangsläufig hier eine Bandbreitenreservierung bezüglich des VoIP-Traffics (QoS) über VPN eingerichtet werden? Lief tatsächlich unter der 9.24 deutlich besser - sorry, ist aber meine Erfahrung.

@COMCARGRU - netter Ansatz, damit hält man aber keinen Zug auf. Schau Dir die Beispiele bei Adobe oder Microsoft an, wobei bei mir ein Ende bezüglich Lancom tatsächlich erreicht wäre, wenn es nur noch über die Cloud gehen würde. Ich denke aber, dass sie sich damit ins Knie schießen würden. Ganz ausschließen kann man es nicht, hat man ja auch schon in anderen Fällen gesehen. Beispiel Teles mit seinem ISDN-Karten Support.

THX Andreas

[COMCARGRU]

Aufhalten will den Zug auch Niemand! Es geht lediglich darum den Lokführer dazu zu bewegen mal einen Blick auf die Weichenstellung zu werfen, damit er sieht, dass er sich gerade auf dem Abstellgleis befindet und er doch besser wieder aufs Hauptgleis wechselt

[Koppelfeld]

Hi Jirka,
Vorbemerkung: "Mein" Problem ist kein unmittelbares mit dem VCM - denn bereits ein Ping, wie im Beispiel gezeigt, funktioniert nicht mit der Adresse des Routers selbst. Sobald man mit der '-a' - Option eine falsche Absenderadresse angibt (aus dem lokalen Intranet), geht der Ping durch.


Bezogen auf den VCM:

9.24: Hier wird standardmäßig das Routing-Tag 0 verwendet, aber immerhin die richtige IP-Adresse.

... und alles funktioniert. Haben wir, genau so, mindestens 20 mal im Einsatz.

In Bezug auf 10.12:

Hier hilft meines Erachtens dann nur ein zurück zur 9.24, so wie ich es dann auch gemacht habe.

Es wäre aber tatsächlich schon schön, wenn 10.12 so gefixt werden würde, daß die originierende IP-Adresse a) richtig ist und b) auch nicht von welcher Instanz auch immer geblockt wird. Allerdings:
Der Fehler tritt nicht immer auf.