LCOS 10.40RC1 NAT Problem

[BeckerOl]

Hallo Forum !

Nach Update LCOS 10.32RU4 auf 10.40RC1 funktioniert mit vorgeschaltetem Router und 8er IP-Range Port Forwarding nur noch über die Haupt WAN-Adresse. Nach Zurückkehren zur alten Firmware lassen sich dann keine Änderungen mehr vornehmen. SNMP Fehler 1.2.21.14.1.1, Wert 31; die alten NAT-Einstellungen mit zugewiesener externen IP-Adresse funktionieren aber wieder.

Eine Auflistung via 'cd 2/21/14' zeigt die Werte 31 und 32 an.

Eine Idee ?

Gruß, OB.

[GrandDixence]

Nach dem Zurückkehren auf einen älteren Firmware-Stand muss immer das Konfigurationsbackup (*.lcf) zurückgespielt werden.
Das Konfigurationsbackup (*.lcf) musste mit dem älteren Firmware-Stand erstellt werden.

Ich empfehle vor jedem Firmware-Update ein Konfigurationsbackup (*.lcf) zu erstellen.

Hier macht der Konfigurationsparameter Probleme, welcher in der LCOS-Menüreferenz im Kapitel 2.21.14.1.1 aufgeführt ist.
https://www.lancom-systems.de/docs/LCOS/menuereferenz/

Wenn dieser Konfigurationsparameter mit dem neuen Firmware-Stand hinzugekommen ist, muss das entsprechende "Addendum LCOS xx.yy" konsultiert werden!

[BeckerOl]

Die alte Config im 10.3x Format funktioniert.

Wie sieht es mit dem NAT Fehler in 10.40 aus - hat hier irgendjemand ähnliche Problem =

[Pauli]

Servus,

habe ebenfalls den 1.2.21.14.1.1 Wert 31 Fehler (wurde ja bereits geklärt), aber auch ein Problem mit dem NAT bzw. Port-Forwarding. Sämtliche eingehende Verbindungen (definiert als FW Regel und Forwarding) lösen IDS Alarma aus und werden gesperrt. Sprich meine Services sind nicht mehr von außen erreichbar. Zurück zur 10.32 bringt mit der identischen Konfiguration meine Server wieder online.

Gruß, Pauli

[ittk]

Hier mal der KB-Artikel, lesenwert vor dem Einspielen der LCOS 10.40 als RC...:

https://support.lancom-systems.com/know ... d=37455808

Und bisschen zum Troubeshooting des Port-Forwardings - hier sind die IP-masquerading, IP-Router und Firewall Traces zu empfehlen:

https://support.lancom-systems.com/know ... iert+nicht

Weiterhin lesenswert sind:

https://support.lancom-systems.com/know ... d=32986867

https://support.lancom-systems.com/know ... -Based+NAT

[Pauli]

Vielen Dank für die Links - kannte ich noch nicht.

Allerdings kann ich in Bezug auf meine Konfig und die Probleme darin nichts erkennen. Ich werde mal erneut updaten und dann genauer auf die Traces schauen.

Gruß, Pauli

[ittk]

Habe gerade mal ein einfaches Port-Forwarding mit einem Mobilfunk-WAN mit genau einer oeffentlichen IPv4-Adresse getestet. Port 80 bis 80, kein Port-Mapping, ohne Angabe von Gegenstelle und WAN-IP-Adresse, hat alles einwandfrei funktioniert. Habt Ihr nur Probleme, weil bei Euch mehrere oeffentliche IP-Adressen am WAN genutzt werden?

[Pauli]

Also irgendwie hat sich doch einiges verändert, was Firewall und Routing betrifft. Ich habe ein wenig probiert und getracert, aber werde nicht wirklich schlau daraus. Hier mal ein simples Beispiel:

Ich habe eine FW Regel die auch gezogen wird:

[Firewall] 2019/12/31 22:19:49,595 Devicetime: 2019/12/31 22:19:49,526
Packet matched rule TAG-202-UTM_VLAN-INTRA_VLAN-IOT
DstIP: 172.16.40.51, SrcIP: 192.168.168.100, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x00d4

Die Regel soll normal ein Routing Tag setzen, aber im Trace erscheint: block-route, packet rejected

Im darauf folgenden IP-Router Eintrag steht dann:
[IP-Router] 2019/12/31 22:19:49,595 Devicetime: 2019/12/31 22:19:49,526
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.40.51, SrcIP: 192.168.168.100, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x00d4
Network unreachable (no route) => Discard

Vor der 10.40RC1 war wurden die Pakete getagt und richtig geroutet?

Gruß und guten Rutsch, Pauli

[ittk]

Moin, ein frohes Neues.

Hast Du evtl. von dem LANCOM selbst aus versucht zu pingen?

aktuelle-lancom-router-serie-f41/reihen ... 17874.html

Was sagt ein show bind und Deine Routing-Tabelle (ls /Status/IP-Router/Act.-IP-Routing-Tab), die IP-Netzwerke (ls st/tcp/netw) und Firewall (show filter)?

Aber o. g. Traces haben jetzt nichts mit dem Portforwarding (WAN-seitig fuer eingehende Verbindungen) zu tun....

[Pauli]

Moin, ein frohes Neues.

Moin, wünsche ich Dir auch.

Was sagt ein show bind und Deine Routing-Tabelle (ls /Status/IP-Router/Act.-IP-Routing-Tab), die IP-Netzwerke (ls st/tcp/netw) und Firewall (show filter)?

Ich denke ich habe hier ein Problem gefunden:

172.16.40.0 255.255.255.0 202 192.168.168.249 #Null Static (5) nein

Sprich bei Zielinterface steht #Null. Offensichtlich weiß der Lancom nun nicht mehr wie er an den hier angegebene Router kommt (ist ein weiterer Router im LAN, der auch intern NAT kann, da der LAncom das nicht kann). In der Routingtabelle kann ich aber keine Interface eingeben?

Aber o. g. Traces haben jetzt nichts mit dem Portforwarding (WAN-seitig fuer eingehende Verbindungen) zu tun....

Da hast Du natürlich Recht, aber auch hier habe ich nach dem Update seltsame Phänomene, die ich noch nicht so richtig protokollieren kann - scheinbar geht es mal und scheinbar nicht. Ich habe mal meine FW Regeln überarbeitet (hatte aber keine MAC basierte Regeln etc.) und aktuell scheint es zu funktionieren.

Danke und Gruß, Pauli

[Pauli]

Also zurück zu 10.32 sieht die Eff.-IP-Routing-Tab. ganz anders aus (viel kürzer mit der identischen Konfiguration) und für den genannten Eintrag erscheint auch INTRANET als Gegenstelle.

Sprich das vorhanden Regelwerk der FW und die Routing Tabelle funktioniert auf jeden Fall in der 10.40 nicht mehr wie bisher und muss überarbeitet werden wenn man ein wenig mehr als eine Standardroute mit zwei FW Regeln hat. Allerdings ist mir auch nach Studium des KB Artikels noch nicht klar was und wie ich meine Konfig anpassen muss.

PS: NAT zwischen diversen internen VLANs geht auch mit der 10.40 nicht oder habe ich etwas übersehen (dann könnte ich meine Konfig etwas vereinfachen)?

Pauli

[ittk]

Vielleicht kann backslash etwas zu Deinen Fragen beitragen...

1. Problem / Frage:

Ich denke ich habe hier ein Problem gefunden:

172.16.40.0 255.255.255.0 202 192.168.168.249 #Null Static (5) nein

Sprich bei Zielinterface steht #Null. Offensichtlich weiß der Lancom nun nicht mehr wie er an den hier angegebene Router kommt (ist ein weiterer Router im LAN, der auch intern NAT kann, da der LAncom das nicht kann). In der Routingtabelle kann ich aber keine Interface eingeben?

Also zurück zu 10.32 sieht die Eff.-IP-Routing-Tab. ganz anders aus (viel kürzer mit der identischen Konfiguration) und für den genannten Eintrag erscheint auch INTRANET als Gegenstelle.

Sprich das vorhanden Regelwerk der FW und die Routing Tabelle funktioniert auf jeden Fall in der 10.40 nicht mehr wie bisher und muss überarbeitet werden wenn man ein wenig mehr als eine Standardroute mit zwei FW Regeln hat. Allerdings ist mir auch nach Studium des KB Artikels noch nicht klar was und wie ich meine Konfig anpassen muss.

2. Problem / Frage:

PS: NAT zwischen diversen internen VLANs geht auch mit der 10.40 nicht oder habe ich etwas übersehen (dann könnte ich meine Konfig etwas vereinfachen)?

[geho]

Bei dem Problem mit #Null als Zielinterface kann ich möglicherweise helfen.
Ab der 10.40 ist es in einigen Szenarien nötig, für die Auflösung des Nexthops einer statischen Route, ein Ziel Routingtag mit anzugeben. Dies geschieht durch Anhängen von @ gefolgt von dem Tag an den Nexthop in der Peers Spalte der statischen Routingtabelle. Mit dem Tag wird dann intern ein Lookup in der FIB durchgeführt, um dass Zielinterface zu bestimmen.
Dies ist insbesondere dann nötig, wenn eine statische Route mit einem Tag angelegt wurde, bei welcher dieses Tag nur durch eine Firewallregel zugewiesen werden kann. (Für die einfachen Fälle, bei denen der Nexthop in einem der ARF Netzwerke liegt, versucht ein Konfigkonverter dies automatisch anzupassen.)

[ittk]

Danke fuer die Antwort.

Also muesste Pauli das Nachfolgende in der Spalte (im LANconfig als "Router" bezeichnet) - in der CLI --> (LCS Skript als Spalte "Peer-or-IP" bezeichnet) eintragen, so habe ich Dich jedenfalls verstanden

Code: Alles auswählen

192.168.168.249@202

[geho]

Fast, die Route ist ja vermutlich mit dem Routing Tag 202 eingetragen und im Tag 202 gibt es keine weitere Route, mit der 192.168.168.24 aufgelöst werden kann. Mit @ muss daher ein Tag angegeben werden, in dem eine Route existiert, bei welcher der Nexthop im Prefix der Route liegt und bei der ein Zielinterface bestimmt ist.
Im einfachsten Fall also z.B.

Code: Alles auswählen

192.168.168.249@0

in der Spalte Peer-or-IP