Messages

Hi,

I guess I have the same issue here. My Wireguard clients connect fine to my OPNSense VPN. They can easily do everything with the hosts on the remote LAN. So Wireguard --> LAN is fine.

But as soon as those clients (happens on a Mac as well as on an iPad) have established the VPN connection they do not have access to the Internet.

I guess there is a rule missing but I do not know which rule I have to add. I have allowed all traffic in the Wireguard interface to everywhere. But no good.

So which rule on which interface do I have to add? Might this be related to outgoing NAT? I set it to fully automated...

Anyone a hint for me (and the OP I assume)?

Thanks!

/KNEBB

Mea culpa!

In der OPNSense Gegenstelle war der Pub-Key der OPNSense eingetragen, nicht der PubKey des iPads...


Ok, ich komme jetzt auf die Geräte im LAN (zB ping).

Trotzdem danke an alle, die sich das durchgelesen haben

Moin,

wahrscheinlich bin ich zu verkopft. Aber irgendwie kriege ich es nicht hin, mein iPad mit meiner WireGuard-Instanz zu verbinden. Helft mir bitte auf die Sprünge...

Was habe ich getan:

• In OPNSense Wireguard VPN aktiviert. Funktioniert auch grundsätzlich (z.B. mit einem MacBook)
• Über Gegenstellen-Generator einen Gegenstelle generiert
• Den QR Code. dort mit der WireGuard App auf dem iPad gescannt - gültige Konfig!
• Eine neue Gegenstelle unter Gegenstellen mit dem Priv/Pub Keys aus dem vorherigen Schritt erstellt
• Auf dem iPad mit dem Hotspot des Handys verbunden
• VPN WireGuard App - Tunnel aktiviert
• Unter OPNSense- VPN- Wireguard - Status ist der Status der Gegenstalle iPad GRÜN
• Kein ping, kein Traffic, kein garnix vom iPad möglich....
• Keine Einträge in der Protokolldatei

Ich muss doch irgendwie rausbekommen, was da falsch ist.... irgendjemand eine Idee?

/KNEBB

Das (alte) Menü wird ja dann bestimmt auch irgendwann wegfallen. Migration hat wunderbar geklappt, aber jetzt habe ich natürlich zwei Einträge im Menü: "Rules [new]" und "Regeln".

Ja, ist absolut nicht wichtig aber weiß jemand die Roadmap, wann das wieder "ordentlich" aussieht, also richtige Sprache und keine zwei Einträge, wenn das eine überflüssig ist?

/KNEBB

Jo, haste recht. Die Fritzbox 6660 ist aber normalerweise eine "Cable". Da ist es nicht ganz so trivial, die OPNSense mit Ethernet an das Koax-KAbel zu kriegen...

Aber letzendlich wird das hier jetzt akademisch- ich denke, die ThomasKrenn Kiste tut es für den Zweck wunderbar und liegt noch unter 50% des Budgets.

Sie macht kein PPPoE- da hängt ihrer Beschreibung nach eine Fritzbox davor. Also: passt!

Also für eine OPNSense Firewall scheint mir das Teil genial zu sein!
4x Intel NIC.

4GB RAM reichen für normale Anwendungen locker aus!

Und auch die CPU macht es an einem Glasfaseranschluß problemlos- solange man da kein intensives VPN macht! Aber zum rumspielen mit VPN reicht auch das!

Also, das scheint mir eine ideale Preis/ LEistungskombi zu sein.

120€ sind fast unschlagbar. (Aufpassen, TK schreibt nur Nettopreise hin, ist halt für Geschäftskunden)

Ich selbst nutzt den LES 2x- ein geniales Teil. Allgemein sind die TK Kisten von sehr guter Qualität. Haben meist aber auch ihren PReis.

Moin,

also grundsätzlich geht es? Es ist nur lahm? Nur messbar oder tatsächlich fühlbar langsamer?

MAch' nochmal einen Bandbreitentest und schau Dir die OPNSense Auslastung währenddessen an (GUI oder Konsole "top"). Ist da etwas auffälliges?

Du hast noch einen anderen Router? Dann versuche doch mal das Folgende:
Anderer Router anklemmen, OPNSense kommt an dessen lokales Interface. Alle anderen Systeme weiterhin in das LAN der OPNSense. Dann nimmst du einen Rechner und testest mal wieder die Bandbreite via OPNSense-Router-Internet und einmal direkt im LAN des Routers: Router-Internet.
Gibt es da massive Unterschiede?
Warum so testen? Durch die notwendige Umkonfiguration des WAN Interfaces der OPNSense schließen wir evtl. Mißkonfigurationaus, ebenso wie Probleme mit dem Provider.
Wenn beides gleich schnell ist, müssen wir uns die WAN-Konfiguration der OPNSense anschauen.
HAben wir einen deutlichen Speed-Unterschied, liegt es tatsächlich an einer Misskonfioguration deR OPNSesnse.

Also? Wie ist das Ergebnis des Testes?

/KNEBB

Schließe mich den Vorrednern an,

allerdings wissen wir zu wenig über Eure Struktur, um konkrete Fehleranalysen machen zu können.

Eine weitere Möglichkeit ist es, dasss Du die beiden Interfaces vertauscht hast...sei es physikalisch oder über die Schnittstellenzuordnung.

Habt ihr denn überhaupt ein getrenntes LAN? Oder ist das alles ein flaches Netz, auch über die externe Anbindung hinaus? Wer stellt denn aktuell den DHCP-Server?

Fragen über Fragen, ohne DEtails läßt sich da nicht viel helfen.

/KNEBB

[Aaaaber:]

Moin!

Du kannst natürlich vieles machen. Und auf den erstetn BLick habe ich jetzt keinen Punkt gesehen, der sofort ein "geht nicht" ausgelöst hätte.

Aaaaber:

Mache eines nach dem Anderen. Wenn ein es sicher, stabil und zuverlässig läuf, nimm das nächste in Angriff. Nicht alles auf einmal. So wie ich Dich aufgrund des Postes einschätze solltes Du ca. ein Jahr einplanen, bis Du alles aus der Liste umgesetzt hast!

Ein paar Tipps zur Reihenfolge:

• Tatsächlich zuerst die VLANs einrichten. Mit Firewall-Regeln etc. hast Du genug zu tun, bis die Netze auch untereinander wirklich so getrennt sind, wie Du das willst. Server, NAS etc. kommen ins gleiche VLAN wie die Clients. Üblicherweise da auch Tablets, Handys etc. Alles, was IoT ist und "nach Hause telefoniert" geht ins VLAN IOT. GästeVLAN ist eine gute Idee, macht aber nur Sinn, wenn Du da kein Passwort hast (oder das ganz einfach via QR-Code o.ä. den Gästen mitteilen kannst. Wenn man eh' ein Passwort fragen muss, kann man auch gleich das vom "richtigen" Netz geben --> wird sind alle menschlich. Ich habe mein Gäste-(V|W)LAN hier wieder abgeschafft.
• Dann gerne Unbound als WErbefilter- und sehen, ob der die gewnschte Unterscheidung nach VLAN macht (glaube nicht!)

Das würde ich tatsächlich so umsetzen. Die folgenden Sachen würde ich ganz sein lassen, das ist oft mit Kanonen auf Spatzen geschossen:

• IDS und IPS. Die Einrichtung UND Überwachung frißt wahnsinnig viel Zeit und lohnt sich in den seltensten Fällen (99% fake alarms)
• Radiusserver. Dafür brauchst Du ein zentrales Benutzerverzeichnis (LDAP, AD,...). Auch hier das Gleiche: Riesenaufwand, auch mit der Pflege, lohnt sich für Heimanwender nicht

Und dann kommen noch die VPN-Sachen:

• Net2NEt-VPN zu den Eltern. Nicht ganz trivial aufzusetzen, da Du beide Geräte konfigurieren musst (Fritz! und OPNSense) und jede ein wenig einen anderen UI-Dialekt hat... musst Du hier nachlesen, klappen sollte das. Und: einmal eingerichtet, läuft das stabil
• RoadWarrior-VPN: Am besten mit Wireguard umsetzen, das funktioniert echt gut und für viele Geräte (Tablets, etc. gibt es auch eigene WireguardApps). Ist aber grundsätzlich ein wenig "Fummelei" und erfordert wirkliches beschäftigen mit der Materie.

Bei den wenigen VPN-Nutzern sollte die CPU das gut schaffen, zu den anderen Server/LAN-Fragen sage ich mal nichs, ist hier etwas off-Topic.

Also, Fahrplan:
-OPNSense installieren (sofern noch nicht gemacht), im bestehenden LAN schauen wie sie so funktioniert und nur absolute Basiskonfiguration machen.
-VLANs trennen, Geräte entsprechend dorthin verschieben
-RoadWarrior VPN einrichten
-NEt2NEt VPN einrichten
Mit ausgibigem Testen und dem Erleben in der Praxis rechne mal pro Punkt 2-3 Monate. Nicht das erstmalige Einrichten, aber das Testen in der Praxis...

/KNEBB

Snapshot geht aber nur, wenn das VMs sind... auf Hardwaare geht das nicht so einfach ;)

Habe zwei Kisten (HW) hier vor kurzem aktualisiert. Als Vorbereitung bin ich von ISC DHCP auf KEA DHCP (v4 only) umgestiegen. Update lief problemlos. Nur bei einer Kiste ist der Kea nach dem Update nicht gestartet. Hatte wohl irgendwie ein Interface namens usb0 in der Konfig. Habe dem dann ein Interface weggenommen, gespeichert, Interface wieder hinzugefügt, gespeichert- lief!

Beim zweiten gab es keine Probleme!

/KNEBB

Hi,

I just migrated from ISC to KEA. It was smoothless.

Configured basic things like DNS and NTP.

On the ISC top left of the static lease list (looks like a calc sheet) to export the configured static leases.
In KEA import the csv as reservations and it worked out of the box!

I had some understanding problem with the default gateway- but this is taken from the interface address on OPNSense.

/KNEBB

Ok, re-read the specs and can confirm the above offered "delete the ip on server" appears to be working. Although with a minor inconvinience:

For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
-client A has IP .12 and its leases got deleted on the server side
-client A still uses this IP as long as half of lease time hast not elapsed
-client B starts DHCPDISCOVER to get an IP
-server offers IP .12 to client B as it is marked as available
-client B sends an ARP request to check the IP
-client A sends ARP reply ("this is my IP")
-client B send DCHPDECLINE to server
-server marks this IP as "invalid" for further usage
-client B starts over with DHCPDISCOVER
-server offers different IP .13 to client B and client B uses this one...
-on the client A when half lease time has elapsed it'll ask for further usage of IP .12
-server declines further usage (as it is marked invalid) with DHCPNACK
-client A starts over with DHCPDISCOVER and will get a different IP .14

So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.

The minor glicht I mentioned is the fact there is an IP address in use which (for the server) has not bee assigned. At least for half of lease time.
And this is not reflected in the server state...

And there is a second problem:
The IP will not be release or renewed before half of the lease time has passed. So when using a static lease for this client it will use the IP not earlier. And this is the same for both cases where I delete the lease on server side or create a static lease....

So I still do not REALLY see the advantage of such a "delete" functionality.


/KNEBB

Moin,

ich habe jetzt nur überflogen. Aber Du müsstest den Wireguard auf der zweiten Kiste ebenfalls als Server einrichten. Wenn der sich nämlich "nur" als Client betrachtet, wird er keine Pakete ins LAN weiterleiten....
Ich habe das hier genauso.
Eine Net-2-Net Verbindugn mit zwei Wireguard-Servern auf der OPNSense, die sich gegenseitig kennen udn PAkete weiterleiten. Lan1 zu Lan2 funktioniert problemlos. Zusätzlich einen zweiten Wireguard Server auf der einen OPNSense eingerichtet, die die "RoadWarrior" (z.B. Windows, Linux, Tablets etc.) evom Internet aus einbinden kann.

Funktioniert wunderbar.

I'm unclear why other DHCP products and even at least some past DNSMasq products were able to help here, but this one won't.

They faked it! @Monviech (Cedrik) has confirmed my post: there is no way a given lease can be recalled! Earliest will be half of lease time. If there were products offering a "delete lease" button they deleted the mapping but did not remove the IP from the client.

You can archive your goal but you have to re-design your setup then. Create static mappings for you known clients, reduce lease time for unknown clients. You might consider to move dynamic clients to a different (V)LAN if this option is not suitable. Or join you new client to a different net to discover the MAC (although it is mostly written somewhere), create a static mapping and move it to the target net.

However: based on technical implementation you simply can not "delete" a given lease. If other product offer this it is faked!