LCOS 9.10 RU1 - Problem mit der Erreichbarkeit von Subnetzen

[Chaosphere64]

Kurzes Feedback: Ich habe heute die 9.10 RU 1 Version von LCOS auf einem 1781-VA installiert. Danach konnte ich zwei von vier lokalen Subnetzen (IPv4 Netze) nicht mehr erreichen.

Pathping / Traceroute / Ping / WinMTR etc. ergaben, dass das Zielnetz in beiden Fällen nicht erreichbar war. Ein Trace ergab keinerlei Probleme mit der Firewall, das Routing ging zumindest soweit, dass die Gateway IP des 1781-VA im jeweiligen Subnetz (x.x.x.1) erreichbar war, Hosts in dem Subnetz jedoch nicht!

Die Konfiguration war unverändert. Das Downgrade auf die Vorgängerversion LCOS 9.10 hat das Problem sofort gelöst.

[MariusP]

Hi,
Geht es hier um VPN-Netze?
Gruß

[Jirka]

Hallo,

Geht es hier um VPN-Netze?

nein, um lokale ARF-Netze.

Ich habe das gleiche Problem. Allerdings schon seit 2 Wochen:
Die 9.10.0370 lief noch ohne Probleme. Die Probleme fingen mit der 9.10.0375 an (Versionen dazwischen wurden nicht online gestellt) und mit der 9.10.0382 sind die Probleme immer noch.
Es sind zwei ARF-Netze konfiguriert. Verwaltung/Intranet mit Schnittstellen-Tag 1 und ein Schulnetz mit Schnittstellen-Tag 2.
Das Schulnetz darf auf eine IP-Adresse (Domänencontroller) aus dem Intranet zugreifen, dafür wird in der Firewall auch das Routing-Tag gesetzt.
(Eigentlich kommt das mit den Schnittstellen-Tags noch daher, dass es da früher keine Deny-All-Regel in der Firewall gab.)
Mit der 9.10.0375 funktioniert das nicht mehr. Keine Ahnung warum nicht.
Ein 'ping -a LANCOM-IP-aus-Schulnetz IP-des-Domänencontrollers' geht dann auch nicht mehr, vorher ging es.

Traces bei mir auch ohne irgendwelche verwertbaren Infos. Da ich keinen Anhaltspunkt habe, habe ich mich bisher nicht getraut, das als Bug reinzustellen. Dass gestern die 9.10.0382 als RU1 freigegeben wurde, hatte mich dann ehrlich gesagt etwas erstaunt (ich hätte damit erst in 14 Tagen gerechnet mit einer neueren Build).

Viele Grüße,
Jirka

P.S.: Backslash, falls Du mal schauen möchtest, ich könnte jetzt in den Abendstunden auf die 9.10.0382 umschalten und dann könntest Du selber mal schauen. Remotezugriff auf Rechner hätte ich allerdings nicht anzubieten, oder nur im falschen Netz. Könnte man aber für morgen organisieren.

[Jirka]

Hallo,

so, ich habe mir das Problem jetzt noch mal ausführlich angeschaut.

/Status/IP-Router/Filter-List und /Setup/IP-Router/Firewall/Rules sind in beiden Firmware-Versionen identisch, da hat sich also nichts verändert. (Ich hatte ehrlich gesagt damit gerechnet, dass ja vielleicht mal das Problem, dass LANconfig die Firewall-Regeln nicht so sortiert, wie das LCOS selber, angegangen wird, aber da hat sich nichts geändert.)

Im IP-Router-Trace kommt folgende Fehlermeldung:

Code: Alles auswählen

[IP-Router] 2015/09/01 20:21:37,049
IP-Router Rx (LAN-1, SCHULNETZ, RtgTag: 1):
DstIP: 10.1.1.3, SrcIP: 10.1.2.66, Len: 75, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 58471
Network unreachable (no route) => Discard

Für mich ist das unverständlich, weil die Route ja da ist:

Code: Alles auswählen

/Status/IP-Router/Act.-IP-Routing-Tab. (Auszug)
> l

IP-Address       IP-Netmask       Rtg-tag  Gateway          Peer              Distance  Masquerade  Type
------------------------------------------------------------------------------------------------------------
10.1.1.0         255.255.255.0    1        10.1.1.1         INTRANET          0         No          Intranet
10.1.2.0         255.255.255.0    2        10.1.2.1         SCHULNETZ         0         No          Intranet

Ein Ping zeigt das gleiche Ergebnis, wenn auch die letzte Zeile im IP-Router-Trace komischerweise anders formuliert ist (sehr nervig übrigens, wenn man z. B. nach der obigen Ausgabe filtert, aber dieses Paket dann durch den Filter fällt...):

Code: Alles auswählen

> ping -a 10.1.2.1 10.1.1.2

 Network unreachable by localhost

 ---10.1.1.2 ping statistic---
 56 Bytes Data, 1 Packets transmitted, 0 Packets received, 100% loss

root@AAAABBBB:/
>
[IP-Router] 2015/09/01 20:45:39,455
IP-Router Rx (intern, RtgTag: 2):
DstIP: 10.1.1.2, SrcIP: 10.1.2.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000d, seq: 0x0000
no route =>  discard frame

Versieht man das Intranet mit Schnittstellen-Tag 0 ist das Problem beim Ping erledigt:

Code: Alles auswählen

> ping -a 10.1.2.1 10.1.1.2

[IP-Router] 2015/09/01 20:49:34,391
IP-Router Rx (intern, RtgTag: 2):
DstIP: 10.1.1.2, SrcIP: 10.1.2.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000e, seq: 0x0000
Route: LAN-1 Tx (INTRANET):

    56 Byte Packet from 10.1.1.2 seq.no=0 time=2.006 ms
[IP-Router] 2015/09/01 20:49:35,391
IP-Router Rx (intern, RtgTag: 2):
DstIP: 10.1.1.2, SrcIP: 10.1.2.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000e, seq: 0x0001
Route: LAN-1 Tx (INTRANET):

    56 Byte Packet from 10.1.1.2 seq.no=1 time=0.971 ms

 ---10.1.1.2 ping statistic---
 56 Bytes Data, 2 Packets transmitted, 2 Packets received, 0% loss

Trotzdem existiert aber noch folgendes Problem:

Code: Alles auswählen

[IP-Router] 2015/09/01 20:51:05,198
IP-Router Rx (LAN-1, SCHULNETZ, RtgTag: 2):
DstIP: 10.1.1.3, SrcIP: 10.1.2.66, Len: 83, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 58982
Network unreachable (no route) => Discard

Irgendwie komisch, dass dieses Paket hier mit RtgTag 2 angegeben ist, während es ganz oben mit RtgTag 1 steht. Und die Firewall-Regel, die das Tag von 2 zu 1 ändert, ist nach wie vor aktiv! Wenn ich das Schnittstellen-Tag vom Intranet wieder von 0 auf 1 ändere, dann steht da wieder RtgTag 1 drin - sehr komisch:

Code: Alles auswählen

[IP-Router] 2015/09/01 21:06:17,247
IP-Router Rx (LAN-1, SCHULNETZ, RtgTag: 1):
DstIP: 10.1.1.3, SrcIP: 10.1.2.66, Len: 83, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 63208
Network unreachable (no route) => Discard

Setze ich beide ARF-Netze auf das Schnittstellen-Tag 0, dann geht das Paket durch:

Code: Alles auswählen

[IP-Router] 2015/09/01 21:20:56,119
IP-Router Rx (LAN-1, SCHULNETZ, RtgTag: 1):
DstIP: 10.1.1.3, SrcIP: 10.1.2.66, Len: 75, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 52375
Route: LAN-1 Tx (INTRANET):

Also da muss irgendwas mit den Schnittstellen-/Routing-Tags nicht mehr stimmen.

Vielen Dank und viele Grüße,
Jirka Reimer

[LoUiS]

Hi,

kannst Du das bitte mal mit der Build 0374 gegentesten, ob es damit noch funktioniert, um den Zeitraum einzugrenzen.
Ich habe die Build gerade auf den FTP Server kopiert.


Ciao
LoUiS

[Chaosphere64]

Hi,
Geht es hier um VPN-Netze?
Gruß

Nein. Vier normale ARF-Netze für Administration, restriktiven Internet Zugriff, Voice und Print (verschiedene VLANs, verschiedene Schnittstellen Tags). Sobald ich die RU 1 eingespielt habe, komme ich aus dem VLAN für Administration (VLAN ID 1, Schnittstellen Tag 0) nicht mehr auf zwei andere Subnetze (genauer: Hosts in diesen Subnetzen, der LANCOM als Gateway im jeweiligen Subnetz ist nach wie vor erreichbar (ICMP)). Die Konfiguration lief bisher ohne jedes Problem.

[Jirka]

Hallo LoUiS,

die 9.10.0374 funktioniert diesbezüglich noch fehlerfrei. Daher ist der Fehler mit der Build 0375 reingekommen.

Viele Grüße,
Jirka

[Rougu]

Hi,

ein funktionierender Workaround ist, dass man für die an lokale Interfaces gebundenen Netze eine explizite Route mit der eigenen IP-Adresse des LANCOM als Next-Hop definiert.

Beispiel:

IP4-Adresse 10.1.252.1/24 an VLAN-Interface "VOIP" mit Routing-Tag 4

Workaround:

IP4-Routing-Tabelle: 10.1.252.0/24 mit Router 10.1.252.1 und Routing-Tag 4

Gruß,

Rougu

[LoUiS]

Guten Morgen,

ich habe gerade eine neue Beta Build LCOS 9.10.0406 auf den FTP Server kopiert, in dieser ist der "Work-Around" nicht mehr notwendig.


Ciao
LoUiS

[Jirka]

Hallo LoUiS,

stimmt.

Vielen Dank und viele Grüße,
Jirka

[Chaosphere64]

Nachdem nun fast zwei Monate ins Land gegangen sind kurz die Frage: Gibt es ein ETA für ein RU2? Dieser Fehler ist ja nun doch recht gravierend und macht den Einsatz in ARF-Szenarien (für mich DAS LCOS Feature überhaupt) schwierig bis unmöglich. Andererseits scheint ja die RU1 in vielen Fällen stabiler zu laufen als die Release Version.

[LoUiS]

Hi,

eine RU3 wird in Kuerze freigegeben.


Ciao
LoUiS

[Chaosphere64]

Vielen Dank für die Info und generell einmal für den Support im Forum. Auch das ist für mich ein echter Mehrwert und Grund LANCOM einzusetzen!