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.