QOS für RDP über VPN

[TschungTschung]

Hi LANCOM´ler

also ich stehe etwas auf dem Schlauch... wir haben eine Site to Site Verbindung zwischen Hauptstandort A (WLC-4006) und Außenstelle B (1711+VPN). Die Kollegen von B wählen sich via RDP auf einen Terminalserver in A ein.
Derzeit haben wir jedoch ziemlich Traffic-lastige Anwendungen laufen, die Projektdaten von A nach B übertragen und somit die Leitung "verstopfen".

Jetzt will ich 1024kbit/s Tx vom A reservieren....

Also muss doch die Regel wie folgt lauten, oder:
Object: Accept
QOS: Bandbreite garantieren (Für Default Route) 1024kbit/s, erzwungen
Verbindungsquelle: LOCALNET
Verbindungsziel: Netz B
Quellprotokoll: RDP
Zieldienste: alle

Im LANMonitor wird leider keine Reservierung angezeigt, also gehe ich mal davon aus, dass was falsch ist!
Vielen Dank schon mal

[Bernie137]

Hi,

benennen doch bitte mal die Up- und Download Geschwindigkeiten der Internetzugänge für A und B.

Viele Grüße
Heiko

[TschungTschung]

A ist symetrisch mit 4096KBit/s und B ist mit 32768KBit/s down und 4096 up benannt.
Also wurde bereits unter Konfiguration --> Schnittstellen --> WAN --> Interface-Einstellungen eingetragen.

Hm,.. muss man evtl bei der Gegenstelle B auch eine Regel erstellen?

[Bernie137]

Moin,

A ist symetrisch mit 4096KBit/s und B ist mit 32768KBit/s down und 4096 up benannt.

Das bedeutet, es kann max. zwischen den Standorten mit 4096KBit/s gearbeitet werden (jeweils der Upload am Standort ist die Begrenzung) abzüglich Overhead.

Also wurde bereits unter Konfiguration --> Schnittstellen --> WAN --> Interface-Einstellungen eingetragen.

Das richtig und gut, weil Vorraussetzung, dass es in der Firewall überhaupt "greift".

Hm,.. muss man evtl bei der Gegenstelle B auch eine Regel erstellen?

Prinzipiell ja, sonst ist es sinnlos. Aber es hat erst mal nix mit der QoS Anzeige im LANmonitor von Router A zu tun.

Jetzt will ich 1024kbit/s Tx vom A reservieren....

Also muss doch die Regel wie folgt lauten, oder:

Allgemein: Regel aktivieren + Diese Regel hält Verbinungszustände nach
Object: Accept
QOS: Bandbreite garantieren (Für Default Route) 1024kbit/s, erzwungen => entweder Default Route abhaken oder stattdessen "Für VPN-Route", Global bitte setzen
Verbindungsquelle: LOCALNET => Gib die IPs der Server an
Verbindungsziel: Netz B
Quellprotokoll: RDP
Zieldienste: alle
Diese Regel in der Prioliste der Firewall ganz nach oben!

Prinzipiell wirst damit aber keine bahnbrechenden Erfolge bekommen, solange reger Querverkehr auf den Leitungen ist. Ich habe die gleiche Konstellation im Einsatz (gehabt) und habe begonnen Dienstetrennung zu machen. Ein 16000 DSL kostet nicht die Welt und ich habe über DSL 16000 das "normale" Surfen abgewickelt. Außerdem sollte man sonstigen Querverkehr (VPN + Internet) "einbremsen", auch mit Firewall an beiden Standorten. Im Standort B brauchst auf alle Fälle ne Firewall Regel höchster Prio, die den Upload für RDP in den VPN Tunnel freihält, sagen wir 512 KBit/s. Das ist für Tastatureingaben und Mausbewegungen, sonst wird es sehr hakelig. Im Standort A würde ich eher 2048KBit/s reservieren als nur 1024KBit/s. Aber wie viele machen überhaupt RDP im Standort B?

Viele Grüße
Heiko

[TschungTschung]

Hi Danke für die Antwort....

Allgemein: Regel aktivieren + Diese Regel hält Verbinungszustände nach

War natürlich gesetzt

QOS: Bandbreite garantieren (Für Default Route) 1024kbit/s, erzwungen => entweder Default Route abhaken oder stattdessen "Für VPN-Route", Global bitte setzen
Verbindungsquelle: LOCALNET => Gib die IPs der Server an

Danke

Diese Regel in der Prioliste der Firewall ganz nach oben!

erledigt...

Leider noch nicht mehr Erfolg

Prinzipiell wirst damit aber keine bahnbrechenden Erfolge bekommen, solange reger Querverkehr auf den Leitungen ist. Ich habe die gleiche Konstellation im Einsatz (gehabt) und habe begonnen Dienstetrennung zu machen. Ein 16000 DSL kostet nicht die Welt und ich habe über DSL 16000 das "normale" Surfen abgewickelt.

Das machen wir bereits. Die beiden Standorte haben jeweils eine zweite Leitung (anderer Routing Tag) und über diese wird der Internettraffic geleitet. (HTTP/HTTPS)

Aber wie viele machen überhaupt RDP im Standort B?

unteschiedlich zwischen 3 und 10 Leuten

u.a. habe ich dann diesen Link gefunden und nun bin ich total verwirrt :-/
http://www.lancom-forum.de/viewtopic.ph ... 72&p=57101

Dienste und Netze sind hier genau vertauscht.....

[Bernie137]

Und die Änderungen werden im LANmonitor erst nach erneuter Einwahl des Internetzugangs angezeigt.

Allerdings ist die Bandbreiten-Reservierung für RDP gar nicht so trivial. Ich habe das aufgrund Deiner Anfrage hier noch mal überdacht. Daher stelle ich es gleich als Frage an alle anderen in den Raum.

Richtig ist in der Zentrale, wo die Zerminal Server stehen: Wenn man als Zieldienst RDP=3389 angibt und nicht als Quelle. Dann wird laut LANmonitor die Bandbreite für Tx reserviert, andernfalls immer für Rx (Fußnote 1)? So weit so gut.

Wenn ich das jetzt auseinandernehme, komme ich aber auf einen Widerspruch! Für RDP muss man am Standort der Terminal Server sinnvollerweise Upload Geschwindigkeit freihalten, aber eben nicht für ausgehende Verbindungen nach TCP3389! Ein Client sendet an den Terminal Server eingehend an 3389 und die Bildschrimausgaben werden ausgehend an ausgehandelte Ports geschickt, z.B. 31245 o.a. Die Regel sieht schön im LANmonitor aus, ist aber meiner Meinung nach sinnlos. Denn hier wird Bandbreite ausgehend an 3389 reserviert. Habe ich jetzt einen Denkfehler???

(Fußnote 1)
Anders habe ich keine Tx Reservierung hinbekommen. Dazu hatte ich die Firewall Regel Object:
Variante 1:
Accept
QOS: Bandbreite garantieren 2048kbit/s, erzwungen
Verbindungsquelle: Alle
Verbindungsziel: <IPs der Terminal Server>
Quellprotokoll: alle
Zieldienste: alle
= Reservierung Rx

Variante 2:
Accept
QOS: Bandbreite garantieren 2048kbit/s, erzwungen
Verbindungsquelle: <IPs der Terminal Server>
Verbindungsziel: Alle
Quellprotokoll: alle
Zieldienste: alle
= Reservierung Rx

Variante 3:
Accept
QOS: Bandbreite garantieren 2048kbit/s, erzwungen
Verbindungsquelle: Alle
Verbindungsziel: Alle
Quellprotokoll: RDP
Zieldienste: alle
= Reservierung Rx

Variante 4:
Accept
QOS: Bandbreite garantieren 2048kbit/s, erzwungen
Verbindungsquelle: Alle
Verbindungsziel: Alle
Quellprotokoll: alle
Zieldienste: RDP
= Reservierung Tx, meiner Meinung nach Unsinn, siehe oben (habe ich so schon 5 Jahre am laufen)

Hab ich nen gewaltigen Denkfehler drinnen, oder was läuft da falsch?

Viele Grüße
Heiko

[Bernie137]

Moin,

so, ich habe jetzt mal nachgelesen. Ist eben schon wieder 5 Jahre her, als ich es damals eingerichtete hatte. Die Firewall Regel in der Zentrale muss lauten wie folgt:

Allgemein: Regel aktivieren, hohe Prio, Diese Regel hält Verbindungszustände nach
Aktionen: Accept
QoS: nur für gesendete Pakete, Bandbreite garantieren 2048kbit/s global
Verbindungsquelle: Alle
Verbindungsziel: Alle
Quellprotokoll: alle
Zieldienste: RDP

Dann die Internet-Verbindung neu "einwählen" lassen und vom entfernten Standort eine neue RDP Sitzung aufbauen. Mit

Code: Alles auswählen

trace + Firewall @ +TCP +"port: 3389"

sollte man nun erkennen, dass die Regel matcht.

Erklärung:
Es kommt bei der Firewall darauf an, wer Initiator ist. Das heißt der RDP Client baut als erstes eine Verbindung zum Zieldienst TCP3389 auf. Darauf hin antwortet der Server auf einem Highport zurück - und das weis die Firewall. Wichtig ist halt in der QoS Regel "nur für gesendete Pakete".

Viele Grüße
Heiko

[TschungTschung]

Hi Bernie,

vielen Dank für deine großartige Hilfestellung.
Also, angezeigt wird es im LANMonitor nun wie gewünscht. Je nach "erzwungen" oder nicht, auch als "reserviert" und "bevorzugt".
Zum Glück bin ich nicht der Einzige, der hier verwirrt war bzw. ist

Dann die Internet-Verbindung neu "einwählen" lassen und vom entfernten Standort eine neue RDP Sitzung aufbauen. Mit
Code:
trace + Firewall @ +TCP +"port: 3389"
sollte man nun erkennen, dass die Regel matcht.

Leider habe ich hier noch keinen Erfolg.

Am Standort B brauch ich ja eigentlich keine Regel, oder?
Bandbreite ist dort genügend vorhanden und wird nicht voll genutzt.

[Bernie137]

Hi,

"Erzwungen" würde ich nicht setzen.

Leider habe ich hier noch keinen Erfolg.

Wenn es im LANmonitor angezeigt wird, dann hat die Regel gematcht.

Am Standort B solltest unbedingt auch eine Regel anlegen, sonst ist es sinnlos, gerade bei Querverkehr. Ich habe da stehen:

Allgemein: Regel aktivieren, hohe Prio, Diese Regel hält Verbindungszustände nach
Aktionen: Accept
QoS: nur für gesendete Pakete, Bandbreite garantieren 384kbit/s global (sehr wichtig, damit Maus- und Tastatureingaben nicht ruckeln)
QoS: nur für empfangene Pakete, Bandbreite garantieren 2048kBit/s global
QoS: PMTU 256 (kann man in der Zentrale auch nachpflegen)
Verbindungsquelle: Alle
Verbindungsziel: Alle
Quellprotokoll: alle
Zieldienste: RDP

Diese Außenstelle hat bei uns 12000 MBit Down und 1 MBit Upload (Bündelung 2x DSL6000).

Viele Grüße
Heiko

[TschungTschung]

Hi, nochmal zwei kurze Verständnis-Fragen, da bisher noch nicht recht viel merkbar rumgekommen ist:

1. Bei

trace + Firewall @ +TCP +"port: 3389"

müsste doch ständig Aktivität zu sehen sein, oder? Leider kommt bei mir gar nix

und 2.
lasse ich an einem Notebook neben mir ständig den LANMonitor mitlaufen (mit DSL Durchsatz Graph) um einfach mal zu sehen wie die Auslastung ist...
Zwischenzeitlich verschwindet mal wieder die "Reservierung" im Sinne von Tx bevorzugt: 0 kBit/s - kurze Zeit später hat es sich wieder eingerenkt.
Kommt hier die Regel dann zum Einsatz?

Vielen Dank schon mal...

Viele Grüße

[Edit] Noch eine Frage.... PMTU 256,... ist das nicht etwas wenig!? Sind hier nicht etwas wenig Daten und zu viel "Verwaltungs"Informationen enthalten?

[Bernie137]

Hi,

bei dem Trace trace + Firewall @ +TCP +"port: 3389" wird geschaut:
1. besteht schon eine Reservierung = keine Aktivität mehr im Trace (weil Reservierung besteht ja schon)
2. besteht keine Reservierung = dann wird genau einmal gemtacht (um die Reservierung zu setzen)
Das was Du erwartest ist trace + IP-Router @ +TCP +"port: 3389" Vorsicht, macht Stress auf dem Router!

Zwischenzeitlich verschwindet mal wieder die "Reservierung" im Sinne von Tx bevorzugt: 0 kBit/s - kurze Zeit später hat es sich wieder eingerenkt.

Wenn keine RDP Sitzung mehr aktiv ist, dann verschwindet die Reservierung (weil bei QoS ja nicht erzwungen wird und das ist auch gut so). Kommt wieder eine Sitzung, dann wird wieder reserviert.

lasse ich an einem Notebook neben mir ständig den LANMonitor mitlaufen (mit DSL Durchsatz Graph) um einfach mal zu sehen wie die Auslastung ist...

Dafür kann ich Tools wie PRTG empfehlen. Einerseits für die Auslastung der Bandbreite, andererseits für die Latenzwerte bzw. ob mal eine Verbindung weggebrochen ist (besonders Nachts und an So- und Feiertagen, da Kurbeln die Provider manchmal mächtig rum und tun so, als wäre nichts gewesen). Bei mehreren Filialen (Sternförmig) erkennt man somit schneller, welche Leitung ein Problem hat.

Noch eine Frage.... PMTU 256,... ist das nicht etwas wenig!? Sind hier nicht etwas wenig Daten und zu viel "Verwaltungs"Informationen enthalten?

Ja, das ist gut möglich. Das sind Zahlen aus der Vergangenheit:
- bei kleineren DSL-Bandbreiten
- (aus heutiger Sicht viel zu kleiner Bandbreitenangabe von MS) mit 40kBit/s
- und kleinem Bildschirm beim User (17 Zoll 1024x786).
Bei mir hat es sich nicht bewährt und ich habe es mit PMTU wieder verworfen bzw nicht mehr weiter getestet, weil ich kaum noch Querverkehr auf der Leitung habe, die Leitung "moderner" (niedrigere Latenz als früher) und "dicker" geworden ist. Eine moderne RDP Sitzung (wo man auch das Scrollrad im PDF nutzen kann) würde ich mit einer Auflösung 1680x1024 von 150kBit/s + X im Download bzw. TerminalServer-seitig im Upload schätzen.

Viele Grüße
Heiko