Messages

106

German - Deutsch / Re: zwei OPNsense verbinden für die administration

« on: November 03, 2024, 10:20:59 pm »

sozusagen site to site VPN zwischen den OPNsense.

Das passt nicht zum Titel, wonach du eine Verbindung für die Administration suchst.

Wenn du mit einer VPN schon Erfahrung hast, nimm doch diese.

Im Grunde sind alle geeignet, um auf Hosts auf der anderen Seite zugreifen zu können.
Wireguard ist etwas einfacher zu konfigurieren. Ich selbst hatte es aber nur mal vorübergehend im Einsatz und hatte es verworfen, weil es nicht gut mit CARP funktioniert.
IPSec (Standard, policy-based) passiert direkt im Kernel und hat damit Einschränkungen im Routing. IPSec VPN ist auch sehr robust und hat daher meinen Vorzug, aber im Fehlerfall oft mühsam zum Debuggen. Wenn du aber beide Seiten selbst kontrollierst bzw. auf der anderen Seite kein Idiot sitzt, sollte das kein Problem sein.

Aber grundsätzlich sind für die Verbindung zweier Locations und den gegenseitigen Zugriff beide geeignet, auch für den Transfer größerer Datenmengen.
Bei OpenVPN ist eben TLS und damit Zertifikate für Server und Clients zwingend. Ansonsten läuft das ebenso tadellos. Mit den neuen "Instances" habe ich aber noch keine Erfahrung gemacht.

107

German - Deutsch / Re: OPNsense und OVPN/Wireguard wollen nicht zusammen...

« on: November 03, 2024, 09:41:11 pm »

Ich bin jetzt noch Halloween so langsam wieder nüchtern. 

  War wohl eine heftige Feier...

Der Hotdog von südlich des Weißwurstequators?

👍🏼

Ich würde das jetzt nicht als sonderlich schwer ansehen. Also: Ja, habe ich. 😇

Nein, ist es nicht, aber aufgrund der Fehlerbeschreibung könnte hier am ehesten der Fehler liegen.

Ja, die Regel scheint in Ordnung zu sein.

Der Hybride Modus ist auch aktiviert?

Habe mir die Anleitung nochmals durchgesehen. Die hat ja gar kein Gateway Setting und "Dynamic gateway policy" im Wireguard Interface ist damit wohl Pflicht.
Ich vermute, ohne diesem Haken wird dir auch gar kein Gateway angezeigt am Dashboard oder in System: Gateways: Configuration?

Wireguard kenne ich nur mit manuellem Gateway Setting, bin daher da auch überfragt.
Aber ein Gateway ist natürlich essentiell fürs Routing.
Es könnte vielleicht ein Fehler in der Tunnel Adresse sein, wodurch die Kommunikation mit dem Gateway nicht zustande kommt.

Ansonsten könnte eventuell doch das Wireguard Log hilfreiche Hinweise auf das Problem liefern

Grüße.

108

German - Deutsch / Re: Ausgehende VPN Verbindungen fuer bestimmte Clients

« on: November 03, 2024, 08:40:29 pm »

Das mit den Gateways habe ich jetzt noch nicht ganz verstanden

Das mit dem Gateway in der Firewall Regel? Das hast du bei deinem Test doch angewandt, oder?

Das nennt sich Policy Routing. Die Pass-Regel funktioniert grundsätzlich wie andere, ist aber um das Gateway erweitert, wodurch sie Traffic, auf welchen sie zutrifft auf das Gateway routet.
Ob sie zutrifft, hängt von Interface, Richtung, IP Version, Protokoll, Quell-IP und -Port und Ziel-IP und -Port ab.
Treffen alle Bedingungen zu, wird das Paket auf das gesetzte Gateway geroutet.

ebenfalls denke ich happert es an meinen Regeln. Ich nehme da gern den ein oder anderen Tipp, was ich uebersehe.

Zu beachten ist hier die Reihenfolge der Regeln. Die Regeln werden am Interface von oben nach unten geprüft. Trifft eine zu, wird sie angewandt und weitere werden ignoriert.
Floating Regeln und Regeln auf Interface Gruppen haben Vorrang gegenüber Interface-Regeln, werden also zuerst geprüft.

Trifft also ein Pass-Regel vor der Policy Routing-Regel zu, kommt letztere nicht zur Anwendung.

109

German - Deutsch / Re: Firewall / Routing funktionieren nicht wie erwartet.

« on: November 03, 2024, 08:17:09 pm »

Daher ich versuche nochmals kurz zu erklären was ich möchte:
Ich will geblockten Datenverkehr loggen und sehen.
Aber nicht von Verbindungen die ich zugelassen habe (wie diese vermutlichen Verbindungs-Timeouts).

Ich kriege das leider nicht hin. 

Hast du nun den Haken bei Firewall: Settings: Advanced > Logging: Default block rausgenommen?
Ich würde erwarten, dass Verbindungs-Timeouts (state violations) damit nicht mehr geloggt werden.

Problem 2 konnte ich lösen, auch wenn ich es nicht verstehe wieso. Wenn ich diesem Smartphone eine andere IP gebe, dann funktioniert das Routing und FW wie gewohnt.
Habe nun die IP 192.168.30.132 anstelle von 192.168.30.133 gegeben.

Vielleicht ein IP Konflikt?
Wenn es nicht funktioniert, mal überprüfen, ob in der ARP Tabelle (Interfaces: Diagnostics: ARP Table) die korrekte MAC Adresse steht.

110

German - Deutsch / Re: Externe Domain zeigt intern DNS_PROBE_FINISHED_NXDOMAIN

« on: November 03, 2024, 09:33:17 am »

Okay, ein DNS Request fragt 10.10.25.1 ab, also Adguard. Und zurückgegeben wird irgendeine öffentliche Google IP. Ich nehme an, du hast die eigene Domain abgefragt.

Code: [Select]

Es wird die Google IP angezeigt, also ja das hatte ich erwartet.Warum hast du das erwartet?

Ich hätte erwartet, dass die HAproxy-IP zurückgegeben wird. Nur so kannst du die eigene Seite erreichen.

Wenn die Abfrage deine eigene Domain betrifft, sollte das DNS System die lokale IP zurückgeben.
In Unbound ist das mit einem Host Override zu erreichen, aber offenbar wird der gar nicht mit einbezogen.

Ich denke, du müsstest das in Adguard irgendwie einstellen können. Oder die Abfragefolge umdrehen, so dass Unbound erst abgefragt wird, und alles was es nicht selbst auflösen kann, an Adguard geht.
Ich habe allerdings mit Adguard keine Erfahrung und kann dir damit leider nicht weiterhelfen. Ich habe aber schon eine Menge Anleitungen und Diskussionen hier und im Netz dazu gesehen.

111

German - Deutsch / Re: Externe Domain zeigt intern DNS_PROBE_FINISHED_NXDOMAIN

« on: November 02, 2024, 06:05:44 pm »

Wenn ich im LAN server.name.com aufrufe, dann kommt:

Typ: HTTPS, Einfaches DNS
Verarbeitet
0.16 ms
10.10.25.21
Pixel-8-Pro.localdomain

Das selbe auch bei anderen Clients.


Trotzdem zeigt mir der Browser:
DNS_PROBE_FINISHED_NXDOMAIN

Vielleicht mal den Browser Cache leeren.

Ein nslookup oder ein dig verrät, welcher DNS Server antwortet.

Ausgabe nslookup (Windows) ergibt:
Server:  OPNsense
Address:  10.10.25.1

Nicht autorisierende Antwort:
Name:    google.de
Addresses:  2a00:1450:4005:80b::2003
          172.217.16.67

Ist das nun das erwartete Ergebnis?
Nachdem die die IPs im Plan unkenntlich gemacht hast, kann ich das nicht verifizieren.

112

German - Deutsch / Re: Ausgehende VPN Verbindungen fuer bestimmte Clients

« on: November 02, 2024, 12:58:49 pm »

Damit die Regel nur für Ziel-IP außerhalb deines Netzes angewandt wird, braucht es noch einen entsprechenden Alias als Ziel.

Ich habe mir hierfür einen RFC 1918 Alias angelegt, der alle privaten Netzwerkbereiche enthält. Diesen verwende ich dann in der Gateway-(policy Routing)-Regel mit "invert" angehakt. Die Regel trifft dann nur auf Ziel-IPs im öffentlichen Adressraum zu und tut damit das Gewünschte.

Wenn du auch ein lokales IPv6 hast, musst du das auch in den Alias inkludieren, oder einen eigenen mit eigener Regel anlegen.

113

German - Deutsch / Re: Externe Domain zeigt intern DNS_PROBE_FINISHED_NXDOMAIN

« on: November 02, 2024, 09:27:11 am »

Du musst die IP des HAproxy Virtual Servers (Frontend) im Host Override angeben, also wahrscheinlich die WAN IP der OPNsense.
Auf die öffentliche IP löst es auch ohne auf durch das öffentlich DNS.

114

24.7 Production Series / Re: OpenVPN, push specific GW IP

« on: November 01, 2024, 12:03:03 pm »

Did you set the topology in the server settings accordingly?

115

24.7 Production Series / Re: OpenVPN, push specific GW IP

« on: November 01, 2024, 11:16:58 am »

but when I set client speciffic override to address 10.11.220.129/30 client gets 10.11.220.1 as GW because VPN instance subnet is 10.11.220.0/22

The tunnel in the client specific override should be the subnet address. So you should enter 10.11.220.128/30 there.

116

German - Deutsch / Re: Externe Domain zeigt intern DNS_PROBE_FINISHED_NXDOMAIN

« on: November 01, 2024, 10:56:16 am »

Ich habe opensense mit AdGuard und HaProxy inklusive ACME installiert.
Zudem habe ich eine öffentlich IPv6 Adresse.

So nehme ich an, dass der Zugriff auf Nextcloud von außen über den HAproxy auf OPNsense erfolgt.
Dein Hostname wird auf die externe IP der Kabelbox aufgelöst und die leitet Anfragen dahin weiter.

D.h., dein lokales DNS müsste die IP des HAproxy Frontends zurückgeben.
Von deinem lokalen DNS Server hast du aber nichts erwähnt. Vielleicht betreibst du auch keinen. Aber ohne könnte das nur funktionieren, wenn die Kabelbox so etwas wie NAT Reflection machen würde. Ob die das kann, kann ich nicht sagen.

Am besten ist aber, ein lokales DNS zu nutzen wie Unbound auf OPNsense, und da ein Host Override für die eigenen öffentlichen Hostnamen einzurichten.
Unbound müsste dann so konfiguriert werden, dass er alle übrigen Anfragen an Adguard weiterleitet.

117

German - Deutsch / Re: NordVpn Opensense einzelne Clients

« on: October 31, 2024, 02:12:30 pm »

Mir fehlt da das Entscheidende: Die Policy Routing Regel
Vergessen?

Bitte den ganzen Regelsatz des Interfaces, LAN vermutlich, zeigen.

118

German - Deutsch / Re: Disk 100% - Nach Installation mit .iso auf Hyper-V VM 10GB feste HDD

« on: October 30, 2024, 11:12:15 pm »

Der Default für Swap sind 8 GB.

Unabhängig von der Diskgröße?
Das ist brutal!

Ich hatte 20 GB genommen. Aber die sind nicht mal zu 10% ausgelastet nach etwa einem halben Jahr.

119

German - Deutsch / Re: Firewall / Routing funktionieren nicht wie erwartet.

« on: October 30, 2024, 10:53:58 pm »

Hast du mir einen Tipp wie ich mit einer eigenen Regel "Block_All_to_All" alles blockierte loggen kann, aber solche "Timeouts" nicht?

Loggen kannst du das mit eine eigenen Block-alles Regel am Ende des Regelsets mit aktiviertem Logging.
Und das Logging der Default-Deny Regel kannst du ausschalten:
Firewall: Settings: Advanced > Logging: Default block

Und hast du allenfalls auch eine Idee zu meinem Phänomen 2 wo nicht zurück geroutet wird?

So wie du das darstellst, dass die Antwortpakets am VLAN20 Interface zurückkommen mit einer Ziel-IP im VLAN30, an diesem Interface aber nicht raus kommen, bin ich ratlos. Wenn die Smartphones gleichzeitig problemlos Internet-Zugriff haben, kann man eigentlich alle potentiellen Fehler ausschließen.

Antwortpakete werden aufgrund eines durch das initiale Paket gesetzten States durchgelassen.
Du kannst dir den State für die Verbindung ansehen: Firewall: Diagnostics: States
Da kannst du nach Ziel- od. Quel-IP filtern. Jede Verbindung verwendet einen bestimmten Port an den Interfaces, und für jede müsstest du 2 Einträge sehen, in und out.

Kannst du von einem anderen Interface darauf zugreifen?
Es wäre für mich logischer, wenn der HA gar nicht auf Anfragen von außerhalb des eigenen Subnetzes antwortet, weil er entweder keine oder eine falsche Gateway Einstellung hat oder es selbst mit seiner Firewall blockiert.

120

German - Deutsch / Re: Firewall / Routing funktionieren nicht wie erwartet.

« on: October 30, 2024, 09:40:42 pm »

Ich finde zu jedem dieser "unerwarteten" Block Einträge auch ein identischen Pass Eintrag der ca. 30-60 min vorher zugelassen wurde.
Also Quell und Ziel IP sowie Ports, siehe erneut Anhang. Das kann kein Zufall sein oder falsche Regelkonfiguration.

Vermutlich sind es lediglich Verbindungs-Timeouts.

Und vermutlich betrifft das auch immer dieselben Geräte mit denselben Zielen, wahrscheinlich IoT Geräte, die Verbindungen zu einem Server ewig halten wollen. Können sie auch, aber dafür müssten sie ab und zu ein Paket drüber schicken.

Wenn die Verbindung auf der Firewall geschlossen ist, muss das Gerät eben eine neue aufbauen, wenn es wieder das Bedürfnis überkommt, dem Server was mitzuteilen.

Ich finde zu jedem dieser "unerwarteten" Block Einträge auch ein identischen Pass Eintrag der ca. 30-60 min vorher zugelassen wurde.
Also Quell und Ziel IP sowie Ports, siehe erneut Anhang. Das kann kein Zufall sein oder falsche Regelkonfiguration.

Die haben das wahrscheinlich nicht geloggt.

Das Logging der Default Deny Regel kannst du auch auf OPNsense ausschalten, wenn du die Einträge nicht sehen möchtest.