Hallo liebe Mitmenschen :-)
Als Neueinsteiger in OPNsense mit leidlich Netzwerkerfahrung muss ich hier mal um Hilfe bitten, denn wahrscheinlich
bin irgendwo zu blöd ...
Ich habe ein Netzwerk 10.20.x.x mit der Maske 255.255.0.0, und kann von einem PC im LAN mit der 10.20.7.94/16 auch alle Knoten erreichen, wie z.B. 10.20.7.27 und 10.20.1.28.
Ich habe, Schritt für Schritt der OPNSense Dokumentation folgend, eine Wireguard VPN Instanz und einen Peer erzeugt, die angegebenen Routen eingetragen, und kann von einem nicht im LAN befindlichen PC mit dem aktuellen Wireguard Client die Rechner 10.20.7.94 und die Firewall mit der 10.20.7.27 erreichen, aber keinen der Knoten im Bereich 10.20.1.x wie z.B. die 10.20.1.28.
Das LAN Interface in der OPNsense ist mit IPv4 address 10.20.7.27 / 16 konfiguriert, das WAN Interface als IPv4 auf DHCP (hängt hinter einer Fritzbox, die eine feste IP-Adresse über DSL hat) und trotz allem herumsuchens finde ich nicht, wo mir eine falsche Netzmaske den Zugriff auf des gesamte Netz (10.20.x.x) verwehrt und mich nur auf den Bereich, in dem auch die Firewall ist (10.20.7.x) lässt.
Kann mir jemand einen Tipp geben, was ich hier falsch mache ?
Das klingt so als wäre in den Allowed IPs in der Client config ein /24 statt /16 angegeben.
hallo, danke für deine rückmeldung.
nein, die client config sieht so aus:
[Interface]
PrivateKey = ...........................
Address = 10.10.10.4/32
MTU = 1420
[Peer]
PublicKey = .................................
Endpoint = ...:51820
AllowedIPs = 10.10.10.0/24,10.20.0.0/16
PersistentKeepalive = 25
Hallo,
Quote from: Alwin on April 16, 2026, 10:03:07 PMaber keinen der Knoten im Bereich 10.20.1.x
die Firewall-Regeln am Wireguard Interface erlauben das?
Beachte auch, das keine Netzwerk-Überschneidung mit dem lokalen Subnetz des Clients vorliegt.
Quote from: Alwin on April 16, 2026, 10:03:07 PMleidlich Netzwerkerfahrung
Was soll denn das für eine Erfahrung sein, alles schreit nach keinerlei Ahnung.
Warum ist 10.20.0.0/16 bei den allowed IPs zu sehen...
gut - ich habe anscheinend tatsächlich keine Ahnung, sorry. Die Allowed IPs sind, wenn ich
das richtig verstehe, die Adressbereiche, die der WG VPN Client von aussen über die OPNsense
erreichen soll, richtig ? Das LAN der Firewall ist das Netzwerk 10.20.0.0/16, mit Adressen in den Bereichen
10.20.1.0/16, 10.20.7.0/16.
AllowedIPs ist bei WireGuard das, was auf der anderen Seite des Tunnels ist. Das ist vollkommen richtig so. @Bob.dig gezeigt ist die Client-Config ...
Quote from: viragomann on April 17, 2026, 11:58:38 AMHallo,
Quote from: Alwin on April 16, 2026, 10:03:07 PMaber keinen der Knoten im Bereich 10.20.1.x
die Firewall-Regeln am Wireguard Interface erlauben das?
Beachte auch, das keine Netzwerk-Überschneidung mit dem lokalen Subnetz des Clients vorliegt.
Der WG VPN Client ist im lokalen Netz 192.168.50.00/24 hinter einer Fritzbox/Deutsche Glasfaser
Die Firewall Regeln sind exakt so, wie in
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
erklärt
Regel LAN
Regel WAN
Regel Wireguard Interface
Quote from: Alwin on April 17, 2026, 12:54:33 PMDie Allowed IPs sind, wenn ichdas richtig verstehe, die Adressbereiche, die der WG VPN Client von aussen über die OPNsense
erreichen soll, richtig ?
Ja, genau. Die Netzwerksegmente, die der Client erreichen können soll.
Allerdings ist das Subnet 10.20.0.0/16 in der Client-Konfig anzugeben.
Der Server braucht als allowed IP nur die virtuelle Client IP kennen.
genau so ist es konfiguriert:
in der WG Instanz lautet die Tunnel Adresse 10.10.10.1/24
in der Client Konfig lauten die Allowed IPs 10.10.10.0/24,10.20.0.0/16
Okay, dann würde ich mir erwarten, dass alle Pakete für 10.20.0.0/16 auch darüber geroutet werden.
Wenn du dir sicher bist, dass es nicht die Firewall am Server selbst ist, die den Zugriff blockiert, mach mal ein Packet Capture (Interfaces > Diagnostic) am Server-Interface, um zu sehen, ob die Pakete Richtung Server korrekt raus gehen und ob dieser auch eine Antwort schickt.
Quote from: Alwin on April 17, 2026, 01:36:25 PMin der WG Instanz lautet die Tunnel Adresse 10.10.10.1/24
Mach da mal 10.10.10.1/32 draus.War Quatsch - s.u.
Quote from: Patrick M. Hausen on April 17, 2026, 01:45:30 PMMach da mal 10.10.10.1/32 draus.
?
Zitat aus den Docs - Step 1 - Configure the Wireguard Instance (https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-1-configure-the-wireguard-instance):
>
Do not use a tunnel address that is a /32 (IPv4) or a /128 (IPv6)Anm: ist dort auch in fetten Lettern
Auf der OPNsense-Seite beim Peer - der ja der "Road Warrior" ist - braucht es nur die eine IP-Adresse aus dem Tunnel-Netzwerk in AllowedIPs. Best practice ...
Es geht doch um die Tunnel IP.
Aber egal, halt mich raus. Ich hab keine Practice in WG...
Quote from: viragomann on April 17, 2026, 01:58:22 PMEs geht doch um die Tunnel IP.
Stimmt, da hatte ich mich verlesen. Danke.
Quote from: viragomann on April 17, 2026, 01:45:01 PMOkay, dann würde ich mir erwarten, dass alle Pakete für 10.20.0.0/16 auch darüber geroutet werden.
Wenn du dir sicher bist, dass es nicht die Firewall am Server selbst ist, die den Zugriff blockiert, mach mal ein Packet Capture (Interfaces > Diagnostic) am Server-Interface, um zu sehen, ob die Pakete Richtung Server korrekt raus gehen und ob dieser auch eine Antwort schickt.
hier die paketmitschnitte von lan und wg interface
ein ping der opnsense auf 10.20.1.28 funktioniert einwandfrei
Der Server auf dem die Pings nicht funktionieren, 10.20.1.28, hängt doch nicht am LAN Interface.
Ein Capture von jenem, an dem der Server angeschlossen ist, wäre relevant und gefragt gewesen.
Im WG Capture siehst du jedenfalls, dass keine Antworten rausgehen.
Quote from: Alwin on April 17, 2026, 02:58:04 PMein ping der opnsense auf 10.20.1.28 funktioniert einwandfrei
Das benötigt keine Routen, keine Firewall Regeln und funktioniert u.U. auch mit falsch gesetzten Subnetzen. Lässt also fast alle möglichen Fehler zu.
Quote from: Patrick M. Hausen on April 17, 2026, 12:58:11 PM@Bob.dig gezeigt ist die Client-Config ..
Völlig unklar, ob dem wirklich so ist. Letztlich fehlen die relevanten Angaben, wer hier was ist. Ich geh wie immer vom Schlimmsten aus. ;)
Quote from: viragomann on April 17, 2026, 03:16:26 PMDer Server auf dem die Pings nicht funktionieren, 10.20.1.28, hängt doch nicht am LAN Interface.
Ein Capture von jenem, an dem der Server angeschlossen ist, wäre relevant und gefragt gewesen.
Im WG Capture siehst du jedenfalls, dass keine Antworten rausgehen.
Quote from: Alwin on April 17, 2026, 02:58:04 PMein ping der opnsense auf 10.20.1.28 funktioniert einwandfrei
Das benötigt keine Routen, keine Firewall Regeln und funktioniert u.U. auch mit falsch gesetzten Subnetzen. Lässt also fast alle möglichen Fehler zu.
Danke für Deine Hilfe, aber der Server 10.20.1.28/16 IST im gleichen LAN wie der Rechner 10.20.7.94/16 und die OPNsense 10.20.7.27/16, alle im 10.20.0.0/16 Netzwerk. Ein falsch gesetztes Subnetz ist wohl auch eher nicht die Ursache, eine Änderung der IP der Firewall auf 10.20.1.27/16 ändert an dem Problem mit dem Wireguard Client nichts
Verstehe. Hatte es so verstanden, dass 10.20.7.0/24 das LAN ist und die Server in einem separaten Subnetz liegen, aber alles zusammen eben in 10.20.0.0/16. Wahrscheinlich weil ich dasselbe Subnetz verwende, es aber doch segmentiert habe.
Okay, also alles ist in dem /16 und hängt am selben Port der OPNsense. Aber nicht alle Geräte sind über WG VPN erreichbar.
Wie du im Packet Capture siehst, kommt von 10.20.1.28 keine Antwort, wenn die Anfrage von der VPN (aus einem anderen Netzwerksegment) kommt.
Da liegt das Problem höchstwahrscheinlich beim Server.
Du kannst jetzt noch auf dem Server selbst ein pcap laufen lassen, um zu überprüfen, ob die Anfragen da tatsächlich ankommen, jedoch habe ich da keine Zweifel.
Vielmehr läuft auf dem Server wahrscheinlich eine Firewall, die die Anfragen aktiv blockiert.
Das ist ein ganz normales Verhalten, wenn die FW in der Grundkonfiguration belassen wurde.
Du musst also vermutlich da nur den Zugriff vom WG-Netz erlauben.
Ein anderes Problem könnte sein, dass der Server nicht die OPNsense als Gateway nutzt (weil er ein anderes nutzt oder es nicht oder falsch konfiguriert ist). In diesem Fall hätte er aber auch keine Verbindung zum Internet, jedenfalls nicht über OPNsense.
Hallo Leute,
zunächst noch einmal herzlichen Dank an alle, die geschrieben haben.
Das Topic kann als (zumindest was OPNsense angeht) gelöst geschlossen werden.
Eine übers Wochenende testweise eingerichtete Sophos XG210 mit OpenVPN Client
führt zum gleichen Ergebnis, also ist irgendwas im LAN faul. Das 10.20.0.0/16
Netzwerk ist in einem Abscnitt zwischen 10.20.1.0/16 und 10.20.7,0/16 über eigene
Glasfaser verbunden, ich denke mal, das da irgendwo Medienkonverter oder ein
Switch drin verbaut sind. Obwohl Windows Clients über Ethernet alle Knoten
im gesamten Netz erreichen, können das VPN Clients über eine Firewall nicht -
sehr seltsam, hat aber hier natürlich nix zu suchen :-)
Quote from: Alwin on April 19, 2026, 09:05:16 PMHallo Leute,
zunächst noch einmal herzlichen Dank an alle, die geschrieben haben.
Das Topic kann als (zumindest was OPNsense angeht) gelöst geschlossen werden.
Eine übers Wochenende testweise eingerichtete Sophos XG210 mit OpenVPN Client
führt zum gleichen Ergebnis, also ist irgendwas im LAN faul. Das 10.20.0.0/16
Netzwerk ist in einem Abscnitt zwischen 10.20.1.0/16 und 10.20.7,0/16 über eigene
Glasfaser verbunden, ich denke mal, das da irgendwo Medienkonverter oder ein
Switch drin verbaut sind. Obwohl Windows Clients über Ethernet alle Knoten
im gesamten Netz erreichen, können das VPN Clients über eine Firewall nicht -
sehr seltsam, hat aber hier natürlich nix zu suchen :-)
nö, kann nicht. Die Bereiche müssten 10.20.1.0/24 und 10.20.7.0/24 sein, Deine 10.20.1.0/16 und 10.20.7.0/16 wären immer noch in 10.20.0.0/16 (korrekter: die richtige Netz-ID ist 10.20.0.0/16 für beide).. Sprich, wenn einem das so deutlich auffällt und Dir das nicht bewusst ist, könnte es sein, dass hier nicht richtig gesubnettet ist?