Änderung des Routing Verhaltens zwischen LCOS 10.32 und LCOS 10.50

[Thomas [NU]]

Hallo zusammen,

ich habe mit einem 1784VA folgendes Problem:

Der 1784 hängt an drei DSL Leitungen, die über die Loadbalancing Funktion des Routers verbunden sind.

Innen vier Netze über VLAN.

In einem der Netze hängt ein Server auf dem eine 3CX Telefonanlage läuft. Die VoIP Funktionalität des Routers wird nicht genutzt.

Solange der Router mit LCOS 10.32RU10 läuft, funktioniert alles einwandfrei.

Wird ein Upgrade auf LCOS 10.50 (egal welche Version) durchgeführt, kommt es zu folgenden Problemen:

Eingehende Anrufe auf einem Teil der SIP Trunks (Telekom) kommen bei der 3CX nicht mehr an.

Daneben verhält sich der VPN Tunnel zum Router auch komisch. Teilweise werden SMB Verbindungen zu internen Servern zwar hergestellt, aber es fließen dann keine Daten.

Alles irgendwie sehr merkwürdig.

Ich habe die ganzen Routing Regeln genauso wie die Firewall Regeln kontrolliert. Scheint alles zu passen, zumal ja unter LCOS 10.32 alles funktioniert, wie es soll....

Habe keine Idee mehr, wo ich noch nachgucken könnte. Habt Ihr Tips für mich?

Viele Grüße
Thomas

[backslash]

Hi Thomas [NU]

zwichen 10.32 und 10.50 hat sich jede Mnge getan - so wurde die Routing-Engine ausgetauscht, was schon anhand er "effektiven Routing-Tabelle" (/Status/IP-Router/Act.-IPv4-Routing-Tab.) deutlich wird.
Daher haben Aussagen a'la

zumal ja unter LCOS 10.32 alles funktioniert, wie es soll....

keinerlei Bedeutung...

So kapselt die neue Routung-Engine beispielsweise Routing-Kontexte stärker als es die alte getan hat, was zur Folge hat, daß bei Routen mit einem Next Hop, u.U. dem Next-Hop auch ein Routing-Tag mitgegeben werden muß (Next-Hop-IP@Tag), wenn sich der Kontext ändert

Desweiteren wurde die NAT-Engine überarbeitet, was zur Folge hat, daß (UDP-) Sessions nun zwingend neue Port-Mappings bekommen, wenn sie einmal "hausgealtert" sind. Hier mußt du jetzt zwingend darauf achten, daß der UDP-Timeout der Maskierung/Firewall größer ist als das Re-Registrierungs-Intervall der TK-Anlage.

Bei Problemen hilft ansonsten i.A. ein IP-Router-Trace, um zu sehen wie Pakete laufen

Zum Thema

Daneben verhält sich der VPN Tunnel zum Router auch komisch. Teilweise werden SMB Verbindungen zu internen Servern zwar hergestellt, aber es fließen dann keine Daten.

fällt mir höchstens ein: überprüf mal die MTU des VPN-Tunnels und stelle sie ggf. manuell ein

Gruß
Backslash

[hyperjojo]

hi,

Daneben verhält sich der VPN Tunnel zum Router auch komisch. Teilweise werden SMB Verbindungen zu internen Servern zwar hergestellt, aber es fließen dann keine Daten.

fällt mir höchstens ein: überprüf mal die MTU des VPN-Tunnels und stelle sie ggf. manuell ein

Dazu gibt es ja etwas in den Release Notes der 10.50 RU5. Könnte dein Fehlerbild erklären.

Code: Alles auswählen

Für ein Interface mit noch nicht ausgehandelter MTU wurde ein Standard-
Wert von 1280 Bytes verwendet. Da die Anpassung an die MTU nicht korrekt
funktionierte, wurde weiterhin der Standard-Wert von 1280 Bytes verwendet.
Dies führte dazu, dass größere Pakete mit gesetztem ‚Don‘t fragment‘
Flag über eine VPN-Verbindung nicht übertragen werden konnten und die
Kommunikation somit stark gestört oder nur sehr langsam möglich war.

Gruß hyperjojo

[Thomas [NU]]

Huhu Ihr beiden,

das scheint es gewesen zu sein.

Timeouts angepasst und MTU vergrößert.

Danke!

Viele Grüße
Thomas