Firmware Upgrade LCOS FX 11.1

[UKernchen]

Hallo,

hat sich schon jemand an LCOS FX 11.1 getraut und was gibt es für Erfahrungen?

Grüße Uwe

[LanSailor]

Moin,
ja, ich habe es gemacht! Hat soweit auch geklappt mit einer UF-60 mit Upgrade von der aktullen 10.x
Aber: Die Einrichtung Benutzer definierte Dienste ist kaputt.
Die Anzeige bereits vorhandener Dienste klappt nicht und neue kann ich auch nicht anlegen.
Präziser: In der Liste sieht man den Namen, aber in der Detailansicht werden die Ports und Protokolle nicht angezeigt, da steht nur {{getSerivice.textItem}} . Neuanlage und speichern geht auch nicht.

Die Firewall selbst schein aber zu funktionieren, d.h. die Benutzer definierten Ports sind offen. Man kann halt nichts ändern.

Update: Man muss den Browser-Cache manuell von Hand löschen, dann geht es wieder. Daher: Problem gelöst!

Gruß, der Lansailor

[Dr.Einstein]

Mal anderen Browser probiert / Cache geleert?

[hub]

Bei mir funktionieren die benutzerdefinierten Dienst noch.
Es ist eben nur die Möglichkeit hinzugekommen, Quellports zu definieren.

Was bei mir nicht mehr geht ist der Reverse-Proxy von intern.
Ich hatte auf der externen IP Reverse Proxies definiert, die früher auch von intern erreichbar waren.

Seit dem Update erreiche ich sie nur noch von außen, nicht mehr von innen - was nicht gerade toll ist, um es vornehm auszudrücken.

Aber vielleicht hat jemand eine Lösung?

[nibbleminx]

Was bei mir nicht mehr geht ist der Reverse-Proxy von intern.

Warum verwendet man denn intern einen Reverse-Proxy? Hairpin-NAT sollte (in der Regel) der bessere Weg sein: https://knowledgebase.lancom-systems.de ... d=50136249

[hub]

Was bei mir nicht mehr geht ist der Reverse-Proxy von intern.

Warum verwendet man denn intern einen Reverse-Proxy? Hairpin-NAT sollte (in der Regel) der bessere Weg sein: https://knowledgebase.lancom-systems.de ... d=50136249

Die Firewall hat eine Externe Schnittstelle (eth0), das externe Netz, was bei mir noch intern ist, weil die Firewall nicht direkt am Internet hängt, nennen wir die externe Zone DMZ.

Dann gibt es ja noch 3 weitere Anschlüsse, da hängen 3 Netzzonen dran.

In der Zone 1 (eth1) hängen verschiedene Dienste für die ein Reverse-Proxy eingerichtet ist, der auf extern (eth0) lauscht.

In Zone 2 (eth2) befinden sich Clients, die auf die Dienste hinter dem Reverse-Proxy (eth0) in Zone 1 (eth1) zugreifen, bisher erfolgreich.

Zeit dem Update geht der Zugriff nur noch von extern, nicht mehr aus den internen Zonen heraus.

Danke für die Antwort, ich schaue es mir mal an.

Alternativ benötige ich eben ein doppeltes DNS und nochmal Reverse-Proxies.

Der Vorteil an dem bisherigen Aufbau war eben, dass ich nur 1 Zertifikat pro Anwendung für den Reverse Proxy benötigte und kein doppeltes DNS.

[hub]

Was bei mir nicht mehr geht ist der Reverse-Proxy von intern.

Hairpin-NAT sollte (in der Regel) der bessere Weg sein: https://knowledgebase.lancom-systems.de ... d=50136249

Das Hairpin-NAT hat für mich nicht funktioniert.

Die Lösung war letztendlich für jeden Dienst einen Reverse Proxy für die Zone 2 (eth2) zu erstellen, der dann natürlich auf dem internen Interface (eth2) der Firewall lauscht.

Dadurch ändern sich für die interne Zone aber die IPs der Anwendungen. (Jeder FQDN hat zwei 2 IPs und 2 Reverse Proxies, jeweils 1 für extern (eth0) und intern (eth2).

Das Backend bleibt unverändert. Das selbe Backend wird von extern und intern genutzt, weshalb man bei den Revers-Proxy-Einträgen eigentlich nur eine Kopie anlegen braucht und das Interface umändert.

Zusätzlich benötigt es aber auch ein internes DNS für die korrekte IP-Auflösung, wenn die Anwendungen aus der Zone 2 (eth2) aufgerufen werden.

Unter LANCOM --> Netzwerk --> DNS --> Netzwerk-spezifische Einst.
habe ich daher zwei DNS Server für das Quellnetz der Zone 2 hinterlegt - für den Domainraum, unter dem die Anwendungen laufen, mit den internen IPs.

Auf dem internen DNS habe ich dann lediglich die IP der Firewall in der Zone 2 als A-Record angelegt und mit diesem Eintrag dann für jede Anwendung CNames verknüpft. Da die SSL-Zertifikate ja auf den jeweiligen FQDN der Anwendung ausgestellt wurden, und ich die bestehenden einfach weiter verwenden möchte, blieb es beim selben FQDNs extern wie intern.

Alle Anfragen für außerhalb des eigenen Domain-Raumes werden dann über die externen DNS-Server aufgelöst.

Bei mir war der Aufwand zum Glück überschaubar.

Aber so ist es ja eigentlich auch korrekt, internes und externes DNS zu trennen.
Ich hatte das damals überhaupt nur so angelegt, weil es funktionierte.
Ob Bug oder Feature lass ich mal dahin gestellt.

[Zerwas]

Bei mir gab es keine Probleme nach dem Update (UF360). Hinweis: Das Update dauert mal wieder länger (ca. 20 Minuten) und die Firewall ist in dieser Zeit nicht erreichbar.

[v.mueller]

Hallo zusammen,

bei uns funktioniert leider auch nach dem Update der Reverse Proxy zum Teil von Innen nicht mehr. Zum Teil deshalb weil z.B. kommende VPN-Netze funktionieren, VLANs aber nicht. Bis zu dem Update auf die 11.1 war das alles kein Problem.
Auch der Zugriff von außen auf den Reverse Proxy funktioniert nicht mehr sauber. Exchange OWA funktioniert, Outlook z.B. nicht. Alles ziemlich bescheiden.
Leider können wir das auch mit Hairpin NAT nicht lösen. Wir nutzen den Proxy auch um z.B. bestimmte Teile vom Exchange von Außen nicht zugänglich zu machen.
Reverse Proxy in jedem Netz mit jeweils eigenen DNS zu bauen ist in meinen Augen für uns auch nicht sinnvoll.
Systemlast der UF-760 ist seit der neuen Version auch deutlich hoch gegangen. Bei 8 Gb Durchsatz lagen wir vorher mit IPS aber ohne Proxy bei max ca. 30% CPU Last. Jetzt in etwa bei 50%.
Fazit: Wäre schon toll wenn bald eine korrekt funktionierende Firmware kommt.

Gruß,
Volker

[technikanddesign]

Wir haben seit dem Update, extreme Probleme in Sachen VPN.

Teilweise baut das VPN auf, dann wieder nicht. Dann geht es, dann wieder nicht. Ist wie ein Glücksspiel ....................

[ThoddyKunz]

Ich schließe mich meinem Vorredner mal an mit den VPN-Problemen.

Ich habe schon seit langem von meiner privaten UF-60 ein Net-2-Net-VPN (IPSec) zu einer UF-360 (LCOS FX 10.13.7304RU7) und ein zweites Net-2-Net-VPN (IPSec) zu einem 1783VAW (LCOS 10.50.1483SU15) eingerichtet. Seitdem ich die UF-60 auf die Version 11.1 upgedatet habe, brechen die VPN-Verbindungen mindestens 1x pro Stunde ab.

Die UF-60 baut die VPN-Verbindungen zu den beiden anderen Geräten auf, da diese über eine feste IPv4-Adresse erreichbar sind. Meine IPv4-Adresse ist dynamisch. Außerdem hängt meine UF-60 hinter einer Fritz!Box 7590, die auch die Internet-Verbindung aufbaut.

Sind solche Probleme bereits bekannt?

Viele Grüße
ThoddyKunz

[XJ8]

Zwar bin ich nicht unbedingt ein Fan der R&S Firewalls, aber mit Blick auf das Thema VPN habe ich damit überhaupt keine Probleme.

In einem von mir betreuten Netz, in dem u. a. 18 x UF-260 site2site VPNs zu einer Cisco 5516-x mit FirePower Modul betreiben, gibt es absolut keine Problem. Die VPN Verbindungen laufen zuverlässig, teilweise über Wochen. Die UF-260 haben sowohl feste IPs als auch ein paar mit dynamischen IPs. Teilweise haben die R&S zusätzlich noch den Zugang via Lancom VPN-Client oder Open-VPN Client konfiguriert, alles völlig unauffällig.

Die UF-260 laufen mit der 11.1 RU6 und die Ciscos ebenfalls mit den aktuellen Releases.

[heiNer]

Hallo zusammen,

zur VPN Problematik:

Wir betreiben eine UF-760 als CentralSite Gateway verwaltet in der LMC und daran angebunden etwa 35 Standorte per VPN.
Aus heiterem Himmel hatten wir das Problem das einige Standorte die VPN Verbindung nicht mehr oder nur kurz aufgebaut haben.

An den Außenstandorten sind verschiedene Router und auch Firmwarestände vorhanden: 1900EF (10.80.0345RU2), 1900EF (10.80.0742SU8), 1900EF (10.92.0018Rel), 1930EF (10.92.0167RU2)

CentralSite UF-760 (11.1.7675)

Ich konnte beobachten das die VPN Verbindungen meistens scheitern mit der Meldung IKE_I_IKE_key_mismatch, aber auch nur sporadisch.
Bei genauerem Betrachten fiel mir auf das die vorgeschlagene Auswahl der DH Gruppen, auf den betroffenen Gateways sehr groß war (DEFAULT = durch LMC erzeugt)

vorher:

dh_groups_vorher.png

nachher:

dh_groups_nachher.png

Nachdem wir die Auswahl der Diffie-Hellman Gruppen auf DH14 reduziert hatten, konnten sofort alle VPN Verbindungen problemlos aufgebaut werden.
Ob und wie das mit der Version 11.1 der UF, in Verbindung mit IKEv2 VPNs zu den Routern, zusammenhängt kann ich nur vermuten.

Fakt ist, in der Version 10.13 haben alle VPNs problemlos funktioniert.

Vielleicht hilft euch das ein bisschen.

Gruß
heiNer

[XJ8]

Vom BSI halte ich zwar nicht viel, aber:

DH14 soll eigentlich - lt BSI Empfehlung - nicht mehr verwendet werden.
Die empfehlen AFAIK min DH 20 oder DH21, was die 11.1 auch
gut kann.

Dazu alles mit min 256 oder 512 was es gibt AES-256 SHA-2-256 o 512 sowohl in Ph1 als auch 2.

Die Verwendung von Default-Liste in Lancom Geräten (und nicht nur dort) habe ich mir komplett abgewöhnt, da sind mir
zuviel zweifelhafte Kombinationen möglich.

Beste Grüße
XJ8