OPNsense soll traffic zwischen zwei WANs teilen

[PhreakShow]

Hi zusammen.

Ich habe folgendes vor: Im Moment habe ich Kabel D/vodafone, aber das Segment ist überbucht und in den Abendstunden kann ich nichts vernünftig spielen (ping > 500ms). Ich habe eine 20GB congstar LTE SIM, über die der "Zocktraffic" laufen soll.

OPNsense ist auf einem Atom n270 installiert, mit drei NICs. NIC1 ist WAN, NIC2 ist LAN und NIC3 heißt LTE.

Am LTE-Anschluss hängt mein Notebook mit eingestecktem LTE-Stick. Das Notebook bridged den LTE-Stick auf das gleiche Netz wie am LTE-Anschluss konfiguriert ist. Das funktioniert soweit und ist eine Zwischenlösung, bis mein richtiges LTE-Modem kommt.

In der Firewall habe ich eine Regel definiert, nach der sämtlicher UDP-Traffic zwischen 7000 und 7999 das LTE-Gateway nehmen soll. Das funktioniert ebenfalls. Das habe ich aus dem Thread:

https://forum.opnsense.org/index.php?topic=6776.0

Der hat ja ein ähnliches Thema.

Aber mein Problem geht weiter. Der Spieleserver schickt mir ja ebenfalls UDP-Pakete. Die müssen auch durch die LTE-Verbindung, sonst habe ich ja nichts davon. Aber woher weiß der Server, wo er hinfeuern muss.
Wie kommen die Pakete überhaupt bei meinem Client an? In meinem Router gibt es ja keinen Portforward auf meinen Rechner. Der Router muss also wissen, dass er da eingehenden Traffic durch das NAT zu meinem Rechner schiebt. Das heißt für mich, dass es einen Bezug zu den zuerst ausgehenden Paketen geben muss, weil mein Rechner die Verbindung startet.

Die ausgehenden Ports auf meinem Rechner sind zufällig gewählt. Das macht nix, weil ich den Zielport für den ausgehenden UDP-Traffic kenne. Aber wie mach ich das mit dem Rückweg?

[JeGr]

> Wie kommen die Pakete überhaupt bei meinem Client an? In meinem Router gibt es ja keinen Portforward auf meinen Rechner. Der Router muss also wissen, dass er da eingehenden Traffic durch das NAT zu meinem Rechner schiebt.

Nö und ja. Nein, wenn der Router kein Portforwarding macht, kommt auch von außen kein Traffic zu dir, der VON dort initial gesendet wird. Stichwort ist initial. Es kann also kein Server dir einfach Daten schicken. Andersherum wenn die Daten VON dir angefragt wurden (abgehend von deinem Rechner zum Server), dann kann er dir logischerweise antworten, egal ob per UDP oder TCP, pf emuliert für UDP da ein wenig was um "stateful" zu sein. Nichts desto trotz: die meisten Client/Server Konstellationen machen inzwischen einfach einen Check ob sie dich direkt erreichen können und wenn nicht wird es meist so gehandhabt, dass sich dein Client dann von dir aus mit dem Server verbindet und über diese Verbindung dann gearbeitet wird. Viel wird hier auch mit Connection Servern gearbeitet, die quasi als Vermittler dienen zwischen dir und dem Spielserver, da heute durch NAT kaum noch jemand ohne weiteres von außen erreichbar ist. Bei den Konsolen erkennt man das bspw. durch den NAT Typ (1,2,3).

Deine Konstellation ist etwas tricky, weil dein Traffic wohl nicht immer nur zwischen Port 7000-7999 sich abspielen wird, das ist ja je nach Spiel unterschiedlich, und wenn sich dein Rechner dann mal über nen anderen Port verbindet, wirst du plötzlich wieder auf der Kabel Leitung sein. Da wäre es vielleicht sinnvoller statt nur via Ports gleich den gesamten Rechner - zumindest Abends - über die LTE Strecke rauszuschicken.

[PhreakShow]

Danke für deine Antwort. Ich hab mich nur gefragt wie der Router das macht. Merkt der sich für jedes ausgehende Paket, dass es auch ein (genau eines?) eingehendes geben darf? Wenn ich mit Wireshark beim Zocken mitschneide, ist die Anzahl der Pakete von und zum Server gleich.

Der Bereich 7000-7999 war für das Spiel Battlegrounds. Die Ports liegen anscheinend immer in dem Bereich. Für CS habe ich 27000-27050 weitergeleitet, und es funktioniert astrein.

Google ping ich in den Abendstunden mit 400-700ms, während ich CS spiele und dort 20-40ms habe. Es war tatsächlich nur eine Umleitung dieser Ports auf das zweite Gateway.

[JeGr]

> Ich hab mich nur gefragt wie der Router das macht.

Stichwort Stateful Filtering. Einfach mal nachlesen. Dafür gibts die State Table, in der eben abgehende Verbindungen festgehalten werden damit eingehend entsprechend zugehörige Pakete eingelassen werden können ohne dass diese extra separat authentifiziert werden müssen.

[PhreakShow]

Danke, gutes Stichwort.