Opnsense Wireguard (Routing) Probleme

[Porfavorio]

Es ist aber definitiv so, dass es mal geht und mal nicht. Gerade geht es wieder. Das kann doch nicht an einer grundlegend falschen Konfiguration liegen?

 

[Bob.Dig]

Möglich ist alles.

 

[TheCadillacMan]

Kann es sein, dass die Wireguard-Firewallregeln auch auf 10.210.0.1/32 und 10.210.0.2/32 lauten müssen (derzeit: 10.210.0.0/32)?

10.210.0.0/32 bringt gar nichts, weil das kein Host ist. Entweder die einzelnen Hosts .1 bzw. .2 freigeben oder das ganze Netz mit 10.210.0.0/24.

 

[Porfavorio]

So, habe mal testweise an Standort B die Firewall der opnsense ganz kurz komplett deaktiviert. Das führte zum Erfolg. Wir können es also wohl auf ein Firewall-Problem eingrenzen. Ich hatte die Regeln, die ich gesetzt habe, ja eingangs beschrieben. Was sollte ich mir hier noch einmal genauer anschauen?

 

[Porfavorio]

Nachdem ich nun auf der opnsense an Standort B das Wireguard Interface zugewiesen habe (wie in der Anleitung empfohlen, aber nicht vorausgesetzt), scheint es problemlos zu funktionieren.

Beschreibung dazu:

First, it generates an alias for the tunnel subnet(s) that can be used in firewall rules. Otherwise you will need to define your own alias or at least manually specify the subnet(s)

Second, it automatically adds an IPv4 outbound NAT rule, which will allow the tunnel to access IPv4 IPs outside of the local network (if that is desired), without needing to manually add a rule

Finally, it allows separation of the firewall rules of each WireGuard instance (each wgX device). Otherwise they all need to be configured on the default WireGuard group that OPNsense creates. This is more an organisational aesthetic, rather than an issue of substance

Kann mir jemand sagen, ob hier nun sicherheitstechnisch etwas Relevantes/Problematisches passiert ist? Nach meinem Verständnis ist hier nichts nach innen geöffnet worden. Eine neue Regel konnte ich allerdings generell nicht entdecken. Wo soll diese angelegt worden / ersichtlich sein?

 

[Bob.Dig]

10.210.0.0/32 bringt gar nichts, weil das kein Host ist.

Ich sach mal vorsichtig, da nicht vom Fach, das kann man schon machen, gerade bei VPNs...

 

[gaym0r]

Ich sach mal vorsichtig, da nicht vom Fach, das kann man schon machen, gerade bei VPNs...

Korrekt, /31-Netze (ist ja hier der Fall) werden gerne für Router-Verbindungen genutzt, auch wenn es bei einem solchen Netz strenggenommen keine Host-IPs gibt. Ist auch hier beschrieben: https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing

 

[b1nb4sh]

@gaym0r
Im Grunde war es ein Vorschlag und wurde von Cisco umgesetzt. Dennoch würde ich, soweit es geht, dennoch auf einer /30 Maske für p2p Links bleiben. In der Technik hat man schon sehr vieles für andere Zwecke missbrauchert

 

[TheCadillacMan]

Ich sach mal vorsichtig, da nicht vom Fach, das kann man schon machen, gerade bei VPNs...

Natürlich kann man das als Firewall-Regel machen, bringt hier aber eben nichts, weil es hier keinen Host mit der IP 10.210.0.0 gibt. /32 ist immer genau eine IP, die entweder existiert oder nicht.

Korrekt, /31-Netze (ist ja hier der Fall) werden gerne für Router-Verbindungen genutzt,

Es ist aber /32 und kein /31.

 

[Bob.Dig]

, weil es hier keinen Host mit der IP 10.210.0.0 gibt.

Genau davon würde ich nicht unbedingt ausgehen.
Edit: Ok, wahrscheinlich wurde ein Tutorial falsch abgeschrieben. 😉

 

[Porfavorio]

Die "Diskussion" ist jetzt müßig. Ich habe die IPs klar benannt und damit gibt es diese nicht als Host.

 

[0-8-15 User]

Ich war wohl fälschlich davon ausgegangen, dass die Grundinstallation von opnsense erst einmal alles von außerhalb blockt, sofern ich es nicht explizit öffne.

Wie greifst du auf das Webinterface zu, wenn von außerhalb alles blockiert ist (Stichwort: anti-lockout)?

 

[Porfavorio]

Wie greifst du auf das Webinterface zu, wenn von außerhalb alles blockiert ist (Stichwort: anti-lockout)?

Ich befinde mich einerseits innerhalb desselben LANs, andererseits geht das per VLAN und VNC.