ubuntuusers.de

Zur Einführung ein Überblick über die Konfiguration.

Mein LAN befindet sich hinter einer pfsense, die direkt mit dem ONT verbunden ist. Einwahl per PPPoE, DS-Lite, also nur IPv6. Auf der pfsense ist Wireguard konfiguriert. Das funktioniert auch. Alle FW-Rules sind gesetzt. Per Android (tablet, Smartphone) komme ich auch per Wireguard und https auf die Loginseite im LAN meiner pfsense, kann mich einloggen. Dito auf andere https-Seiten und auch ssh ist möglich.

Leider ist das alles mit identischen Einstellungen in der /etc/wireguard/wg0.conf nicht mit dem Xubuntu Notebook möglich. Per ping (icmp) kann ich die LAN-IPv4 der pfsense erreichen und erhalte Antworten. Bei https gibt es aber irgendwann einfach einen Timeout. Dito bei ssh zu Servern im LAN. Auch serverseitig haben die Android-Geräte keine andere Config als die Notebooks. Lediglich die Credentials sind unterschiedlich und natürlich die IPv4-Adresse die beim Verbindungsaufbau fürs Netz des WG-Tunnels vergeben wird. Passende Rules für TCP 443 und TCP 22 sind natürlich für alle Geräte vorhanden und unterscheiden sich nicht.

Warum also komme ich trotz identischer Configs mit meinem Tablet aus dem Mobilfunknetz und mit Wireguard z.B. per https auf Web-Interface meiner pfsense, oder dem des WLAN-AP's, etc. aber eben nicht mit Xubuntu?

Eine Fehlkonfiguration der pfsense und von Wireguard schließe ich aus. Habe mehrfach alles überprüft und verglichen. Es muss an einem Unterschied zwischen *buntu und Android liegen, dass es mit dem einen OS klappt, dem anderen aber nicht.

Hat jemand eine Idee, an welcher Stelle ich noch suchen kann?

coraggioso schrieb:

... aber eben nicht mit Xubuntu?

Evtl. hast Du nicht die richtige MTU für den WG-Tunnel (WG-Interfaces) konfiguriert. Versuch mal mit 1392

Wenn du mit deinem Tablet aus dem Mobilfunknetz über Wireguard auf dein https Zielsystem kommst, solltest du kurz prüfen, in welchem Netz dein Xubuntu Rechner steht und welche Komponenten sich noch zwischen diesem und deinem Zielsystem befinden (Router, Firewall usw).

Prüfe mal mit z.B. Wireshark, welche Telegramme da noch im Spiel sind und welchen Status diese Kommunikation hat. Auch ein "traceroute" kann da schon einen kleinen Überblick über die beteiligten Hops schaffen.

lubux schrieb:

Versuch mal mit 1392

Danke lubux das wars.

Mit 1392 gehts. Default gibt die pfsense 1420 vor. Hatte das schon auf 1412 abgesenkt, wegen IPv6 und WireGuard MTU Size 1412 – Best Practices IPv4/IPv6 – MTU Berechnen. Mit 1420 und weil ich eben von extern wegen DS-Lite nur IPv6 habe, hatte ich schon 1412 genommen und mit Android klappt das auch und mutmaßlich wohl auch mit Windows. Solche Empfehlungen wie im oben verlinkten Beitrag werden ja mutmaßlich mit irgend so einem Windows getestet.

Also Problem ist gelöst. Würde mich jetzt nur noch interessieren, warum Android 1412 ausreichen, *buntu aber 1392 braucht?

Android wird das mit der Fragmentierung, anders handhaben bzw. evtl. PMTUD benutzen.

Ein Problem kann es auch sein wenn ICMP blockiert wird, dann klappt das mit der PMTU Discovery nicht so wirklich.

Danke encbladexp für den Hinweis, aber ping (ICMP) war und ist auf meiner pfsense erlaubt.

Ich habe mir mal per

tracepath

die pmtu in einem Wireguard-Tunnel zu einer Fritte angesehen. Ist dort 1392. Auf Fritten kann man die gar nicht konfigurieren. Wenn man da einen anderen, als den Default-Wert will muss man das schon direkt in die Config des Clients schreiben.

Ich gehe mal davon aus, dass die Fritten-Fritzen sich bei der Default-Vorgabe 1392 schon was gedacht haben und der Hinweis von lubux genau der richtige Hinweis war.