Ubuntu verschiedene Internetzugänge mit Wireguard, WLAN funktioniert, LAN nicht
Hallo zusammen,
ich habe hier ein komisches Phänomen vielleicht auch nur ein Verständnisproblem meinerseits. Es ist zb. Freifunk Verfügbar an dem ich per Kabel anstecken kann und mich auch per WLAN Verbinden kann.
Es sollte die Ausgangslage somit -eigentlich- Identisch sein.
Ich habe ein Notebook mit einem frischen Ubuntu und einer Wireguard Verbindung zu mir nach Hause.
Verbinde ich nun mein Notebook mit dem WLAN und baue eine Wireguard Verbindung auf, dann klappt alles so wie ich es mir vorstelle. Ich komme in mein Heimnetzwerk, kann auch auf Internetseiten surfen, Pings und Traceroute geht durch.
Auch der Aufruf verschiedener Internetseiten funktioniert ohne jegliche Problem. Browser Firefox. Egal welche Seite ich aufrufe.
Verbinde ich mich nun mit LAN und führe die selben Tests durch, Sieht es wie folgt aus:
Die Tests sind im Terminal identisch. Jetzt das große aber.
Ich kann kaum Internetseiten mit dem Browser aufrufen.
- Heise.de funktioniert
- administrator.de funktioniert nicht
Viele weitere Seiten funktionieren nicht. Stern.de, n-tv.de usw. kein aufruf im Browser möglich, aber Ping per Terminal ist möglich.
Test ich nun genau das selbe Verhalten mit einem Windows Laptop.
Heißt WLAN / LAN Kabel, Wireguard usw. habe ich keinerlei Probleme.
Kurz zusammengefasst:
Mit Windows egal ob WLAN oder LAN funktioniert alles wie gewünscht.
Mit Linux funktioniert alles mit wLAN, mit LAN allerdings sogut wie nichts.
Ich kann das verhalten auch mit einem anderen internen Netzwerk nachstellen. Mit Ubuntu WLAN alles in Ordnung, mit Ubuntu LAN die selben Probleme.
Windows selbe Ausgangsituation keinerlei Auffälligkeiten.
Für mich klingt das so, als wäre etwas mit der LAN Schnittstelle auf dem Ubuntu, allerdings nur in Verbindung mit Wireguard.
Das Netzwerk selbst schließe ich aus, da es mit Windows ohne jegliche Probleme funktioniert.
Danke für die Hilfe.
ich habe hier ein komisches Phänomen vielleicht auch nur ein Verständnisproblem meinerseits. Es ist zb. Freifunk Verfügbar an dem ich per Kabel anstecken kann und mich auch per WLAN Verbinden kann.
Es sollte die Ausgangslage somit -eigentlich- Identisch sein.
Ich habe ein Notebook mit einem frischen Ubuntu und einer Wireguard Verbindung zu mir nach Hause.
Verbinde ich nun mein Notebook mit dem WLAN und baue eine Wireguard Verbindung auf, dann klappt alles so wie ich es mir vorstelle. Ich komme in mein Heimnetzwerk, kann auch auf Internetseiten surfen, Pings und Traceroute geht durch.
ping -4 administrator.de
PING administrator.de (82.149.225.19) 56(84) bytes of data.
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=1 ttl=55 time=56.5 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=2 ttl=55 time=53.4 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=3 ttl=55 time=49.5 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=4 ttl=55 time=51.5 ms
^C
--- administrator.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 49.522/52.729/56.505/2.581 msping -6 heise.de
PING heise.de (2a02:2e0:3fe:1001:302::) 56 data bytes
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=2 ttl=57 time=54.8 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=3 ttl=57 time=114 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=4 ttl=57 time=56.8 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=5 ttl=57 time=44.1 ms
^C
--- heise.de ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4010ms
rtt min/avg/max/mdev = 44.136/67.350/113.605/27.137 msping 192.168.7.10
PING 192.168.7.10 (192.168.7.10) 56(84) bytes of data.
64 bytes from 192.168.7.10: icmp_seq=1 ttl=63 time=63.2 ms
64 bytes from 192.168.7.10: icmp_seq=2 ttl=63 time=46.9 ms
64 bytes from 192.168.7.10: icmp_seq=3 ttl=63 time=41.0 ms
64 bytes from 192.168.7.10: icmp_seq=4 ttl=63 time=35.5 ms
^C
--- 192.168.7.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 35.465/46.636/63.155/10.360 mstraceroute administrator.de
traceroute to administrator.de (82.149.225.19), 30 hops max, 60 byte packets
1 192.168.77.1 (192.168.77.1) 36.116 ms 39.115 ms 39.066 ms
2 ipbcc232fe.dynamic.kabel-deutschland.de (188.194.50.254) 53.148 ms 53.124 ms 53.101 ms
3 ip53a9894e.static.kabel-deutschland.de (83.169.137.78) 50.864 ms 51.669 ms 51.627 ms
4 ip5886c33d.static.kabel-deutschland.de (88.134.195.61) 52.950 ms 52.903 ms 52.926 ms
5 145.254.3.100 (145.254.3.100) 52.886 ms 52.848 ms 52.840 ms
6 145.254.2.207 (145.254.2.207) 56.610 ms 59.501 ms 63.487 ms
7 decix-fra.tng.de (80.81.192.83) 63.809 ms 63.768 ms 63.722 ms
8 ae6-2625.cr1.rbs.de.aixit.net (83.141.1.187) 63.375 ms 63.268 ms 63.485 ms
9 ae0-3002.er2.fra1.ax.de.aixit.net (83.141.5.102) 63.075 ms 63.123 ms 62.963 ms
10 * * *
11 * * *
12 * * *
13 * * *Verbinde ich mich nun mit LAN und führe die selben Tests durch, Sieht es wie folgt aus:
ping -4 administrator.de
PING administrator.de (82.149.225.19) 56(84) bytes of data.
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=1 ttl=55 time=51.1 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=2 ttl=55 time=100 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=3 ttl=55 time=55.6 ms
64 bytes from www.administrator.de (82.149.225.19): icmp_seq=4 ttl=55 time=58.0 ms
^C
--- administrator.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 51.110/66.281/100.423/19.866 msping -6 heise.de
PING heise.de (2a02:2e0:3fe:1001:302::) 56 data bytes
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=57 time=45.2 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=2 ttl=57 time=44.6 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=4 ttl=57 time=45.5 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=5 ttl=57 time=107 ms
^C
--- heise.de ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4050ms
rtt min/avg/max/mdev = 44.607/60.633/107.277/26.931 mstraceroute administrator.de
traceroute to administrator.de (82.149.225.19), 30 hops max, 60 byte packets
1 192.168.77.1 (192.168.77.1) 36.319 ms 40.806 ms 40.746 ms
2 ipbcc232fe.dynamic.kabel-deutschland.de (188.194.50.254) 52.591 ms 52.609 ms 52.517 ms
3 ip53a9894e.static.kabel-deutschland.de (83.169.137.78) 49.265 ms 49.320 ms 49.268 ms
4 ip5886c33d.static.kabel-deutschland.de (88.134.195.61) 52.487 ms 52.286 ms 52.405 ms
5 145.254.3.100 (145.254.3.100) 52.502 ms 52.371 ms 52.405 ms
6 145.254.2.207 (145.254.2.207) 55.925 ms 55.360 ms 59.907 ms
7 decix-fra.tng.de (80.81.192.83) 63.379 ms 55.420 ms 63.243 ms
8 ae6-2625.cr1.rbs.de.aixit.net (83.141.1.187) 62.378 ms 63.123 ms 63.071 ms
9 ae0-3002.er2.fra1.ax.de.aixit.net (83.141.5.102) 63.017 ms 62.955 ms 62.861 ms
10 * * *
11 * * *
12 * * *ping 192.168.7.10
PING 192.168.7.10 (192.168.7.10) 56(84) bytes of data.
64 bytes from 192.168.7.10: icmp_seq=1 ttl=63 time=34.4 ms
64 bytes from 192.168.7.10: icmp_seq=2 ttl=63 time=35.4 ms
64 bytes from 192.168.7.10: icmp_seq=3 ttl=63 time=32.7 ms
64 bytes from 192.168.7.10: icmp_seq=4 ttl=63 time=42.6 ms
^C
--- 192.168.7.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 32.735/36.267/42.557/3.753 msDie Tests sind im Terminal identisch. Jetzt das große aber.
Ich kann kaum Internetseiten mit dem Browser aufrufen.
- Heise.de funktioniert
- administrator.de funktioniert nicht
Viele weitere Seiten funktionieren nicht. Stern.de, n-tv.de usw. kein aufruf im Browser möglich, aber Ping per Terminal ist möglich.
Test ich nun genau das selbe Verhalten mit einem Windows Laptop.
Heißt WLAN / LAN Kabel, Wireguard usw. habe ich keinerlei Probleme.
Kurz zusammengefasst:
Mit Windows egal ob WLAN oder LAN funktioniert alles wie gewünscht.
Mit Linux funktioniert alles mit wLAN, mit LAN allerdings sogut wie nichts.
Ich kann das verhalten auch mit einem anderen internen Netzwerk nachstellen. Mit Ubuntu WLAN alles in Ordnung, mit Ubuntu LAN die selben Probleme.
Windows selbe Ausgangsituation keinerlei Auffälligkeiten.
Für mich klingt das so, als wäre etwas mit der LAN Schnittstelle auf dem Ubuntu, allerdings nur in Verbindung mit Wireguard.
Das Netzwerk selbst schließe ich aus, da es mit Windows ohne jegliche Probleme funktioniert.
Danke für die Hilfe.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673027
Url: https://administrator.de/forum/ubuntu-verschiedene-internetzugaenge-mit-wireguard-wlan-funktioniert-lan-nicht-673027.html
Ausgedruckt am: 27.05.2025 um 18:05 Uhr
34 Kommentare
Neuester Kommentar
Moin,
Funktioniert denn unter Ubuntu ohne Wireguard alles richtig?
Ist die Wireguard-Kionfijuration unter Ubuntu und Windows gleich?
Was sagen ifconfig -a und ipconfig /alll und netstat -r jeweils?
lks
Funktioniert denn unter Ubuntu ohne Wireguard alles richtig?
Ist die Wireguard-Kionfijuration unter Ubuntu und Windows gleich?
Was sagen ifconfig -a und ipconfig /alll und netstat -r jeweils?
lks
Hört sich nach einem MTU Problem an. Bei Freifunk auch anzunehmen, da die alle Produktivdaten nochmals in einem Tunnel übertragen. Mit PPPoE hat man dann eine 3fache Encapsulation was die MTU deutlich verkleinert und die Wireguard Default MTU nicht mehr reicht.
Dazu müsste man aber wissen WIE der Internet Zugang über LAN realsiert ist. Bei PPPoE wäre eine MTU Problematik (Fragmentierung) möglich. Die Default MTU von Wireguard ist 1420.
Leider machst du dazu wenig hilfreiche Angaben so das man nur Kristallkugeln kann.
Statt der o.a. Allerwelts Ping Checks wäre ein max. MTU Ping Check mit und ohne aktivem VPN Tunnel sehr viel sinnvoller gewesen...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/de/19863/Ping-Test-zur-Ermittlung-der-optimalen-M ...
Möglich auch das es mit der (vermutlichen) Dual Stack Umgebung zu tun hat und es sich um eine falsche oder fehlerhafte WG Konfiguration handelt. Auch hier fehlen leider wieder hilfreiche Angaben zum IP Adress Design und insbesondere dem Wireguard Setup.
Ebenso wären DNS Checks (nslookup oder dig) für IPv6 und v4 sinnvoll und hilfreich um die Namensauflösung als Fehlerquelle auszuschliessen. Auch hier wieder einmal mit und einmal ohne VPN Tunnel. Leider auch Fehlanzeige.
Eine zielführende Hilfe ohne ins wilde Raten abzugleiten ist da dann nur schwer möglich.
Dazu müsste man aber wissen WIE der Internet Zugang über LAN realsiert ist. Bei PPPoE wäre eine MTU Problematik (Fragmentierung) möglich. Die Default MTU von Wireguard ist 1420.
Leider machst du dazu wenig hilfreiche Angaben so das man nur Kristallkugeln kann.
Statt der o.a. Allerwelts Ping Checks wäre ein max. MTU Ping Check mit und ohne aktivem VPN Tunnel sehr viel sinnvoller gewesen...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/de/19863/Ping-Test-zur-Ermittlung-der-optimalen-M ...
Möglich auch das es mit der (vermutlichen) Dual Stack Umgebung zu tun hat und es sich um eine falsche oder fehlerhafte WG Konfiguration handelt. Auch hier fehlen leider wieder hilfreiche Angaben zum IP Adress Design und insbesondere dem Wireguard Setup.
Ebenso wären DNS Checks (nslookup oder dig) für IPv6 und v4 sinnvoll und hilfreich um die Namensauflösung als Fehlerquelle auszuschliessen. Auch hier wieder einmal mit und einmal ohne VPN Tunnel. Leider auch Fehlanzeige.
Eine zielführende Hilfe ohne ins wilde Raten abzugleiten ist da dann nur schwer möglich.
Funktioniert denn unter Ubuntu ohne Wireguard alles richtig?
Soweit ich das erkennen kann, ja.Ist die Wireguard-Kionfijuration unter Ubuntu und Windows gleich?
Ja die Konfig ist soweit identisch. Andere IP und andere Keys. Rest ist allerdings komplett gleich.Statt der o.a. Allerwelts Ping Checks wäre ein max. MTU Ping Check mit und ohne aktivem VPN Tunnel sehr viel sinnvoller gewesen...
MTU im LAN ohne Wireguard:
ing -M do -s 1253 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1253(1281) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1036msping -M do -s 1252 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1252(1280) bytes of data.
1260 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=20.3 ms
1260 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=20.4 ms
1260 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=20.6 ms
1260 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=20.3 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 20.319/20.432/20.620/0.117 msMTU im LAN mit Wireguard:
ping -M do -s 1252 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1252(1280) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6166msping -M do -s 1392 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1392(1420) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7194msMTU im WLAN ohne Wireguard:
ping -M do -s 1253 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1253(1281) bytes of data.
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1060msping -M do -s 1252 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1252(1280) bytes of data.
1260 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=20.4 ms
1260 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=22.0 ms
1260 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=21.9 ms
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 20.444/21.433/21.985/0.701 msMTU im WLAN mit Wireguard:
ping -M do -s 1400 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1400(1428) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1043msping -M do -s 1392 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1392(1420) bytes of data.
1400 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=54.3 ms
1400 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=58.0 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 54.303/56.136/57.969/1.833 msMöglich auch das es mit der (vermutlichen) Dual Stack Umgebung zu tun hat und es sich um eine falsche oder fehlerhafte WG Konfiguration handelt. Auch hier fehlen leider wieder hilfreiche Angaben zum IP Adress Design und insbesondere dem Wireguard Setup.
Die WG Konfig kann ich ausschließen. Im WLAN funktioniert genau diese Konfig wunderbar. Auf auf einem Windows Rechner funktioniert im LAN alles. Nur Linux Ubuntu zieht mir hier einen Strich durch die Rechnung.
Ebenso wären DNS Checks (nslookup oder dig) für IPv6 und v4 sinnvoll und hilfreich um die Namensauflösung als Fehlerquelle auszuschliessen. Auch hier wieder einmal mit und einmal ohne VPN Tunnel.
Macht das Sinn? Die Daten liegen bereits im Cache und sehen so aus:
nslookup heise.de
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: heise.de
Address: 193.99.144.80
Name: heise.de
Address: 2a02:2e0:3fe:1001:302::
Kurzer Trace mit Wireshark oder tcpdump bringt wie immer Klarheit ...
Man beachte das Freifunk ja einen Tunnel bereitstellt und da muss dann auch alles durch. PMTU (ICMP Error frames) Durchgängigkeit der Firewalls nicht vernachlässigen!
Man beachte das Freifunk ja einen Tunnel bereitstellt und da muss dann auch alles durch. PMTU (ICMP Error frames) Durchgängigkeit der Firewalls nicht vernachlässigen!
1Kurzer Trace mit Wireshark oder tcpdump bringt wie immer Klarheit ...
Da kenne ich mich leider absolut nicht aus.
Man beachte das Freifunk ja einen Tunnel bereitstellt und da muss dann auch alles durch. PMTU (ICMP Error frames) Durchgängigkeit der Firewalls nicht vernachlässigen!
Mich wundert die ganze Sache nur, WLAN und LAN ist in dem Freifunksetup gleich. Ich lande immer am selben Gateway.
Auch, dass Windows mit LAN und Wireguard absolut keine Probleme hat, lässt mich darauf schließen, dass es an Ubuntu liegen muss.
Zitat von @wusa88:
Da kenne ich mich leider absolut nicht aus.
Dann wirds aber endlich mal Zeit es zu lernen, als Networker unverzichtbare Grundlagen, du bist ja hier nicht erst gerade kurz unterwegs Kurzer Trace mit Wireshark oder tcpdump bringt wie immer Klarheit ...
Da kenne ich mich leider absolut nicht aus.
.Mich wundert die ganze Sache nur, WLAN und LAN ist in dem Freifunksetup gleich. Ich lande immer am selben Gateway.
Auch, dass Windows mit LAN und Wireguard absolut keine Probleme hat, lässt mich darauf schließen, dass es an Ubuntu liegen muss.
Wundern bringt da nichts, hier zählen nur harte Fakten und in einem Trace sieht man wo es hakt.Auch, dass Windows mit LAN und Wireguard absolut keine Probleme hat, lässt mich darauf schließen, dass es an Ubuntu liegen muss.
EIn Netzwerk unter Ubuntu lässt sich auf unterschiedliche Weisen einrichten, ob über Netplan / NetworkManager / systemd-networkd / oder oder oder weiß hier niemand, auch wie du Wireguard eingerichtet hast, ob über wg-quick oder NetworkManager etc. wissen wir hier nicht, ich Tippe auf ein DNS Problem (z.B. angegebener DNS-Server über den Tunnel nicht erreichbar etc.). Also ausführliche Config zusammenstellen und hier posten dann kann man weiter sehen.
Als erstes würde ich sicherstellen wollen das DNS-Abfragen korrekt funktionieren wenn der Tunnel aktiv ist.
1
Config stelle ich jetzt dann gleich zusammen.
Hier ist nochmal eine Ausgabe von dig wenn ich den Tunnel aktiv habe und dann die 1.1.1.1 befrage.
Auch andere Anfragen gehen durch:
Hier ist nochmal eine Ausgabe von dig wenn ich den Tunnel aktiv habe und dann die 1.1.1.1 befrage.
dig heise.de @1.1.1.1
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> heise.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8388
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;heise.de. IN A
;; ANSWER SECTION:
heise.de. 81804 IN A 193.99.144.80
;; Query time: 53 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon May 26 11:50:29 CEST 2025
;; MSG SIZE rcvd: 53dig administrator.de @1.1.1.1
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> administrator.de @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25924
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;administrator.de. IN A
;; ANSWER SECTION:
administrator.de. 3600 IN A 82.149.225.19
;; Query time: 341 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon May 26 11:53:52 CEST 2025
;; MSG SIZE rcvd: 61Auch andere Anfragen gehen durch:
dig administrator.de @1.0.0.2
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> administrator.de @1.0.0.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8941
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;administrator.de. IN A
;; ANSWER SECTION:
administrator.de. 3041 IN A 82.149.225.19
;; Query time: 60 msec
;; SERVER: 1.0.0.2#53(1.0.0.2) (UDP)
;; WHEN: Mon May 26 11:59:18 CEST 2025
;; MSG SIZE rcvd: 61dig administrator.de @9.9.9.9
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> administrator.de @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17307
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;administrator.de. IN A
;; ANSWER SECTION:
administrator.de. 3495 IN A 82.149.225.19
;; Query time: 57 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Mon May 26 11:59:21 CEST 2025
;; MSG SIZE rcvd: 61Hier ist nochmal eine Ausgabe von dig wenn ich den Tunnel aktiv habe und dann die 1.1.1.1 befrage.
Joa gut, inetressant ist dann aber eher was in deiner WG Config am Client zu DNS steht ... Du solltest auch nicht explizit einen DNS-Server bei der Abfrage angeben sondern den vom System automatisch hinterlegten benutzen lassen, sonst spiegelt das ja nicht die normale Situation beim Surfen wieder .1
Es ist egal, ob ich meinen DNS Server eintrage, oder den Eintrag komplett frei lasse.
Mache ich dig auf meinen Router zuhause um eine DNS Abfrage zu starten, dann kommt folgende Ausgabe:
dig administrator.de @192.168.77.1
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> administrator.de @192.168.77.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46802
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;administrator.de. IN A
;; ANSWER SECTION:
administrator.de. 3600 IN A 82.149.225.19
;; Query time: 57 msec
;; SERVER: 192.168.77.1#53(192.168.77.1) (UDP)
;; WHEN: Mon May 26 13:06:42 CEST 2025
;; MSG SIZE rcvd: 50dann kommt folgende Ausgabe:
Die ist ja auch korrekt! Und WO ist jetzt die Frage oder das "Problem"??Du kannst ja oben beim MTU Check schon sehen das du massive MTU Probleme hast durch die mindestens 2 fache Encapsulation (WG Tunneloverhead, FF Tunneloverhead)
Das wäre der erste Punk der anzupassen ist.
Ich bin da ehrlich gesagt nicht tief genug im Thema drin.
Ich sehe die massiven Probleme nicht, ich merke dass es nicht geht.
Für mich ist es einfach unerklärlich. Im WLAN genau das selbe Gateway usw. und es funktioniert ohne jegliche Probleme.
Hänge ich mich in das selbe Gateway nur per LAN habe ich nur Probleme.
Mache ich das ganze mit Windows. LAN und WLAN ohne Problem.
Es muss doch dann an Linux / Ubuntu liegen, bzw. an der Ethernet Schnittstelle vom Laptop wenn es bei Ubuntu nicht geht?
Ich sehe die massiven Probleme nicht, ich merke dass es nicht geht.
Für mich ist es einfach unerklärlich. Im WLAN genau das selbe Gateway usw. und es funktioniert ohne jegliche Probleme.
Hänge ich mich in das selbe Gateway nur per LAN habe ich nur Probleme.
Mache ich das ganze mit Windows. LAN und WLAN ohne Problem.
Es muss doch dann an Linux / Ubuntu liegen, bzw. an der Ethernet Schnittstelle vom Laptop wenn es bei Ubuntu nicht geht?
Ich sehe die massiven Probleme nicht
Oha, wenn bei 1253 schon fragmentiert werden muss siehst du das nicht? 😱ping: local error: message too long, mtu=1280
Hänge ich mich in das selbe Gateway nur per LAN habe ich nur Probleme.
WLAN hast du dann hoffentlich deaktiviert, oder? Nicht das du beide Adapter parallel im gleichen IP Netz aktiv hast?!WLAN hast du dann hoffentlich deaktiviert, oder? Nicht das du beide Adapter parallel im gleichen IP Netz aktiv hast?!
Ja, ich hatte immer nur den Adapter aktiv, welchen ich auch genutzt habe.
Heißt Kable wurde immer abgesteckt oder wenn das Kabel dran war, dann habe ich das Funknetzwerk deaktiviert.
Oha, wenn bei 1253 schon fragmentiert werden muss siehst du das nicht? 😱
Das ist aber bei WLAN und LAN gleich.
Ich habe jetzt mal die Gegenprüfung auf dem funktionierendem Windows Laptop gemacht.
MTU im LAN ohne Wireguard:
ping -f -l 1473 1.1.1.1
Ping wird ausgeführt für 1.1.1.1 mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust), ping -f -l 1472 1.1.1.1
Ping wird ausgeführt für 1.1.1.1 mit 1472 Bytes Daten:
Antwort von 1.1.1.1: Bytes=1472 Zeit=20ms TTL=55
Antwort von 1.1.1.1: Bytes=1472 Zeit=22ms TTL=55
Antwort von 1.1.1.1: Bytes=1472 Zeit=22ms TTL=55
Antwort von 1.1.1.1: Bytes=1472 Zeit=20ms TTL=55
Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 20ms, Maximum = 22ms, Mittelwert = 21msMTU im LAN mit Wireguard:
ping -f -l 1393 1.1.1.1
Ping wird ausgeführt für 1.1.1.1 mit 1393 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4ping -f -l 1392 1.1.1.1
Ping wird ausgeführt für 1.1.1.1 mit 1392 Bytes Daten:
Antwort von 1.1.1.1: Bytes=1392 Zeit=53ms TTL=56
Antwort von 1.1.1.1: Bytes=1392 Zeit=54ms TTL=56
Antwort von 1.1.1.1: Bytes=1392 Zeit=56ms TTL=56
Antwort von 1.1.1.1: Bytes=1392 Zeit=55ms TTL=56
Ping-Statistik für 1.1.1.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0Das heißt doch jetzt, da ich in Freifunk und Windows eine MTU von 1500(1472) habe, passt mit Freifunk dem Netzwerk usw. alles.
Problem ist sowie ich das sehe MTU in Verbindung mit Linux/Ubuntu?
Was ich allerdings wiederum auch nicht verstehen kann, da es mit den selben MTU Werten im WLAN funktioniert.
Zusammengefasst:
Linux
LAN ohne WG: MTU 1252 (1280) -> funktioniert
LAN mit WG: MTU keine Antwort -> funkioniert nicht
WLAN ohne WG: MTU 1252 (1280) -> funktioniert
WLAN mit WG: MTU 1392 (1420) -> funktioniert
Windows:
LAN ohne WG: MTU 1472 (1500) -> funktioniert
LAN mit WG: MTU 1392 (1420) -> funkioniert
WLAN ohne WG: MTU 1472 (1500) -> funktioniert
WLAN mit WG: MTU 1392 (1420) -> funktioniert
Wäre so einfach mal nen Wireshark Trace zu ziehen, aber nö, man wandert lieber im Dunkeln und bricht sich die Finger an der nächsten Wand 🤣.
Btw. Config sehen wir hier immer noch nicht geschweige denn zumindest mal die IP-Adressierung, Routing-Tabelle (IPv6/IPv4) & Co. ... so wird das sonst nix hier.
Btw. Config sehen wir hier immer noch nicht geschweige denn zumindest mal die IP-Adressierung, Routing-Tabelle (IPv6/IPv4) & Co. ... so wird das sonst nix hier.
1sudo apt install wireguard
cd /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickeyNeue WG Verbindung erstellt:
Oben erstellter Privatekey in die GUI bei Geheimer Schlüssel eingetragen:
Und den Publickey vom Mikrotik Router bei Öffentlicher Schlüssel eigetragen:
Ich habe nur die Schlüsselerstellung im Terminal eledigt.
Rest wurde nur in der GUI erledigt.
Da sieht man schon den ersten Fehler mit dem du dir unwissentlich einen Bypass gebaut hast. Du machst ausschließlich einen IPv4- und keinen IPv6-Redirect, wenn du im LAN oder WLAN nun auch eine öffentliche IPv6 Adresse bekommst, nehmen die Pakete den Weg nicht mehr über den Tunnel sondern gehen über den lokalen Internet-Anschluss raus wenn per DNS Anfrage eine IPv6 Adresse geliefert wird. Wenn ein GW Redirect dann bitte auch vollständig und mit IPv6 über den Tunnel schicken sonst ist das ja witzlos denn man will ja dann i.d.R. komplett über den Tunnel surfen und nicht nur "halb".
2
Wie muss ich dann vorgehen? Muss ich in WG die IPv6 Methode auf automatisch setzen? Die Gegenstellen, an dem der WG Server sitzt, hat aber keine IPv6 oder ist das egal, da es dann trotzdem aufgelöst wird?
Oder muss ich in den Ethernet Einstellungen die IPv6 deaktivieren, dass ich keine IPv6 von Freifunk zugewiesen bekomme?
Oder wie ist hier das beste vorgehen?
Bezüglich Wireshark, ich habe das nicht vergessen, aber nutze ich nie. Tue mich da sehr hart hier was zu liefern.
Oder muss ich in den Ethernet Einstellungen die IPv6 deaktivieren, dass ich keine IPv6 von Freifunk zugewiesen bekomme?
Oder wie ist hier das beste vorgehen?
Bezüglich Wireshark, ich habe das nicht vergessen, aber nutze ich nie. Tue mich da sehr hart hier was zu liefern.
Du benutzt ja das wenig performate Gateway Redirect in deinem WG Setup statt Split Tunneling. Wie oben vom Kollegen @BiberMan schon gesagt aber nicht für IPv6 obwohl du in einem Dual Stack Umfeld arbeitest. Korrekt wäre dann ein
AllowedIPs = 0.0.0.0/0, ::/0 im WG Setup
Mit dem Rüstzeug kann es sogar ein Laie bedienen. Ein Administrator sowieso.
AllowedIPs = 0.0.0.0/0, ::/0 im WG Setup
aber nutze ich nie.
Ziemlich traurig für einen Administrator! Tue mich da sehr hart hier was zu liefern.
Das muss es ja nicht: Wireshark SchnellschulungMit dem Rüstzeug kann es sogar ein Laie bedienen. Ein Administrator sowieso.
Zitat von @wusa88:
Die Gegenstellen, an dem der WG Server sitzt, hat aber keine IPv6 oder ist das egal, da es dann trotzdem aufgelöst wird?
Wenn der WG-Server bzw. der Router dort keine globale IPv6 hat (echt jetzt, das hat doch heutzutage fast jeder Provider? 🤔) macht ein IPv6 Redirect mittels ::/0 in den AllowedIPs natürlich keinen Sinn, in dem Fall solltest du IPv6 auf dem LAN oder WLAN IF deaktivieren damit dieser Traffic nicht am Tunnel vorbei fließt.Die Gegenstellen, an dem der WG Server sitzt, hat aber keine IPv6 oder ist das egal, da es dann trotzdem aufgelöst wird?
1
Ich verstehe es trotzdem nicht. Hier mal per Screenshot zusammengefasst, wie die WLAN und LAN Schnittstelle aussieht.
WLAN Interface:
LAN Interface:
Die WG Config ist in beiden Fällen die selbe.
Für mich sieht WLAN und LAN auch gleich aus.
Im WLAN ohne Probleme.
Im LAN geht nichts.
Am Freifunk LAN kann es aber nicht liegen, da es mit Windows funktioniert.
Ich komme hier irgendwie nicht weiter. Ich muss mich doch mal mit Wireguard beschäftigen. Vielleicht bringt mich das weiter. Aber momentan hänge ich hier irgendwie fest.
Auch ein Redirect von IPv6 hat nicht gebracht.
WLAN Interface:
LAN Interface:
Die WG Config ist in beiden Fällen die selbe.
Für mich sieht WLAN und LAN auch gleich aus.
Im WLAN ohne Probleme.
Im LAN geht nichts.
Am Freifunk LAN kann es aber nicht liegen, da es mit Windows funktioniert.
Ich komme hier irgendwie nicht weiter. Ich muss mich doch mal mit Wireguard beschäftigen. Vielleicht bringt mich das weiter. Aber momentan hänge ich hier irgendwie fest.
Auch ein Redirect von IPv6 hat nicht gebracht.
Auch ein Redirect von IPv6 hat nicht gebracht
Tja, wie denn auch wenn das WG Interface keinerlei IPv6 Config hat und am Ende am Server auch nicht, geschweige denn das du dann dort den IPv6 Traffic zus. auch hättest NATen müssen wenn du kein festes IPv6 Netz hast.
Du solltest die IPv6 Seite deaktivieren.
Nicht denken sondern nachdenken lautet die Devise!
1
Das habe ich auch schon versucht. LAN Schnittstelle und WG IPv6 deaktiviert.
Funktioniert aber leider auch nicht.
Funktioniert aber leider auch nicht.
LAN Schnittstelle und WG IPv6 deaktiviert.
Nur zur Info: WIE hast du das denn bewerkstelligt? /etc/sysctl.d/ und Reboot ? 🤔
Nein per GUI. IPv6 deaktivert und Reboot.
Ich habe jetzt Wireshark installiert.
Ich kann auch die Pakete mitschneiden.
In dem Tutorial von @aqui wird nur ganz grob angerissen, wie und was Wireshark ist und die ersten Filter gesetzt werden.
Was muss ich in meinem Fall beobachten und wie muss ich hier am besten vorgehen?
Ich habe jetzt Wireshark installiert.
Ich kann auch die Pakete mitschneiden.
In dem Tutorial von @aqui wird nur ganz grob angerissen, wie und was Wireshark ist und die ersten Filter gesetzt werden.
Was muss ich in meinem Fall beobachten und wie muss ich hier am besten vorgehen?
Nun, beibringen können wir dir hier die TCP Grundlagen & Co. natürlich bei weitem nicht. Ausschau halten kannst du aber nach häufigen Retransmissions und fragmentierten Paketen, das deutet dann meist auf ein MTU Problem hin. Oder nach ausbleibenden Antworten etc.. Das kannst du mit einem Mittschnitt vergleichen bei dem es hingegen läuft.
Ansonsten bleibt nur das du uns zwei Mittschnitte bereitstellst dir wir uns ansehen können.
Ansonsten bleibt nur das du uns zwei Mittschnitte bereitstellst dir wir uns ansehen können.
1
Sobald ich Wireguard im LAN starte, hagelt es TCP Retransmission Fehler:
Auch Fragmented IP Protokoll taucht relativ oft auf.
Diese Verhalten fällt mir bei WLAN nicht auf.
Diese Verhalten fällt mir bei WLAN nicht auf.
wird nur ganz grob angerissen, wie und was Wireshark ist und die ersten Filter gesetzt werden.
Ist ja bewusst so gehalten damit auch Laien damit schnell klar kommen und nicht gleich überfordert werden. Fragmented IP Protokoll taucht relativ oft auf.
Wie oben schon gleich vermutet sehr wahrscheinlich ein MTU Problem.
Woher kann dann ein MTU Problem kommen?
Ich kann das Freifunk LAN ausschließen, da es mit Windows im LAN funktioniert.
Im Freifunk WLAN ist auch alles in Ordnung.
Es muss dann vermutlich irgendetwas mit Linux zu tun haben bzw. mit Linux und dem LAN Anschluss.
Wie kann ich vorgehen und so ein MTU Problem zu beheben?
Ich kann das Freifunk LAN ausschließen, da es mit Windows im LAN funktioniert.
Im Freifunk WLAN ist auch alles in Ordnung.
Es muss dann vermutlich irgendetwas mit Linux zu tun haben bzw. mit Linux und dem LAN Anschluss.
Wie kann ich vorgehen und so ein MTU Problem zu beheben?
Woher kann dann ein MTU Problem kommen?
Der Router der die Tunnel und ggf. die PPPoE Verbindung bedient sendet auf dem LAN Interface eine falsche MSS Segment Size an die Endgeräte. Diese "denken" dann das es die klassischen 1500 sind und senden zu große Pakete und erzwingen damit eine Fragmentierung am Router.Vermutlich also ist der böse Buhman eher nicht dein Ubuntu sondern dein Router?!
Zitat von @wusa88:
Woher kann dann ein MTU Problem kommen?
Ich kann das Freifunk LAN ausschließen, da es mit Windows im LAN funktioniert.
Im Freifunk WLAN ist auch alles in Ordnung.
Es muss dann vermutlich irgendetwas mit Linux zu tun haben bzw. mit Linux und dem LAN Anschluss.
Woher kann dann ein MTU Problem kommen?
Ich kann das Freifunk LAN ausschließen, da es mit Windows im LAN funktioniert.
Im Freifunk WLAN ist auch alles in Ordnung.
Es muss dann vermutlich irgendetwas mit Linux zu tun haben bzw. mit Linux und dem LAN Anschluss.
Finde den Fehler:
Linux
LAN ohne WG: MTU 1252 (1280) -> funktioniert
LAN mit WG: MTU keine Antwort -> funkioniert nicht
LAN ohne WG: MTU 1252 (1280) -> funktioniert
LAN mit WG: MTU keine Antwort -> funkioniert nicht
WLAN ohne WG: MTU 1252 (1280) -> funktioniert
WLAN mit WG: MTU 1392 (1420) -> funktioniert
WLAN mit WG: MTU 1392 (1420) -> funktioniert
Wenn ein Paket ohne zusätzlichen Tunnel kleiner ist als mit zusätzlichem Tunnel wiederspricht sich ja schon in sich ...
"funktioniert" heißt erst mal gar nichts auch wenn es für dich "scheinbar" funktionell anfühlt muss es im Background noch nicht richtig sein.
Wie kann ich vorgehen und so ein MTU Problem zu beheben?
Indem du die MTU auf dem LAN und dem WG IF statt auf "Automatisch" manuell festlegst oder mal die MSS am Router der das Freifunk aufbaut checkst ...1
IIRC werden bei Freifunk die Datenpakete mehrfach gekapselt. Dadurch ist die "Nutz-MTU" relativ klein und kann von Freifunk zu Freifunk unterschiedlich sein.
Hast du zufällig ICMP deaktiviert / geblockt?
Eigentlich sollten die Netzwerkgeräte bei zu großen Paketen anfangen die MTU runter zu schrauben.
Hast du zufällig ICMP deaktiviert / geblockt?
Eigentlich sollten die Netzwerkgeräte bei zu großen Paketen anfangen die MTU runter zu schrauben.
1Hast du zufällig ICMP deaktiviert / geblockt?
Tja, habe ich oben zu Beginn schon drauf hingewiesen, leider wird hier nie was vollständig beantwortet sondern immer wieder "Funktioniert doch im WLAN" geantwortet. Geschweige denn IP-Adressierung im LAN und WLAN / Firewall Settings gepostet usw. das müssen wir uns hier selbst dazu dichten.1
Ja, ist alles im Nebel stochern.
Habe ich es richtig gesehen? WG-Tunnel über Freifunk?
und iirc bekommt mean bei den meisten Freifunks eine echte IPv6 am Endgerät.
Idealerweise würde ja eine Skizze des "Netzwerkaufbaus" und perfekterweise ein Wireshark mitschnitt helfen.
Habe ich es richtig gesehen? WG-Tunnel über Freifunk?
und iirc bekommt mean bei den meisten Freifunks eine echte IPv6 am Endgerät.
Idealerweise würde ja eine Skizze des "Netzwerkaufbaus" und perfekterweise ein Wireshark mitschnitt helfen.
1Firewall Settings gepostet
Auf die Firewall von Freifunk habe ich keinen Zugriff.Hast du zufällig ICMP deaktiviert / geblockt?
sudo ufw status
Status: InaktivAber um das ganze mal zu "verallgemeinern". Es betrifft nicht nur das Freifunk Netz, sondern auch andere Netze funktionieren mit Ubuntu am LAN nicht bzw. nicht wenn WG aktiv ist.
IP-Adressierung im LAN und WLAN
Willst du die ip aIch muss aber ehrlich gestehen, dass ich davon zu wenig Ahnung habe.
