Feature-Wunsch Firewall Dienst-Objekte: QUIC

[Jirka]

Hallo zusammen,

in einer langen TeamViewer-Sitzung heute kam bei einem Kunden von mir nach der Aufklärung über QUIC eine gewisse Unverständnis auf, warum LANCOM denn das Protokoll nicht inzwischen als Dienst-Objekt im Default in der Firewall aufgenommen hat (mit UDP 443), diese Frage bzw. diesen Feature-Wunsch möchte ich hiermit weitergeben.
Interessant an dieser Stelle ist, dass ich vor gut 5 Jahren beim Googeln von UDP Port 443 prompt auf einen Blog-Beitrag eines Forumsmitglieds hier gestoßen war, John Lose, hier bekannt als joeMJ, der sich leider lange nicht mehr hier sehen gelassen hat, trotzdem nochmal danke an dieser Stelle. Es gab also auch schon vor Jahren andere LANCOM-Nutzer, die darauf stießen, dass man hier eigentlich mit der Zeit gehen müsste und normalen IT-Administratoren eine Liste an verbreiteten Diensten zur Verfügung stellen sollte, damit diese schneller zu einem fehlerfreien Deny-All-Regelwerk kommen.

Vielen Dank und viele Grüße
Jirka

[tstimper]

Hi Jirka,

das ist ja interessant, war mir bisher nirgends aufgefallen.

So wie es ausssieht, können das derzeit nur die Browser Google Chrome und Opera nutzen.

Siehe https://www.ionos.de/digitalguide/hosti ... udp-basis/

Und UDP hat ja keine Sessions und somit gibt es eigentlich keine statefull Firewalls.

Wenn ich LCOS richtig verstehe, wir da dennoch kurz die Firewall für dieRückantwort geöffnet, z.b. für den DNS Reply.

Da gibt es allerdings das Verhalten, das LCOS den UDP DNS Request an die zwei Konfigurierten oder vom Provider zugewiesenen DNS Server schickt,
die Reply Firewall allerdigs schon nach dem ersten Replay zu macht und der zweite Replay einen Alert auslöste, was mittlerweile unterdrückt und nicht notifiziert wird. (veränderte Notifikation Defaults)

Da hies es, Lancom müsste den UDP Stack umbauen um da auch simulierte Sessions zu nutzen oder so.

Also wenn QUIC wirklich unterstütze werden soll, müsste LCOS (und das Debian der UFs) das erkennen und geeignet behandeln.

Und nur, wenn es wirklich das QUIC Protokoll ist.

Ist das überhaupt beherschbar?

Viele Grüße

ts

[backslash]

HI Jirka,

ich sag's mal so: wenn man irgendwas mit QOS machen will, dann bräuchte man das QUICC-Objekt nur dazu, um QUICC garantiert zu filtern, denn sonst ist dein ganzes QOS für die Katz, weil sich die QUICC anders als TCP nicht "runterregeln" läßt.

schon mehrfach als Bugmeldung gesehen - insbesondere im Zusammenhang mit Citrix, das offenbar extrem anfällig für Delays und Paket-Loss ist und die Sessions regelmässig abbicht, sobald auch QUICC-Traffic vorhanden ist... Und das, obwohl Citrix über TCP läuft und damit eigentlich kein Problem haben sollte

Gruß
Backlsash

[GrandDixence]

Und das, obwohl Citrix über TCP läuft

Citrix unterstützt auch die Kommunikation per UDP auf Serverport 443:
https://docs.citrix.com/en-us/citrix-ga ... rvice.html

Wurde kontrolliert, ob die Citrix-Anwendungen in den Problemfällen über TCP oder UDP abgewickelt wurden?

weil sich die QUICC anders als TCP nicht "runterregeln" läßt.

QUIC sollte sich wie TCP per "DROP" oder per "ECN" herunterregeln lassen. Bei "DROP" entstehen unnötige, "künstliche" IP-Paketverluste auf dem Transportweg, welche mit dem Einsatz von ECN vermieden werden können. Gemäss der Wikipedia-Seite zu Explicit Congestion Notification (ECN):
https://en.wikipedia.org/wiki/Explicit_ ... tification

https://de.wikipedia.org/wiki/Explicit_ ... tification
unterstützt QUIC ECN.

ECN ist kurz beschrieben unter:
https://networkingharder.wordpress.com/ ... explained/

https://www.msxfaq.de/netzwerk/grundlagen/ecn.htm

Bei einem ECN-fähigen Internetanschluss empfehle ich zur Verkehrslastregelung den Einsatz von ECN anstelle von "DROP". Siehe auch:
https://community.sunrise.ch/d/15398-ec ... pc-sunrise

Da LCOS keine Verkehrslastregelung (QoS) mit ECN unterstützt (oder habe ich da etwas verpasst?), empfehle ich den Einsatz eines ECN-fähigen "Traffic Shaper". Siehe dazu:
fragen-zum-thema-firewall-f15/bandbreit ... ml#p106507

https://community.swisscom.ch/t5/Intern ... 394#M69411

Als Einstieg in das Thema "Traffic Shaper" empfehle ich dieses Youtube-Video ab 13:48 min:
https://www.youtube.com/watch?v=lQNSab8eCQ4

Fehlt der "Traffic Shaper" an diesem Internetanschluss, blockiert man am besten den gesamten QUIC-Datenverkehr über diesen Internetanschluss mit einer "DENY ALL"-Firewallregelstrategie. Gleiches gilt auch, wenn der Internetanschluss kein ECN unterstützt!

[backslash]

Hi GrandDixence

eine "Runterregelung" mittels ECN (oder gar Drop) ist aber leider nicht das, was benötigt wird...

Ein TCP regelt sich allein aufgrund steigender Round-Trip-Times runter, d.h. wenn man die TCP-Pakete einfach nur verzögert weiterkleitet. Und genau das ist nötig, wenn in Empfangsrichtung Bandbreite "freigeräumt" werden soll, um Platz für z.B. VOIP-Pakete zu machen. Der Internet-Provider wird die VIOP-Pakete höchtens dann bevorzugen, wenn er auch dein Telefon-Provider ist. Oder wenn du ihn dafür bezahlst betimmte DSCPs zu bevorzugen - Dazu darf der Provider auf der anderen Seite aber die DSCPs nicht "plätten" was aber leider auch alle Provider tun, wenn man sie nicht extra bezahlt...

Daher beibt bei QOS nur, QUICC-Traffic komplett zu blockieren...

Gruß
Backlsash

[GrandDixence]

Mit der Verzögerung der Weiterleitung von IP-Datenpakete läuft man nur in die Problematik von Bufferbloat rein. Ich hatte vor einigen Jahren bei der Inbetriebnahme des Traffic Shapers (CAKE) den Eindruck, dass auch ausserhalb von Überlastsituationen der Webbrowser die Webseiten spürbar schneller lädt, wenn der Traffic Shaper die Flusssteuerung übernimmt.

[tstimper]

Mit der Verzögerung der Weiterleitung von IP-Datenpakete läuft man nur in die Problematik von Bufferbloat rein. Ich hatte vor einigen Jahren bei der Inbetriebnahme des Traffic Shapers (CAKE) den Eindruck, dass auch ausserhalb von Überlastsituationen der Webbrowser die Webseiten spürbar schneller lädt, wenn der Traffic Shaper die Flusssteuerung übernimmt.

Das ist ja interessant. Kannst Du vielleicht Deine Traffic Shaper Config posten?

Vielen Dank und viele Grüße

ts

[GrandDixence]

Siehe den zweitletzten und drittletzten Link in meinem Beitrag vom 27.08.2024 um 22:41 Uhr.

[plumpsack]

... Aufklärung über QUIC ...

Wer oder was benutzt QUIC außerhalb der Android- und oder Google-Welt?

[GrandDixence]

Der Einsatz von QUIC ist für HTTP/3 vorgesehen:
https://en.wikipedia.org/wiki/HTTP/3

Heute ist der Einsatz von QUIC erfahrungsgemäss immer optional. Alle QUIC-fähigen Serverdienste machen einen Rückfall auf TCP/IP, wenn eine Firewall den QUIC-Netzwerkverkehr blockiert. Deshalb sollte man heute dem Ratschlag von Backslash folgen und den gesamten QUIC-Netzwerkverkehr in der Firewall blockieren. In 5 bis 15 Jahren könnte der Einsatz von QUIC nicht mehr überall optional sein.

[plumpsack]

Wer oder was benutzt QUIC außerhalb der Android- und oder Google-Welt?

Hab es selber herausgefunden:

Google
Meta
Microsoft

QUIC hat sich somit erledigt.