Load Balancing /Policy Based Routing & Remotedesktop-Pro

[Michael76]

Hallo liebe Lancom-Experten!
Hoffe ihr könnt mir helfen, hänge an folgendem Problem fest:

An unserem 1821+ sind 2 DSL Leitungen (DSL/SDSL) per Load Balancer zusammengefasst.

Die (dnyamische) IP-Adresse einer jeden Leitung wird per Aktions-Tabelle in einen eigenen DynDNS-Account geschrieben (nennen wir diese hier mal "leitung1.dyndns.org" bzw. "leitung2.dyndns.org"),
z.B. für Remote-Desktop - Erreichbarkeit.

Dadurch ist auch bei Ausfall einer DSL-Leitung immer noch eine Einwahl auf der anderen Leitung möglich.

Der Einfachheit halber für die Problembeschreibung sei unser Terminal Server in diesem Falle mal direkt auf Port 3389 per Remotedesktop erreichbar (bitte jetzt keine Diskussion über Einwahlsicherheit anfangen).
Hierzu existiert ein entsprechender Eintrag in der Port-Forwarding Tabelle: (Port 3389 an Terminalserver, beliebige Gegenstelle).

Dies funktioniert soweit wunderbar; Remotedesktop funtioniert sowohl über Leitung1 als auch über Leitung2.

Nun sollen aber noch per Policy Based Routing gezielt bestimmte Dienste auf die Leitungen verteilt werden;
z.B. WEB über Leitung1/DSL, MAIL über Leitung2/SDSL usw.

Dies habe ich so wie in den Beiträgen
http://www.lancom-forum.de/topic,7832,- ... ncing.html bzw.
http://www.lancom-forum.de/topic,8290,- ... ncing.html eingestellt;
also 2 zusätzliche Default-Routen erstellt, eine für jede DSL-Leitung mit Routing-Tags 1 bzw. 2, dann Firewall-Regeln für WEB und MAIL angelegt in denen die gewünschten Tags zugewiesen werden.

Das Problem ist, sobald ich diese zwei neuen Default-Routen aktiviere, funktioniert die oben beschriebene Remotedesktop-Einwahl nicht mehr!
Der Remotedesktop-Client meldet bei Verbindungsherstellung sofort einen Fehler; die IP-Adressen der beiden DSL-Leitungen sind aber anpingbar.

Sobald das Policy Based Routing wieder deaktiviert wird (z.B. Ausschalten der zusätzlichen Default-Routen), funktioniert Remotedesktop wieder.

Wo liegt mein (Denk)Fehler bzw. wer kann mir helfen, diese beiden Aufgaben unter einen Hut zu bringen (RDP über 2 Leitungen + Policy Based Routing)?

Für Eure Hilfe schon vorab vielen herzlichen Dank!
Michael

[backslash]

Hi Michael76

mach doch mal im Fehlerfall einen IP-Router-Trace (im Telnet trace # ip-router eingeben

Gruß
Backslash

[Michael76]

Hallo backslash,

vielen dank für den tip mit dem trace!

zunächst einmal der trace bei funktionierendem remotedesktop (routen für tags 1 und 2 ausgeschaltet):

einkommender rdp auf leitung #1:
[IP-Router] 2009/04/09 07:29:09,460
IP-Router Rx (MVOX, RtgTag: 0):
DstIP: 10.1.50.12, SrcIP: 145.254.240.183, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3176, Flags: S
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2009/04/09 07:29:09,460
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 145.254.240.183, SrcIP: 10.1.50.12, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3176, SrcPort: 3389, Flags: SA
Route: WAN Tx (MVOX)

einkommender rdp auf leitung #2:
[IP-Router] 2009/04/09 07:19:43,380
IP-Router Rx (S-DSL, RtgTag: 0):
DstIP: 10.1.50.12, SrcIP: 145.254.240.183, Len: 57, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3166, Flags: PA
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2009/04/09 07:19:43,500
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 145.254.240.183, SrcIP: 10.1.50.12, Len: 40, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3166, SrcPort: 3389, Flags: A
Route: WAN Tx (S-DSL)


sobald ich nun die routen für tags 1 und 2 aktiviere funktioniert die remotedesktop-einwahl nicht mehr und der trace sieht so aus:

einkommender rdp auf leitung #1:
[IP-Router] 2009/04/09 08:26:46,150
IP-Router Rx (MVOX, RtgTag: 1):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3195, Flags: S
Route: WAN Tx (MVOX)

[IP-Router] 2009/04/09 08:26:49,190
IP-Router Rx (MVOX, RtgTag: 1):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3195, Flags: S
Route: WAN Tx (MVOX)

[IP-Router] 2009/04/09 08:26:55,210
IP-Router Rx (MVOX, RtgTag: 1):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3195, Flags: S
Route: WAN Tx (MVOX)


einkommender rdp auf leitung #2:
[IP-Router] 2009/04/09 08:25:59,590
IP-Router Rx (S-DSL, RtgTag: 2):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3194, Flags: S
Route: WAN Tx (S-DSL)

[IP-Router] 2009/04/09 08:26:02,580
IP-Router Rx (S-DSL, RtgTag: 2):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3194, Flags: S
Route: WAN Tx (S-DSL)

[IP-Router] 2009/04/09 08:26:08,600
IP-Router Rx (S-DSL, RtgTag: 2):
DstIP: 10.1.50.12, SrcIP: 145.254.107.66, Len: 48, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 3389, SrcPort: 3194, Flags: S
Route: WAN Tx (S-DSL)


er schickt nun also die pakete nicht wie oben erst ins LAN, sondern gleich wieder über die WAN-schnittstelle raus?
anbei noch ein screen meiner routing-tabelle, sollte eigentlich so wie in den anleitungen für PBR beschrieben eingestellt sein...
stehe leider momentan total auf dem schlauch!

jede hilfe/anregung willkommen
Gruß,
Michael

[backslash]

Hi Michael76

hier beißt sich policy based routing und ARF... Die einkommenden Pakete sind mit dem Tag der jeweiligen Gegenstelle getaggt und es findet sich kein ARF-Netz mit diesem tag, weshalb die Pakete dann wieder auf der ungetaggten Defaultroute rausgesendet werden...

Als erstes stellt sich die Frage: Wieso haben die Pakete das Tag der Leitung? Hast du vielleicht die Erzeugung der WAN-Tags (Kommunikation -> Gegenstellen -> WAN-Tag-Erzeugung) von "manuell" auf "automatisch" umgestellt? Wenn ja: stell es wieder zurück auf "manuell", denn dann erhalten alle eingehenden Pakete das Tag 0

Als zweites: die Sperr-Routen, die im Auslieferungzustand in der Routing-Tabelle stehen, haben ihren Sinn. In deinem Fall würde die Sperr-Route für das 10.x.x.x Netz auch verhindern, daß das Paket wieder auf das WAN gesendet würde...

Also: Stell die WAN-Tag-Erzeugung auf "manuell" und trage die Sperr-Routen wieder ein

Gruß
Backslash

[Michael76]

backslash, einfach der wahnsinn!

es funktioniert!
tausend dank!!!

du hattest recht, die WAN-Tag-Erzeugung stand auf "automatisch"!
ich hatte ja schon soviel rumprobiert...
daher waren auch die default Sperr-Routen nicht mehr drin

danke nochmal für deine erstklassige hilfe!! bin begeistert!
Gruß,
Michael