HTTP/HTTPS zu einem Subnetz funktioniert nicht über WireGuard

Started by intelliIT, January 13, 2025, 10:00:56 AM

Previous topic - Next topic
Ich glaube, ich habe hier ein etwas kniffliges Problem.

Ich habe mehrere Road-Warrior-Clients, die über WireGuard mit meiner OPNsense verbunden sind. Die OPNsense steht hinter einem DSL-Router+Modem, auf dem die VPN-Ports weitergeleitet sind.

Ich habe ein Problem mit einem spezifischen Intranet-Subnetz (`10.9.0.0/24`), wenn ein Windows-Client über DSL (Vodafone DSL) eine Wireguard-Verbindung aufbaut. Das Problem tritt nur bei einem bestimmten Nutzer auf.

# Symptome:

* HTTP/HTTPS-Verkehr zu `10.9.0.0/24` schlägt fehl (z. B. SSL-Handshake-Fehler).
* Ping- und DNS-Anfragen zu `10.9.0.0/24` funktionieren problemlos.
* Jeglicher Verkehr zu einem anderen Subnetz (z. B. `10.12.0.0/24`) funktioniert ohne Probleme.
* Der Wechsel auf einen anderen Internetzugang (z. B. mobiler Hotspot) löst das Problem.

Beide Subnetze befinden sich auf der gleichen Switching-Hardware und nutzen denselben Link zur OPNsense, mit VLANs getrennt.

Ich habe alle grundlegenden Dinge überprüft, wie Konfigurationen, Routing, NAT, Firewall-Regeln usw.
Bei der MTU bin ich mir unsicher, da grundsätzlich Verkehr funktioniert, aber ,,komplexere" Anwendungen fehlschlagen.
Ich sehe Pakete und Anfragen, aber die Handshakes gelingen nicht.
Ich werde versuchen, einen Packet-Capture zu erstellen, sobald der Nutzer diesen Internetzugang wieder verwendet.

Hat jemand eine Idee?
Ich verstehe es nicht wirklich.
Ich glaube nicht, dass ich vom ISP Hilfe bekomme.

Ich hatte mal ähnliche Probleme, ausgelöst durch MTU 1500 vs 1492. Da fehlen für Handshakes essentielle Bytes.

auf welchem interface?
lokal beim nutzer oder am vlan-trunk auf der opnsense?
warum hat dann nur ein nutzer von ca. 35 dieses problem?
und warum scheint das von ip-adressen beeinflusst.

Keine Ahnung, was bei Dir das Problem ist. Hier musste das Problem für jeden User separat dadurch gelöst werden, dass in die (jede! - also die Config jeweils auf beiden Seiten des Tunnels) Wireguard-Config im [Interface]-Abschnitt "MTU = 1500" eingetragen wurde.

Insofern könnte es schon sein, dass User-spezifische Probleme durch MTU verursacht werden. Je nachdem, wie die Netzwerkkonfiguration ansonsten so aussieht.

Quote from: intelliroadIT on January 13, 2025, 10:00:56 AMIch habe ein Problem mit einem spezifischen Intranet-Subnetz (`10.9.0.0/24`), wenn ein Windows-Client über DSL (Vodafone DSL) eine Wireguard-Verbindung aufbaut. Das Problem tritt nur bei einem bestimmten Nutzer auf.
Gibt es irgendeinen anderen Nutzer, der ebenfalls einen Vodafone DSL benutzt, und bei dem es läuft?

Quote from: Uzi on January 13, 2025, 08:12:05 PM
Quote from: intelliroadIT on January 13, 2025, 10:00:56 AMIch habe ein Problem mit einem spezifischen Intranet-Subnetz (`10.9.0.0/24`), wenn ein Windows-Client über DSL (Vodafone DSL) eine Wireguard-Verbindung aufbaut. Das Problem tritt nur bei einem bestimmten Nutzer auf.
Gibt es irgendeinen anderen Nutzer, der ebenfalls einen Vodafone DSL benutzt, und bei dem es läuft?
das weiss ich leider nicht.

Dann fällt mir im Moment nur noch folgendes ein:
Den betroffenen Rechner über DSL verbinden. In der Kommandozeile ein "ipconfig /all" auslösen, Ergebnis rauskopieren und speichern.
VPN-Verbndung aufbauen, wieder "ipconfig /all", Ausgabe speichern.

Schauen, ob da irgendwas auffälliges ist, z.B. eine lokal verwendete 10.9.x.x Adresse.
Eventuell auch mal mittels traceroute ("tracert") eine IP aus dem problematischen Netz "ansteuern" und die Wege vergleichen. Auch mal mit DSL und VPN (könnte eventuell nicht gehen) und Hotspot und VPN (sollte ja gehen) vergleichen.

Werden denn die Hostnamen bei Ping identisch aufgelöst, egal ob über DSL oder Hotspot?

Die Routing-Tabelle würde ich mir auch noch geben lassen.
Wenn wir hier von Windows sprechen: "route print".

falls jemand anderes darüber stolpert, mit einem MTU = 1360 in der wireguard-config funktioniert es mit dem Vodafone DSL des nutzers ohne probleme.
icmp-pakete -f und 1360 < size < 1400 gehen verloren, während alles > 1400 needs to fragment meldet.

ist mss-clamping auf der server-seite das richtige, um diese probleme für alle zukünftigen benutzer zu verhindern?