Messages

Hallo an die Runde,

seit Update auf die Firmware 25.3.1 wird mir beim os-speedtest-community Plugin "falsch konfiguriert" angezeigt (Plugin Version 0.9_6). Das Plugin funktioniert jedoch meiner Meinung nach einwandfrei.

Eine Neu-Installation brachte keine Änderung. Das Problem hat sich mit 25.3.4 nicht geändert. Auf einer zweiten, ident konfigurierten Opnsense tritt die gleiche Fehlermeldung auf.

Hat noch jemand das Problem identifiziert?

Grüße
neuling10



 

Die ersten beiden Segmente sind ident mit 192.168

Da die Router werksseitig mit 192.168.1.1 bzw. mit 192.168.0.1 erreichbar sind, kann ich diese nicht ändern auf z.B. 192.168.0.0/24 und 172.16.0.0/24, wie in der WireGuard Site-to-Site Setup Doku zu lesen
https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html

Hallo an die Runde,

zuerst zu meinem Setup:
Wireguard Site to Site Verbindung zwischen 2 Opnsense Firewalls. Beide Opnsese sind mit je einem Router im Bridge Mode verbunden, die eine dynamische, öffentliche IP vom ISP erhalten. Die Wireguard Verbindung ist aufgrund der dynamischen öffentlichen IPs mit DynDNS Domains aufgebaut. Das Setup funktioniert, ich kann von Site A auf das LAN von Site B zugreifen und umgekehrt.
LAN IP Range Site A: 10.100.1.1/16. Die Admin-Seite des Routers ist werksseitig über 192.168.1.1 erreichbar
LAN IP Range Site B: 100.200.1.1/16. Die Admin-Seite des Routers ist werksseitig über 192.168.0.1 erreichbar

Ziel: Ich würde gerne von Site A zusätzlich zum LAN-Netzwerk Site B auch auf die Admin Site des Routers auf Site B zugreifen und vice versa.

Ich habe in den Wireguard Peer Einstellungen bei den zugelassenen IPs die Router IP der jeweiligen Gegenseite ergänzt (192.168.1.1/32 bzw. 192.168.0.1/32) und im Wireguard Interface die FW Rule Site A mit
allow   IPv4*   10.100.1.1/16   *   192.168.0.1/32   *   *   *
und Site B mit
allow   IPv4*   10.200.1.1/16   *   192.168.1.1/32   *   *   *
ergänzt.

Leider erreiche ich die Router-Oberfläche auf der jeweiligen Gegenseite nicht. Über eine Wireguard iOS Verbindung zu Site A am Smartphone erreiche ich den Router der Site A jedoch problemlos.

Meine Überlegungen:
- Ist es möglich, dass über eine Wireguard Site to Site VPN Verbindung nur eine interner IP Range geteilt werden kann? Also nicht 10.100.1.1/16 und zusätzlich auch noch 192.168.1.1/32? Bräuchte ich somit eine zusätzliche separate Site to Site Verbindung?
- Funktioniert das Setup möglicherweise nicht, weil 2 idente private Netzwerke (192.168.1.1/24) auf beiden Seiten vorhanden sind?
- Oder liegt es einfach an einem Konfigurationsfehler meinerseits?

Danke Euch für Eure Tipps!

Grüße
neuling10

Vielen Dank für Eure Inputs, das hilft mir schon mal weiter. Vor allem dass ich mir keine Sicherheitslücke mit dem beschriebenen Vorgehen aufmache, ist schon mal eine sehr relevante Info für mich :-)

Euer Vorschlag, direkt auf der Opnsense eine CA zu nutzen mit einem Wildcard-Zertifikat, klingt für meinen Anwendungsfall völlig ausreichend. Kann man dieses Zertifikat dann direkt auf der Opnsense den Geräte-Adressen zuordnen (mit Unbound Override und Nginx Server) oder muss ich dann doch auf allen internen Geräten das Zertifikat manuell installieren? Das würde ich mir gerne ersparen und nehme dafür etwas mehr Konfigurationsaufwand auf der Opnsense in Kauf.

Für alle internen Geräte auf dem Caddy Reverse-Proxy anlegen, und den über die externe IP-Adresse mit HTTP-Challenge Letsencrypt spielen lassen. Dazu muss man natürlich alle Geräte, die darüber bedient werden, ins öffentliche DNS eintragen, notfalls mit CNAMEs die auf einen DynDNS-A-Record zeigen.
Aber man kann dann im Caddy-Plugin den Zugriff per HTTP(S) auf die internen Netze einschränken. Somit hat man zwar global sichtbare Namen aber den Zugriff trotzdem nur von innen.

Wäre es dann so, dass zwingend eine Internet-Verbindung bestehen muss, wenn ich über die DNS-Adresse (z.B. raspberry.myhome.net) auf die internen Geräte aus dem internen Netz zugreifen möchte?
Wäre es dann nicht einfacher mit der DNS Challenge das Wildcard Zertifikat anzulegen und dann dieses mittels Nginx an die internen Host-Adressen zuzuweisen? Somit würde man sich ja das öffentliche Eintragen der Geräte beim DNS Provider ersparen? Ganz nach dem Gedanken, nur so wenig wie möglich öffentlich beim DNS Provider Preis zu geben...

Grüße
neuling10

Hallo an die Runde,

ich habe mich die letzten Tage intensiv mit dem Thema LetsEncrypt Zertifikate für interne Hosts auseinandergesetzt.

Mein Ziel ist es, die nervenden "Ihre Verbindung ist nicht sicher"-Meldungen durch ein LetsEncrypt Wildcard Zertifikat für diverse interne Hosts (Synology NAS, Openhab Smart Home, Grafana Dashboards etc.) zu eliminieren. Mir geht es rein um interne Hosts, ich möchte keinen externen Zugriff ermöglichen und habe hierfür aktuell auch keinen Anwendungsfall. Für den Zugriff auf meine Hosts von Außerhalb nutze ich ausschließlich Wireguard VPN (Site to Site oder am Smartphone).

Mein Plan wäre es nun, mir mittels ACME Plugin ein Wildcard LetsEncrypt Zertifikat zu generieren über eine DNS Challenge eines DNS Providers. Nur für die Opnsense würde ich einen A-Record beim DNS Anbieter anlegen (in meinem Fall z.B. bei IPv64). Den TCP Port der Opnsense Weboberfläche würde ich von 443 auf einen anderen Port ändern.
Mittels Nginx Plugin würde ich das Zertifikat den internen Hosts zur Verfügung stellen. Für diese Host Domains würde ich anstatt DNS A-Records beim DNS Provider den Unbound Dienst mit DNS Host Overrides nutzen und dies im Nginx HTTP-Server erfassen. 

Soweit zum Plan. Nun stellen sich mir als Laie jedoch noch ein paar Fragen in Bezug auf die Sicherheit meines Vorhabens:
1. Wenn ich es richtig verstanden habe, wird für die DNS Challenge durch das ACME Plugin die Opnsense von extern zugreifbar. Könnte das nicht ein durchaus kritisches Einfallstor in Bezug auf die Sicherheit sein (Zugriff auf die Opnsense GUI), z.B. falls der DynDNS Provider gehackt wird?
2. Könnte nun jemand, der meine externe IP und die internen Host Domains kennt, von außen auf die Weboberfläche der Hosts zugreifen?

Ich hoffe ihr könnt mir ein paar Ratschläge zu meinem Vorhaben geben. Immerhin möchte ich durch den Komfort-Gewinn nicht eine unnötige Sicherheitslücke aufmachen, dann lasse ich das lieber doch bleiben...

Grüße
neuling10

Hi,

I have found the solution. I had to add the following FW-rule:
TCP/UDP from source Wireguard transfernet on site B to target InfluxDB host on site A

Hallo, dankeschön, die gute Nachricht: Daten kommen an, Ziel erreicht :-)

Ein Neustart der Opnsense und des Telegraf Plugins brachte die Datenübertragung zum Laufen.

Nachdem ich Schritt für Schritt die Firewall wieder "dicht" gemacht habe, blieb genau eine notwendige Regel am Wireguard Interface auf Site A übrig:
TCP/UDP von Source Wireguard Transfernetz auf Site B auf Target InfluxDB Host auf Site A

Zwecks "Lernen und Verstehen" doch noch eine Frage:
Ganz verstehe ich die Sache noch nicht. Die zweite Regel am Wireguard Interface ist laut Opnsense Site to Site Anleitung die Allow lokales Netz Site B (192.178.1.1/16) auf lokales Netz Site A (192.168.1.1/16). In dieser Regel ist ja ohnehin auch schon die Opnsense auf Site B mit 192.178.1.1 enthalten. Warum ist dann zusätzlich auch noch die Allow Regel für das Transfernetz Site B auf den InfluxDB Host Site A notwendig? Alles andere läuft ja auch ohne dieser Regel problemlos über VPN und das Site to Site Transfernetz (Host zu Host oder Host zu Opnsense GUI)

Hallo Patrick, danke für die Hinweise, hab das alles nochmals gecheckt mit der Anleitung zu Wireguard Site To Site.
In den Peer Einstellungen unter Allowed IPs hatte ich auch das Transfernetz und das lokale Netz enthalten. Site To Site Wireguard läuft grundsätzlich auch schon seit einigen Monaten problemlos. In den LAN FW Rules habe ich zusätzlich nun auch das Wireguard Transfernetz freigegeben.

Ratlos macht mich der nach wie vor leider immer noch nicht funktionierende Telegraf Plugin Datentransfer :/

Hallo viragomann,

vielen Dank für die Hinweise :). Ich hab das nun nochmal alles gecheckt:

- Der Host mit der InfluxDB (Raspberry) ist von der Gegenseite erreichbar
- Laut Firewall Protokolldateien - Liveansicht wird kein interner Traffic geblockt, den Host (Raspberry) betreffend
- Am Wireguard Interface habe ich als Quelle und Ziel das jeweils gesamte Netz der anderen Site als FW-Rule freigegeben mit IPv4 Any und 192.168.178.1/16 bzw. 192.178.178.1/16
- Der Raspberry Host kann grundsätzlich Daten von der entfernten Site empfangen (getestet mit einem weiteren Container am Raspi, der von einem anderen Host im entfernten Netz Daten empfängt)

Ich habe in der Zwischenzeit ein altes, unbeantwortetes Posting gefunden, bei dem mit IPSec ähnliches versucht wurde (https://forum.opnsense.org/index.php?topic=28039.0. Hier ist die Rede, das Telegraf Plugin würde die WAN-IP als Sourceadresse nehmen und nicht die LAN-IP. Leider fehlen mir jedoch die Ideen, wie man einerseits überprüfen kann, ob das tatsächlich so ist bzw. ob es für dieses Problem eine Lösung geben könnte...



 

Hello everyone,

I have a Wireguard VPN site to site tunnel between 2 Opnsense firewalls. In the network on Site A is a host with an InfluxDB.

The Opnsense on Site A sends data into the InfluxDB using the Telegraf plugin. Unfortunately, the Opnsense on Site B cannot reach the InfluxDB, although the FW rule between Opnsense on Site B and InfluxDB on Site A is set to Allow any. As a layman, I have no idea why this is failing or what I could try to establish communication. Perhaps something needs to be set in the routing tables? Or in the Wireguard peer settings?

I am grateful for any tips :-)

Regards
neuling10

Hallo an die Runde,

ich habe einen Wireguard VPN Site to Site Tunnel zwischen 2 Opnsense Firewalls. Im Netzwerk auf Site A sitzt ein Host mit einer InfluxDB.

Die Opnsense auf Site A schaufelt Daten mittels Telegraf Plugin in de InfluxDB. Die Opnsense auf Site B erreicht die InfluxDB leider nicht, obwohl die FW Rule zwischen Opnsense und InfluxDB auf Allow any steht. Als Laie fehlen mir die Ideen, warum dies scheitert oder was man versuchen könnte, um die Kommunikation herzustellen. Muss vielleicht was in den Routing Tabellen eingestellt werden?

Bin für jeden Tipp dankbar :-)

Grüße
neuling10

Die Listen interfaces des Admin Web Interfaces jedoch nur auf das lokale LAN Interface legen.

Warum?

Ich hatte in div. Videos vernommen, die Weboberfläche nur aufs lokale LAN Interface zu legen, um nicht von außerhalb zugreifen zu können.
Wenn ich es allerdings richtig verstehe, könnte ich von außerhalb meines lokalen Netzes ohnehin nicht zugreifen, es sei denn ich hätte eine NAT Portweiterleitung auf den Adguard Port eingerichtet... 

Hallo an die Runde,

um DNS freizugeben, nutze ich die eingehende Regel
IPv4 TCP/UDP   Server    *   Diese Firewall   53 (DNS)   *   *      LAN_TO_Firewall_DNS

Die DNS Freigabe klappt nur mit obiger Regel. Setze ich bei Ziel statt "Diese Firewall" die IP der Opnsense ein (10.10.1.1), klappt die DNS Freigabe nicht mehr.
Ich nutze Adguard und Unbound DNS auf Port 53053.

Eine Verständnisfrage zu den Firewall Regeln:
=> Ist die DNS Freigabe auf "Diese Firewall" ein potentielles Sicherheitsrisiko? Ich habe gelesen, der Eintrag "Diese Firewall" würde alle privaten Adressen der Sense umfassen?  ???

=> Falls meine DNS Regel Optimierungsbedarf hat, wäre interessant wie diese aussehen müsste? Target 10.10.1.1 mit Port 53 oder Port 53053 (Unbound) habe ich bereits getestet, damit bekommen die Hosts allerdings keine Internetverbindung.

Grüße
neuling10

[Aufbau:]

Hallo an die Runde,

folgender Aufbau:
ich habe 2 Opensense Boxen via IPSec Site 2 Site verbunden, das ganze läuft problemlos.

Auf Site A ist eine Gateway Gruppe aktiv zwecks Failover (falls Kabelverbindung ausfällt, wird Verbindung über LTE Modem hergestellt). Das WAN Failover funktioniert problemlos.
Auf Site B gibt es kein Failover.
Da ich auf beiden Sites statische, öffentliche IP Adressen habe, erhält Phase 1 des Tunnels mittels DynDNS Service stets die aktuelle und aktive IP von Site A sowie die aktuelle IP von Site B. Auch das funktioniert wie es soll.
Auf Site A habe ich zwei Phase 1 Einträge; für jedes Interface einen (WAN Kabel und WAN LTE). Die WAN Gruppe ist ja leider nicht wählbar.
Auf Site B habe ich nur einen Phase 1 Eintrag.

Ziel:
Schaltet auf Site A die WAN Verbindung aufs LTE Modem um, soll der IPSec Tunnel über das LTE Gateway laufen. Sobald wieder eine Verbindung zum Haupt-Gateway (Kabel) aufgebaut ist, soll der VPN Tunnel wieder automatisch auf das Kabel Gateway wechseln.


Problem:
Natürlich habe ich bereits einiges an Recherche- und Testfällen hinter mir (Dead Peer Detection, "MOBIKE "deaktivieren" aktiviert, Keyingtries auf -1). Was ich auch einstelle, nach dem Gateway Wechsel wird die VPN Verbindung nicht mehr aktiv. Erst nachdem ich auf beiden Sites den IPSec VPN Dienst neu gestartet habe, verbindet sich der Tunnel wieder.

Hat jemand von euch einen ähnlichen Aufbau und eine funktionierende Konfiguration?

Grüße
neuling10

Hi,

ich hatte zu Testzwecken sowas ähnliches laufen. Versuchs mal mit einer eingehenden Rule am Wireguard  Interface (nicht die Gruppe) mit:

IPv4 *   IP_WireguardClient   *   DieseFirewall    *   *   *      ALLOW_WGClient_TO_Firewall

Grüße
neuling10