LCOS 10.40RC1 NAT Problem

[ittk]

Falls Du die aktuelle Beta testen willst, teile hier nur Dein Routermodell mit... Denn vorab ein Feedback zu erhalten, kann beiden Seiten nicht schaden .

Vielen Dank für die Antwort

Dann warte ich auf die nächste offizielle Version.

Viele Grüße

Thomas

[wahltho]

Hallo,

ich kann es ja mal ausprobieren:
1 x 1783VA
2 x 1781VA.

Ich bräuchte also die Betas für beide Router-Typen.

Viele Grüße

Thomas

[ittk]

LANconfig-10.40.0033
LANmonitor-10.40.0009
1783-VA LCOS 10.40 BUIL0137
1781-VA LCOS 10.40 BUIL0137

Hallo,

ich kann es ja mal ausprobieren:
1 x 1783VA
2 x 1781VA.

Ich bräuchte also die Betas für beide Router-Typen.

Viele Grüße

Thomas

[wahltho]

Merci

Habe es ausprobiert, aber bei mir hat es die Probleme mit dem Port Forwarding leider nicht behoben.

Vllt. noch kurz zur Konfiguration

der 1783VA dient als Load Balancer mit einem VF-VDSL-Anschluss. Dahinter hängen die beiden 1781VA mit jeweils einem Telekom-VDSL-Anschluss mit jeweils einer festen IP. Der 1783VA verwaltet also das LAN und macht Load Balancing zwischen den drei VDSL-Anschlüssen (2x indirekt über die 1781VA).

Mit den festen IPs der Telekom spreche ich die Geräte im LAN des 1783VA an. Das Port Forwarding kaskadiert somit jeweils über die 1781VA auf den 1783VA zu den Geräten im LAN.

Bisher hat das Alles einwandfrei funktioniert.

Viele Grüße

Thomas

[Dani99]

bei der 137er Version werden leider die eMailserver hinter dem Router auch nicht mehr bedient. Das Liegt aber wahrscheinlich daran, dass ich nicht so genau weis, wo ich dieses @Tag bei mir anfügen soll:


.

LG
Dani

[backslash]

Hi Dani99,

das mit dem Routing-Tag bezieht sich darauf, wenn unter "Peer-Or-IP" (also als Next-Hop) eine IP-Adresse angegeben wird. Da du aber direkt die Gegenstellen eingetragen hast, ist keine Angabe eines Routing-Tags nötig.

Was auch immer das Problem mit deinen Mail-Servern ist... Hier hilft nur, den Zugriff auf sie mit Traces zu verfolgen, um zu sehen, wo es hakt. Angefangen beim Ethenet-Trace, über den ARP-Trace bis zum IP-Router- und Firewall-Trace.

Und natürlich könnte auch ein Blick auf die FIB weiterhelfen (/Status/IP-Router/Act.-IPv4-Routing-Tab. oder "show ipv4-fib"). Dabei mußt du berücksichtiugen, daß es keinen automatischen Wechsel mehr zwischen den Kontexten (z.B. Rückfall auf Tag 0) mehr gibt, d.h. ein Paket wird beim Empfang in einen Kontext (Routing/Interface-Tag) gezwungen den es nicht mehr verläßt. Die Routing-Tabellen existieren pro Tag und sind in sich abgeschlossen. Ein Kontextwechsel ist daher nur über eine Firewallregel, die das Paket umtaggt, oder einen Next-Hop mit '@' Erweiterung möglich.

Gruß
Backslash

[backslash]

Hi wahltho

der 1783VA dient als Load Balancer mit einem VF-VDSL-Anschluss. Dahinter hängen die beiden 1781VA mit jeweils einem Telekom-VDSL-Anschluss mit jeweils einer festen IP. Der 1783VA verwaltet also das LAN und macht Load Balancing zwischen den drei VDSL-Anschlüssen (2x indirekt über die 1781VA).

der 1783 VA hat also eine PPPoE und zwei IPOE-Verbindungen? Auf den IPOE Verbindungen gab es das Problem mit dem ARP, das behoben wurde - wie du sicherlich mit einem ARP-Trace festellen kannst. Auf PPPoE-Verbindungen gab es das Problem nicht (wie auch aus Pauli's Post hervorgeht: feedback-lcos-release-update-betatest-f ... ml#p101508)

Letzendlich kann ich dir auch nur das gleiche sagen, wie Dani99: Verfolge die gescheiternen Zugriffe mit den genannten Traces. Ob ein Konfigurationsproblem vorliegt oder doch ein weiterer Bug, kann ich dir nicht sagen... Im Ernstfall mußt du das direkt bei LANCOM eintüten - mit Konfigurationen und genauer Beschreibung, was genau nicht funktioniert...

Gruß
Backslash

[wahltho]

Hallo Backslash,

vielen Dank für Deine ausführlichen Antworten

notfalls muss ich halt mal wieder 90 Euro investieren.

Noch eine letzte Frage:

Wenn das Port Forwarding mit 10.32 einwandfrei funktioniert, sollte es doch ohne Konfigurationsänderungen auch mit der 10.40 Version (ohne ARP-Problem) funktionieren, oder?

Viele Grüße

Thomas

[backslash]

Hi wahltho,

Wenn das Port Forwarding mit 10.32 einwandfrei funktioniert, sollte es doch ohne Konfigurationsänderungen auch mit der 10.40 Version (ohne ARP-Problem) funktionieren, oder?

solange du nicht noch andere Probleme hast - wie z.B. verschiedene Routing-Tags, die einen Eingriff in die Konfig nötig machen. Aber dazu hat geho ja schon gesagt, daß der Konfig-Konverter versucht, das zu erkennen und aufzulösen. "Versuchen" heißt aber auch, daß es ggf. nicht funktioniert und doch ein manueller Eingriff nötig ist.

notfalls muss ich halt mal wieder 90 Euro investieren.

was meinst du damit? Es gibt ein Formular, um Probleme zu melden: https://www.lancom-systems.de/service-s ... t-kontakt/. Da gibt es auch einen konstenfreien Link für Endkunden-Support. Leider hat man den entschieden keine eigene Seite mehr für den RC zu machen (siehe auch feedback-lcos-release-update-betatest-f ... 17869.html) und ich weiss auch nicht, wie genau Anfragen drüber bearbeitet werden, könnte mir aber vorstellen, daß eine Angabe, daß das Problem mit dem 10.40 RC auftritt, das Problem wichtiger macht...

Letztendlich kann ich dazu nur sagen: solange das nur hier im Forum bleibt und alle Leute nur warten, daß die Probleme magisch verschwinden, passiert vermutlich rein gar nichts.

Gruß
Backlash

[ittk]

Wahlto meinte bestimmt diese kostenplichtigen Optionen, Die in diesem Fall aber nichts bewirken....

Code: Alles auswählen

LANCOM Emergency Support 10320 4044144103209 Voucher für Zugang zum kurzfristigen Notfall-Support. Max. Reaktionszeit von 30
Minuten innerhalb der LANCOM Service-Zeiten. Ein LANCOM Experte steht für die
Abwicklung des Support-Falls max. 1 Std. zur Verfügung.

LANCOM Config Service - Remote 10311 4044144103117 Voucher für die Konzeption von individuellen Netzwerk-Lösungen per Telefon, E-Mail
oder Remote-Sitzung durch den LANCOM 2nd-Level Support. Ein Voucher entspricht
einer Bearbeitung von 45 Minuten

Beide zu je 90,00 € / Netto

Aber backslash hat Recht. Ihr duerft nicht hoffen, dass moegliche Bugs jemand Anderes meldet, dass solltet Ihr direkt immer selbst tun, damit in der Beta / RC-Phase gleich alle moeglichen Bugs gefunden und behoben werden.. Ein dediziertes, professionell organisiertes Beta/RC-Programm gibt es ja (leider) nicht (mehr)...

Hi wahltho,

Wenn das Port Forwarding mit 10.32 einwandfrei funktioniert, sollte es doch ohne Konfigurationsänderungen auch mit der 10.40 Version (ohne ARP-Problem) funktionieren, oder?

solange du nicht noch andere Probleme hast - wie z.B. verschiedene Routing-Tags, die einen Eingriff in die Konfig nötig machen. Aber dazu hat geho ja schon gesagt, daß der Konfig-Konverter versucht, das zu erkennen und aufzulösen. "Versuchen" heißt aber auch, daß es ggf. nicht funktioniert und doch ein manueller Eingriff nötig ist.

notfalls muss ich halt mal wieder 90 Euro investieren.

was meinst du damit? Es gibt ein Formular, um Probleme zu melden: https://www.lancom-systems.de/service-s ... t-kontakt/. Da gibt es auch einen konstenfreien Link für Endkunden-Support. Leider hat man den entschieden keine eigene Seite mehr für den RC zu machen (siehe auch feedback-lcos-release-update-betatest-f ... 17869.html) und ich weiss auch nicht, wie genau Anfragen drüber bearbeitet werden, könnte mir aber vorstellen, daß eine Angabe, daß das Problem mit dem 10.40 RC auftritt, das Problem wichtiger macht...

Letztendlich kann ich dazu nur sagen: solange das nur hier im Forum bleibt und alle Leute nur warten, daß die Probleme magisch verschwinden, passiert vermutlich rein gar nichts.

Gruß
Backlash

[cpuprofi]

...damit in der Beta / RC-Phase gleich alle moeglichen Bugs gefunden und behoben werden...

Ich glaube das wird nur ein frommer Wunsch von Dir sein...

Grüße
Cpuprofi

[ittk]

Ich glaube das wird nur ein frommer Wunsch von Dir sein...

Du weißt vermutlich ganz genau, was ich damit meine....

Es muss sich niemand wundern, wenn man selbst zu bequem ist, Bugs zu melden, die bei einem selbst auftreten, und auch aktiv dran zu bleiben - Hauptsache den bequemen Weg einschlagen.... Sollte auf diesem offiziellem Wege, ein gemeldeter und bestaetiger Bug, dennoch nicht behoben werden, muss seine Kritikalitaet und Prioritaet in die Wagschale geworfen werden.... Sollte jedoch ein entsprechend wichtiger Bug ignoriert werden, dann... In den meisten Faellen gibt es irgendwie eine Loesung / Workaround....
Man darf nicht erwarten, dass ein Passiv sein / Nichtstun bzw. Aussitzen und ggfs. eine einmal erfolgte Wortmeldung in einem inoffiziellen Forum (dass wir uns in einem Solchen bewegen, sollte hier Jedem bekannt sein) ueberhaupt Beachtung findet - ganz Geschweige denn, ueberhaupt zur Kenntnis genommen wird...

[wahltho]

Vielen Dank für Eure Antworten.

Noch eine Frage zum Routing-Tag mit 10.40:

Innerhalb der 1781er die vor dem 1783 hängen verwende ich für die WAN-Verbindung jeweils ein eigenes Netzwerk mit dem Routing Tag 1.

Pakete aus dem WAN kommen also an den 1781ern an und landen dort im LAN mit dem Routing Tag 1. Der 1783er hinter den 1781ern ist auch an dieses LAN mit dem Routing Tag angeschlossen. Dorthin werden die Pakete weitergeleitet. Das (eigentliche) LAN das der 1781er bedient und an dem alle Geräte hängen hat ein Routing Tag 0.

Muss ich jetzt in den 1781ern noch eine Firewall Regel zum Ändern des Routing Tags von 1 auf 0 eintragen?

Viele Grüße

Thomas

[backslash]

Hi wahltho,

Routing-Tags haben nur erstmal innerhalb eines Gerätes eine Bedeutung, d.h. es ist dem 1783 zunächst egal, was du in den 1781ern konfiguriert hast...

Aber dann verlässen mich doch meine Vorstellungsfähigkeiten zu deinem Aufbau... Ich dachte, du hast den 1783 der einen VDSL-Anschluß bedient und an zwei DSL-Ports jeweils noch ein 1781 hängen hat, die weitere VDSL-Ports bedienen und der 1783 betreibt einen Loadbalancer über die drei WAN-Verbindungen. Damit wären die 1781 doch gar nicht mit dem LAN verbunden... und nun erzählst du, daß der 17883 und die 1781er sich das LAN teilen - das verwirrt mich jetzt nicht nur ein bischen, sondern massiv...

Wenn das wirklich so ist, dann wundert es mich gar nicht, daß du mit der strikteren Trennung durch die FIB u.U. ein Problem hast, das auch nicht vom Konfig-Konverter automatisch aufgelöst werden konnte. Da mußt du dir u.U. über dein Netz nochmal richtig Gedanken machen und die Routen ggf. anpassen.

Gruß
Backslash

[wahltho]

Hallo Backslash,

wahrscheinlich habe ich mich unklar ausgedrückt.

192.168.0.* (Routing Tag 0) ist mein Haupt LAN das der 1783er bedient. Dort ist er mit LAN Port 1 angeschlossen. Der 1783er bedient direkt den Vodafone-Anschluss. In dem Haupt-LAN hängen alle Geräte.

Der 1783er fungiert als Load Balancer für die drei VDSL-Anschlüsse:

192.168.1.* (Routing Tag 1) ist ein LAN zwischen dem 1783er und dem ersten 1781er (Telekom 1), das im ersten 1781er eingerichtet ist. Der 1783er hängt mit seinem Lan Port 2 am LAN Port 1 des ersten 1781er.

192.168.2.* (Routing Tag 1) ist ein LAN zwischen dem 1783er und dem zweiten 1781er (Telekom 2), das im zweiten 1781er eingerichtet ist. Der 1783er hängt mit seinem Lan Port 3 am LAN Port 1 des zweiten 1781er.

Zusätzlich hängen die beiden 1781er zu Wartungs- und Konfigurationszwecken über ihren jeweiligen LAN Port 2 im primären Netz 192.168.0.* (Routing Tag 0) mit einer eigenen IP

WAN-Pakete werden gemäß den eingestellten Routen jeweils von den beiden 1781ern über 192.168.1.* / 192.168.2.* (Routing Tag 1) an den 1783er weitergeleitet und vice versa.

Die Port Forwardings sind in den 1781ern und im 1783er korrespondierend eingerichtet.

Port Forwarding geht also z.b. vom ersten 1781 über 192.168.1.* (Routing Tag 1) an den 1783er und vom 1783er über 192.168.0.* (Routing Tag 0) an das Endgerät

Viele Grüße

Thomas