24.07.2022

4609

Langsamer Upload opnsense wireguard zu Ubuntu Server 20.04 (0,26 mb s)

Hallo liebes Forum,
ich benötige bitte Hilfe bevor mir meine restlichen Haare ausfallen. Seit einer Woche versuche ich nun den Internetraffic meiner Netzwerkclients (inkl. upnp) mittels opnsense und wireguard über einen Ubuntu 20.04 Server zu routen, um die feste IP für meine Clients bei mir zu Hause zu nutzen. Meine Clients haben bereits die externe IP, der Downlaod funktioniert auch. Jedoch bekomme ich im Upload nur 0,26 mb/s hin. Ich habe keine Ahnung was mein Upload so behindert.

Auf opnsense Seite habe ich folgende Schritte befolgt:

https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.htm ...

Auf Ubuntu Server Seite habe ich folgende Schritte unternommen:

https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard ...

- Mein Troubleshooting hat ergeben dass bereits die Wireguard Vebindung sehr langsam ist. iperf3 von opnsense zu Ubuntu ergab auch nur 0,26 mb/s.
- Traceroute vom Client führt über den VPS
- Mein client kann 10.0.0.1 anpingen.

Mein Client 192.168.2.11
Peer opnsense 10.0.0.2
Gateway opnsense 10.0.0.99
Ip VPS 10.0.0.1
External IP VPS

Irgendwas stimmt hier nicht. Aber ich finde es einfach nicht heraus. Ich habe schon X mal mit einer neuen Installation von opnsense begonnen und bin immer zum gleichen Ergebnis gekommen.

Bitte um Hilfe

Gruß Eddie

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3430741277

Url: https://administrator.de/forum/langsamer-upload-opnsense-wireguard-zu-ubuntu-server-20-04-0-26-mb-s-3430741277.html

Ausgedruckt am: 28.12.2024 um 08:12 Uhr

36 Kommentare

Neuester Kommentar

Zitat von @itsed99:
Jedoch bekomme ich im Upload nur 0,26 mb/s hin. Ich habe keine Ahnung was mein Upload so behindert.

Moin,
dein DSL 16.000 hat nur 2 MBit/s Upload, das sind genau deine 250KB/s.

VG

Ohne Wireguard habe ich 50 Mbit/s. Download sind ca. 200 Mbit/s.

(inkl. upnp)

Oha... für eine Firewall ein absolutes NoGo! UPnP gehört in jedem Falle aus guten Gründen immer deaktiviert auf NAT Routern und Firewall! Solltest du als Netzwerk Profi eigentlich wissen.

Deine Fehler:

Keine besonders intelligente VPN IP Adressierung. Guckst du dazu HIER.
Kardinalsfehler ist ein PEBKAC Problem nämlich das du ein Gateway Redirect Konzept umgesetzt hast!! Deutlich sinnvoller wäre ein Split Tunneling Konzept. Bei Gateway Redirect wird sämtlicher Client Traffic in den VPN Tunnel geroutet so das auch lokaler Traffic, der eigentlich nicht ins VPN soll, den Tunnel massiv belastet. Besser ist in jedem Falle hier Split Tunneling zu verwenden. Siehe Wireguard Tutorial.

Nur mal zur Sicherheit:

was ist denn die verbaute Hardware auf deiner OPNSense und dem Ubuntu-Server?
welche DSL-Verbindung hast du zuhause?
warum ist es für dich wichtig, die feste IP des Servers zuhause zu nutzen?

warum ist es für dich wichtig, die feste IP des Servers zuhause zu nutzen?

Vermutlich (geraten) ein DS-Lite Opfer der kein IPv4 VPN realisieren kann und mit IPv6 nicht leben kann oder will?!

Hallo,

Ohne Wireguard habe ich 50 Mbit/s. Download sind ca. 200 Mbit/s.

Ist das Deine (Heim)Internetanbindung? 200DL/50UL?
Auf welcher Hardware "rennt" denn OPNSense bei Dir?

Wie viele VPN Verbindungen hast Du denn da genau? 10, 20 oder 50?

Dobby

Zitat von @aqui:

(inkl. upnp)

Keine besonders intelligente VPN IP Adressierung. Guckst du dazu HIER.
Kardinalsfehler ist ein PEBKAC Problem nämlich das du ein Gateway Redirect Konzept umgesetzt hast!! Deutlich sinnvoller wäre ein Split Tunneling Konzept. Bei Gateway Redirect wird sämtlicher Client Traffic in den VPN Tunnel geroutet so das auch lokaler Traffic, der eigentlich nicht ins VPN soll, den Tunnel massiv belastet. Besser ist in jedem Falle hier Split Tunneling zu verwenden. Siehe Wireguard Tutorial.

Danke für den Tipp. Sehr gute Info!

Das ist mir bewusst, dass upnp deaktiviert gehört. Leider gibt es derzeit keine Alternative. Ich habe an dem dem Router jedoch ausschließlich die 10 Clients, welche eine feste IP benötigen als auch zwanghaft leider upnp. Andere Devices sind in einem anderen Subnet.

Ja, sämtlicher Client Traffic soll durch den Tunnel gehen. Ich habe an diesen OPNSense Instancen keine Clients, welche auf mein lokales Netz zugreifen sollen. Ich verstehe leider immer noch nicht ganz, wo genau mein Fehler ist. Wie kann es sein, dass der Upload so langsam ist? Würde eine falsch konfigurierte Firewall nicht meinen Upload komplett unterbrechen oder eben komplett freigeben?

Zitat von @Gentooist:

Nur mal zur Sicherheit:

was ist denn die verbaute Hardware auf deiner OPNSense und dem Ubuntu-Server?
welche DSL-Verbindung hast du zuhause?
warum ist es für dich wichtig, die feste IP des Servers zuhause zu nutzen?

OPNSense läuft auf Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz, der Ubuntu Server läuft auf einer kleinen VPS von Ionos. Dazu habe ich leider keine Informationen. Laut top sind jedoch beide nicht ansatzweise CPU bottlenecked.

DSL Verbindung: Cable, 1000 Download, 50 Upload.

Zitat von @aqui:

warum ist es für dich wichtig, die feste IP des Servers zuhause zu nutzen?

Vermutlich (geraten) ein DS-Lite Opfer der kein IPv4 VPN realisieren kann und mit IPv6 nicht leben kann oder will?!

Für meine privaten Anwendungen benötige ich keine feste IPV4. Jedoch benötige ich das für einige Services. IPV6 ist leider dort die Beschränkung.

Zitat von @108012:

Hallo,

Ohne Wireguard habe ich 50 Mbit/s. Download sind ca. 200 Mbit/s.

Ist das Deine (Heim)Internetanbindung? 200DL/50UL?
Auf welcher Hardware "rennt" denn OPNSense bei Dir?

Wie viele VPN Verbindungen hast Du denn da genau? 10, 20 oder 50?

Dobby

Pro OPNsense sollen es eine VPN Verbindung sein. Insgesamt sollen bis zu 6 OPNsense Instancen laufen. Ich kann leider nur 10 Clients per feste IP verwenden.

CPU ist Intel(R) Xeon(R) CPU E7- 8870 @ 2.40GHz. (Insgesamt 4x im System). Ich konnte kein CPU bottleneck erkennen.

Irgendjemand nen Tipp wo das Problem liegen könnte?
Hier nochmal die Config des Linux servers. UFW aktiviert.

Hier sind die IPERF3 Ergebnisse Ohne und Mit VPN.

Leider gibt es derzeit keine Alternative.

Die gibt es immer wenn man nachdenkt...

Irgendjemand nen Tipp wo das Problem liegen könnte?

Ja, in deinem fehlerhaften (und überflüssigen) NAT (Masquerading) in der Tunnelverbindung! Damit ist kein transparentes Routing möglich und frisst zudem unnötig Performance.
Siehe auch Wireguard Tutorial!
Einen max. MTU Check solltest du auch mal machen welche MTU noch durch den Tunnel geht und das ggf. anpassen um nicht fragmentieren zu müssen.
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
https://portal.nutanix.com/page/documents/kbs/details?targetId=kA0320000 ...
usw.

P.S.: 5 Einzel Antwortthreads kann man auch intelligent und übersichtlich zu einem zusammenfassen mit einem @... vor den Nicks!

Zitat von @aqui:

Leider gibt es derzeit keine Alternative.

Die gibt es immer wenn man nachdenkt...

Tatsächlich in diesem Fall leider nicht. Die Alternative wäre +60 feste IPV4 Adressen.

Irgendjemand nen Tipp wo das Problem liegen könnte?

Danke. Ich lese mich mal ein und gebe dann Rückmeldung.

P.S.: 5 Einzel Antwortthreads kann man auch intelligent und übersichtlich zu einem zusammenfassen mit einem @... vor den Nicks!

Vielen Dank

Die Alternative wäre +60 feste IPV4 Adressen.

Nein, die wäre das richtige Protokoll.

Aber egal, ist Off Topic und eine andere Baustelle...

Zitat von @aqui:

Leider gibt es derzeit keine Alternative.

Die gibt es immer wenn man nachdenkt...

Irgendjemand nen Tipp wo das Problem liegen könnte?

Scheint nicht zu funktionieren.

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 10.0.0.1 netmask 255.255.255.0 destination 10.0.0.1
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 2977 bytes 281216 (281.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3099 bytes 630572 (630.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ping -M do -s 1400 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 1400(1428) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
^C
--- 10.0.0.2 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3056ms

root@localhost:~# ping -M do -s 1392 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 1392(1420) bytes of data.
---> Hier kommt keine Antwort

Zitat von @aqui:

Die Alternative wäre +60 feste IPV4 Adressen.

Nein, die wäre das richtige Protokoll.

Aber egal, ist Off Topic und eine andere Baustelle...

Gerne auch hier nen Link zum einlesen

Zitat von @aqui:

Leider gibt es derzeit keine Alternative.

Die gibt es immer wenn man nachdenkt...

Irgendjemand nen Tipp wo das Problem liegen könnte?

Ich habe die NAT deaktiviert. Result ist jedoch das Gleiche.

Mehrere unübersichtliche Einzel Antwortthreads im 3 Minuten Takt kann man auch intelligent und übersichtlich zu einem zusammenfassen!!!

Dann liegt es vermutlich an deinem Server oder dem WG Client.
So ein WG Setup rennt mit einem Raspberry Pi 4 hier in Wirespeed. Wohlgemerkt ohne das überflüssige NAT im Tunnel.
Allerdings versteht man deinen Speedtest nicht wirklich ohne eine Information wie beide Tunnelenden physisch angebunden sind. Gute 100 Mbit/s ist doch ein durchaus akzeptabler Wert.
Zudem hast du ja auch ein MTU Problem. Das Pings mit so kleiner MTU wie 1392 nicht durch den Tunnel gehen ist de facto nicht normal. Hast du das testweise mal auf 1300 gesetzt?

Zitat von @aqui:

Mehrere unübersichtliche Einzel Antwortthreads im 3 Minuten Takt kann man auch intelligent und übersichtlich zu einem zusammenfassen!!!

Hi ja sorry. Versuche den Thread übersichtlicher zu gestalten

Ja, mit den 100 Mbit/s down bin ich auch zufrieden. Anbindung sollte eigentlich 1000 sein. Direkt am Router messe ich ca 400 Mbit/s down.
Aber der Upload macht mir zu schaffen. Das müsste eigentlich um die 50 Mbit/s. NAT habe ich deaktivert, hat leider nichts verändert. Woran kann das mit dem "schlechten" Upload liegen? Ich bin am Verzweifeln

Servus @itsed99,
als erstes, stelle sicher das ICMP am Ubuntu-Server in der Firewall am WG Interface für alle Client-Subnetze freigeschaltet ist damit die PMTU Ermittlung auch reibungslos funktioniert. Jetzt startest du mal eine Wireshark-Session am Client und sendest Daten. Schaue dir nun die Pakete in Wireshark an, wenn du eine erhebliche Anzahl an Retransmissions siehst dann liegt der Fehler zu 99% an der MTU und fragmentierter Übertragung und damit einer erheblich reduzierten Übertragungsrate, in dem Fall reduziere die Wireguard MTU am Server/Client mal auf 1400.

Des weiteren musst du natürlich auch am Ubuntu-Server sicherstellen das dir hier nicht die Upload-Rate durch den Provider beschränkt wurde bzw. du Opfer einer Fair-Use-Policy bist => Vertrag studieren.

Und bitte bitte bitte, Speedtests doch erst mal lokal innerhalb des Tunnels z.B. mittels iperf3 machen und nicht über irgendwelche externen Dienste die einem oft was vom Pferd erzählen! Erst wenn die Datenrate im Tunnel stimmt gehst du einen Schritt weiter und testest nach extern.

Grüße Uwe

Zitat von @colinardo:

Servus @itsed99,
als erstes, stelle sicher das ICMP am Ubuntu-Server in der Firewall am WG Interface für alle Client-Subnetze freigeschaltet ist damit die PMTU Ermittlung auch reibungslos funktioniert. Jetzt startest du mal eine Wireshark-Session am Client und sendest Daten. Schaue dir nun die Pakete in Wireshark an, wenn du eine erhebliche Anzahl an Retransmissions siehst dann liegt der Fehler zu 99% an der MTU und fragmentierter Übertragung und damit einer erheblich reduzierten Übertragungsrate, in dem Fall reduziere die Wireguard MTU am Server/Client mal auf 1400.

Des weiteren musst du natürlich auch am Ubuntu-Server sicherstellen das dir hier nicht die Upload-Rate durch den Provider beschränkt wurde bzw. du Opfer einer Fair-Use-Policy bist => Vertrag studieren.

Und bitte bitte bitte, Speedtests doch erst mal lokal innerhalb des Tunnels z.B. mittels iperf3 machen und nicht über irgendwelche externen Dienste die einem oft was vom Pferd erzählen!!

Grüße Uwe

Hi. Vielen Dank für deine Antwort. Es geht auf jeden Fall in die richtige Richtung! Ich habe beim Interface OPNSense als auch beim Ubuntu Server die MTU auf 1400 gesetzt und habe jetzt im Download einen leicht reduzierten, um Upload aber einen besseren Wert. Wie kann ich das jetzt optimieren? Ist leider nach wie vor zu langsam.

Bitte erst nochmal meinen Post aufmerksam lesen und uns die Hinweise mit Fakten belegen . Vor allem was sagt der Wireshark Trace? Wenn du Wireshark nicht interpretieren kannst, kannst du mir auch einen Trace per PN zum Download bereitstellen und ich schaue mir ihn an (persönliche Daten im Trace werden selbstverständlich vertraulich behandelt), daran lässt sich zu 90% die Ursache ermitteln. Des weiteren, ist ICMP tatsächlich durchgängig freigeschaltet und im Test funktionsfähig? Wenn das nämlich nicht stimmt brauchst du gar nicht erst weiter testen. Und bitte keine externen Speedtests!! Mach als erstes einen iperf3 Test zwischen den WG Tunnel-Endpunkten damit keine externen Parteien zusätzlich beteiligt sind !!!

Zitat von @colinardo:

Bitte erst nochmal meinen Post aufmerksam lesen und uns die Hinweise mit Fakten belegen . Vor allem was sagt der Wireshark Trace? Wenn du Wireshark nicht interpretieren kannst, kannst du mir auch einen Trace per PN zum Download bereitstellen und ich schaue mir ihn an (persönliche Daten im Trace werden selbstverständlich vertraulich behandelt), daran lässt sich zu 90% die Ursache ermitteln. Des weiteren, ist ICMP tatsächlich durchgängig freigeschaltet und im Test funktionsfähig? Wenn das nämlich nicht stimmt brauchst du gar nicht erst weiter testen. Und bitte keine externen Speedtests!! Mach als erstes einen iperf3 Test zwischen den WG Tunnel-Endpunkten damit keine externen Parteien zusätzlich beteiligt sind !!!

Vielen Dank. Ich habe dir eine PN mit dem Trace geschickt. Wo kann ich nachlesen, wie ich ICMP testen bzw. freischalten kann?
Wird gemacht. Keine externen Speedtests mehr!

Zitat von @itsed99:
Vielen Dank. Ich habe dir eine PN mit dem Trace geschickt.

Merci, wie ich vermutet hatte, der Trace ist voller Retransmissions mit viel zu großen TCP-Window-Werten vom Client. Das kann so also niemals ordentlich funktionieren, deine PMTU funktioniert hier also überhaupt nicht und ICMP wird an irgendeiner deiner Firewalls gefiltert und dann wundert der magere Speed nicht.

Wo kann ich nachlesen, wie ich ICMP testen bzw. freischalten kann?

Öhm, du betreibst einen Ubuntu Server am öffentlichen Internet und weist nicht wie du ICMP in deiner Firewall auf deinem Wireguard Interface freischaltest??
Himmel Herr Gott lass ... regnen, Interface natürlich anpassen

iptables -I INPUT -i wg0 -p icmp -j ACCEPT
iptables -I FORWARD -i wg0 -p icmp -j ACCEPT

Des weiteren natürlich auch an der OpnSense.
Wir kennen dein Firewall-Regelwerk hier nicht, wenn du da also irgendwas in der Richtung in der Forward oder Input-Chain blockst ohne zu wissen was das für Auswirkungen hast du dir damit selbst ein Bein gestellt.

Wir kennen dein Firewall-Regelwerk hier nicht

Hoffen wir mal inständig das er überhaupt eins hat?! 😱

Zitat von @colinardo:

Zitat von @itsed99:
Vielen Dank. Ich habe dir eine PN mit dem Trace geschickt.

Wo kann ich nachlesen, wie ich ICMP testen bzw. freischalten kann?

iptables -I INPUT -i wg0 -p icmp -j ACCEPT
iptables -I FORWARD -i wg0 -p icmp -j ACCEPT

Vielen Dank. wg0 Interface passt. ufw sollte auch nichts blocken, richtig?
Ich habe alle Firewall Rules meines OPNsens hier als Screenshot reingestellt. Auch die Protokolle sind überall offen auf "any". Kann es sein das mein Asus Router oder meine Fritzbox das ICMP blocken?

Kurze Frage. Wenn ich vom Client den Server pingen kann und vice versa, dann geht doch icmp durch oder? Z.b. von 10.0.0.1 Server gepingt:

PING 192.168.2.11 (192.168.2.11) 56(84) bytes of data.
64 bytes from 192.168.2.11: icmp_seq=1 ttl=63 time=25.6 ms
64 bytes from 192.168.2.11: icmp_seq=2 ttl=63 time=23.2 ms
64 bytes from 192.168.2.11: icmp_seq=3 ttl=63 time=23.4 ms
64 bytes from 192.168.2.11: icmp_seq=4 ttl=63 time=24.4 ms
64 bytes from 192.168.2.11: icmp_seq=5 ttl=63 time=21.1 ms
64 bytes from 192.168.2.11: icmp_seq=6 ttl=63 time=24.3 ms

Kann das evlt. ein Problem sein?
https://forum.opnsense.org/index.php?topic=5144.0

Laut OPNSense Firewall log gehen die Pakte von Iperf3 durch.

Vielen Dank für den Support auf jeden Fall.

ufw sollte auch nichts blocken, richtig?

Hellsehen können wir leider noch nicht...

dann geht doch icmp durch oder?

Jein. Dann geht lediglich ICMP Typ 8 und 0 durch aber ob die anderen ICMP Typen (insbesondere Typ 3) auch korrekt bedient werden besagt das leider nicht.
https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol

Deine o.a. Regel lässt lediglich TCP passieren (Protocol). TCP ist bekanntlich kein ICMP und auch kein UDP usw.

P.S.: Wenn du einmal die FAQs lesen würdest und das "+" bei eingebetten Bildern richtig klickst, würde man die auch in einem vernünftigen Kontext sehen statt zusammenhangslos am Ende des Threads.

Zitat von @aqui:

ufw sollte auch nichts blocken, richtig?

Hellsehen können wir leider noch nicht...

dann geht doch icmp durch oder?

Vielen Dank für die Hinweise. Ich sehe aber nicht, dass die OPNSense Firewall ICMP blocken würde. Es wird durchgelassen.

ICMP Im Loopback ok?

Die Settings der OPNSense sehen wir da rum geht es uns hier primär nicht sondern die Firewall-Einstellungen des Ubuntu Servers!
PMTU wird des weiteren nicht überall angewendet. Hier ist dann MSS Clamping gefragt, dass lässt sich in den OPNSense Einstellungen unter Firewall > Settings > Normalization konfigurieren. Eine Regel die auf das Wireguard Interface angewendet wird dessen MSS du auf 1380 setzt sollte Ruhe schaffen, evt. auch etwas geringer einstellen je nach dem was über den Tunnel gefahren werden soll. MSS 1380 passt hier zur Default WG MTU 1420 bei reiner IPv4 Nutzung, ist die WG MTU auf 1400 sollte die MSS auch auf 1360 stehen (IP und TCP Header jeweils 20 Bytes).

MSS Clamping sorgt dafür das beim TCP SYN Handshake die MSS Option entsprechend von Anfang an geringer angesetzt wird und es so zu keiner Fragmentierung auf dem Pfad zwischen Client und Server komt.

Die Anpassung der MSS sieht man dann schön im TCP Handshake in den TCP Optionen. Einfach mal etwas mehr mit TCP und Wirehark befassen dann musst du nicht mehr rum raten wieso und weshalb

.

So long, das war es von meiner Seite.

Viel Erfolg
Grüße Uwe

Zitat von @colinardo:

Die Settings der OPNSense sehen wir da rum geht es uns hier primär nicht sondern die Firewall-Einstellungen des Ubuntu Servers!
PMTU wird des weiteren nicht überall angewendet. Hier ist dann MSS Clamping gefragt, dass lässt sich in den OPNSense Einstellungen unter Firewall > Settings > Normalization konfigurieren. Eine Regel die auf das Wireguard Interface angewendet wird dessen MSS du auf 1380 setzt sollte Ruhe schaffen, evt. auch etwas geringer einstellen je nach dem was über den Tunnel gefahren werden soll. MSS 1380 passt hier zur Default WG MTU 1420 bei reiner IPv4 Nutzung, ist die WG MTU auf 1400 sollte die MSS auch auf 1360 stehen (IP und TCP Header jeweils 20 Bytes).

.

So long, das war es von meiner Seite.

Viel Erfolg
Grüße Uwe

Uwe, vielen Dank für die Antwort. Ich habe eine Regel bei Normalization gesetzt

Leider ohne Erfolg.

Tja ich bin es jetzt leid raten zu müssen wir haben jetzt schon x mal um die Einstellungen des Ubuntu-Systems gebeten und du ignorierst das einfach, du machst immer nur das was du gerade machen willst der Rest fällt hinten runter ist aber essentiell wichtig! Auch was für maximale TCP Window-Werte (net.core.rmem_max / net.core.wmem_max) auf dem Ubuntu-System konfiguriert sind usw. fehlt hier alles. Daher bin ich jetzt raus.

Viel Erfolg
Grüße Uwe

Zitat von @colinardo:

Tja ich bin es jetzt leid raten zu müssen wir haben jetzt schon x mal um die Einstellungen des Ubuntu-Systems gebeten und du ignorierst das einfach. Auch was für maximale TCP Window-Werte (net.core.rmem_max / net.core.wmem_max) auf dem Ubuntu-System konfiguriert sind usw. fehlt hier alles. Daher bin ich jetzt raus.

Viel Erfolg
Grüße Uwe

Sorry hab ich nicht ganz Verstanden. Welche werte beim Ubuntu Server benötigst du noch?

Zitat von @colinardo:

Die Settings der OPNSense sehen wir da rum geht es uns hier primär nicht sondern die Firewall-Einstellungen des Ubuntu Servers!

Dieser Satz ohne Punkt und Komma war eine Aufforderung weitere nicht näher definierte Informationen zur Ubuntu Firewall zu liefern?

Folgende Lösung hat funktioniert. Ubuntu Seite:

sudo ifconfig wg0 mtu 1380 up

OPNSense Seite:
VPN > Wireguard > Local > Edit > Oben links auf "Advanced Mode" > MTU 1380 eintragen.

Piece!