Messages

Ohne jetzt den Source Code gesichtet zu haben, vermute ich das es von Wireguard ausgeht. Das Problem ist das unter "Interfaces" die Lock-Option ignoriert. Nach jedem Reload wird das WG-Interface neu angelegt. Unter Linux kann man die Route mit "OnLink" anlegen, damit eben genau das nicht passiert. Ein Pendant in OPNsense ist nicht auffindbar.

Ich habe auch versucht das Problem zu umschiffen, indem ich STATIC vom FRR-Package verwende. Dort passiert aber genau das gleiche. Sobald Reload von WG, müssen auch hier manuell die Routen wieder aktiv gesetzt werden.

WG-Peer-Adressen verwenden ist leider auch keine Option, da dies dazu führt das der BGP-Daemon sich nach Reload nicht mehr aktiv verbindet zum Neighbor. Nur ein Reload des Daemons, behebt dieses Verhalten. Beide Wege haben so ihre Nachteile, keine davon funktioniert zuverlässig.

Irgendwie müsste das von OPNsense irgendwie berücksichtigt werden. Vielleicht mit einer ONLINK-Option bei den Gateways.

Ich verwende WG mit der Option "no routes" und verwende dann dynamisches Routing mit BGP. Als Neighbor-Peer-Adressen verwende ich Adressen die auf dem Loopback-Interface liegen. Damit die Gegenstelle weiß, wohin es die Pakete für den Neighbor schicken muss, wird dafür auf das WG-Interface eine Route gelegt.

Gibt es noch einen anderen Weg? Bin für Verbesserungsvorschläge offen.

Hallo,

wie der Titel schon sagt: Wenn ich in der OPNsense 24.7.12 unter "VPN > Wireguard > Peers" zum Beispiel einen Peer hinzufüge und danach "Apply" betätige, schmeißt er mir vorher angelegte statische Routen unter "System > Routes > Configuration" raus. Das passiert aber nur bei Routen die auch mit dem Wireguard-Interface korrespondieren. Wenn das passiert muss ich manuell in jenem Menü für die Routen diese nochmal aktivieren.

Das WG-Interface hat allerdings die Lock-Option gesetzt, wovon ich mir erhofft habe, das genau dieses Phänomen nicht passiert. Das Routen wegfliegen, wenn das zugrundeliegende Interface weg ist, ist ok. Aber nicht wenn ich sage das Interface bestehen bleiben soll.

OPNsense Maschine ist eine VM mit vtnet Interfaces. Falls das eine Rolle spielt.

Hat dafür jemand eine Lösung?

Grüße

Hallo,

ich beobachte auf einem unserer Systeme ein komisches Verhalten. Nach einen längeren Stromausfall und anschließenden mehrfachen Neustart hat Unbound einfach den Betrieb eingestellt. Egal was für Einstellungen gesetzt werden, ich bekomme nur TimeOuts. Ich habe die Einstellungen mit anderen Setups verglichen, erkenne da keinen Unterschied.

OPNsense 23.7.3

Es handelt sich um ein HA-Cluster. Auf beiden funktioniert es nicht. Erst dachte ich das jemand eine Einstellung nicht persistent gesetzt hat, aber selbst wenn ich alle Einstellungen so setze wie auf funktionierenden Systemen funktioniert Unbound nicht. Leider geben die Logs trotz erhöhten Log Level keine Fehler, sondern nur den Hinweis auf einen TimeOut. Es scheint mir fast so als würde er die Einstellungen unter System > Settings > General ignorieren. Habe dort schon was anderes eingetragen. Keine Chance.

Unter Reporting > Settings habe ich ebenfalls die DNS Daten resettet. Weder Namensauflösung auf der OPNsense selbst oder von irgendeinem Host im Netz funktionieren. Einstellungen sind Standard. Kein DNSSEC keine sonstigen Spielereien. Access List ist auf Default Action Allow.

Jemand eine Idee?

Gruß

[0.0.0.0/0]

Hallo,

vielleicht kann mir hier jemand auf die Sprünge helfen. Folgendes Szenario: Ich habe eine APU6B4 mit installierten OPNsense 23.1.5_4. Diese soll über zwei Tunnel mit zwei verschiedenen Endpunkten kommunizieren und ist dabei Initiator. Auf der anderen Seite stehen zwei Debian 11 Kisten mit Wireguard installiert und bereits eingerichteten anderweitigen Tunneln, die einwandfrei funktionieren.

Ich verwende dynamisches Routing und habe bei beiden Endpunkten 0.0.0.0/0 bei allowed IPs eingetragen und unter Local beide Instanzen mit Haken "Disable Routes" gesetzt.

Der erste Tunnel war kein Problem und läuft wie erwartet:

wg1
Tunnel Address 192.168.100.111/24
Endpoint Port 55555

Der zweite Tunnel bekommt keinen Handshake:

wg2
Tunnel Address 192.168.101.111/24
Endpoint Port 50011

Interessant ist das ich im Packet Capture auch absolut Null Traffic zum zweiten Endpoint sehe. Allerdings wenn ich die Tunnel Address auf "192.168.101.111" setze, ohne Angabe der Maske im CIDR-Format, dann macht die OPNsense daraus eine /8er Maske und der Handshake kommt zustande und ich sehe Traffic auf dem WAN-Interface.

Gibt es für dieses Verhalten eine Erklärung?

Grüße