Messages

Und du hast der IPSec instance ein Interface zugewiesen?
Das wäre Voraussetzung, dass das jeweilige Gateway und damit die statische Route nicht benutzt wird.

Ja, hatte ich

Am IPSec Gateway müsste auch "upstream" aktiviert sein.

Habe ich auch versucht, leider ist die statisch Route 0.0.0.0/0 trotzdem aktiv, obwohl der Tunnel nicht up ist.

Und du hast der IPSec instance ein Interface zugewiesen?
Das wäre Voraussetzung, dass das jeweilige Gateway und damit die statische Route nicht benutzt wird.

Ja habe ich

Du könntest es auch der Gateway Priorisierung versuchen. Dem IPSec Gateway eine 1 geben und den WAN Gateways höhere je nach Wunsch. Und natürlich die statische Route entfernen.
Am IPSec Gateway müsste auch "upstream" aktiviert sein.

Das scheint für mich die Lösung zu sein. Das Upgstream IPSec GW ist nicht up, deshalb greift das zweitbeste Gateway und der Tunnel wird aufgebaut, dann greift die default Route auf das IPSec Gateway, der IPSec bleibt aber glücklicherweise up.

Aber ja, ich wäre das auch schon bei Patrick und würde das ganze auf Policy-based IPSec (Tunnel Mode) umstellen.
Eine Policy Routing Regel sollte es aber meine Meinung nach nicht brauchen. Wäre auch gar nicht möglich, weil der poliy-based Modus keine Gateway IP bereitstellt.
Das routet dann ohnehin schon der Kernel, wenn als Remote Netzwerk 0.0.0.0/0 gesetzt ist. Und zwar sicher erst, nachdem die Verbindung hergestellt wurde.

OK vielen Dank an Euch beide, das schaue ich mir auch noch mal an.
Wobei ich kein Freund von Policy Based Routing bin. ( Komme vom Provider und wir lieben Routen :-) )

.

Das mit der einzig möglichen Default Route habe ich schon verstanden. Was ich nicht verstehe, sind die statischen Routen. Die führen zu deinem Problem. Ich habe das schon mehrfach zu erklären versucht.

Wenn ich die more specific statischen Routen nicht setze, kann er den Tunnel nicht aufbauen, da die statische 0.0.0.0/0er Route schon up ist, obwohl der Tunnel nicht steht ( Du hast ja auch mal geschrieben, statisch ist statisch ( Was ich mit Router Verständnis nicht nachvollziehen kann )
Jetzt kommt etwas neues: setze ich neur eine 10.0.0.0/8 in den Tunnel, kann er den Tunnel aufbauen, da ja dann die Default Route ins Internet zeigt.
Jetzt habe ich einfach mal die Route 0.0.0.0/0 in den Tunnel gesetzt. Der Tunnel bleibt bestehen und es wird alles in den Tunnel geroutet.
Reboote ich die OPNsense kann er den IPSec nicht mehr aufbauen, da die 0.0.0.0/0 in den Tunnel zeigt.

Wenn du dir die Konfiguration der beiden Gateways ansiehst, ist da "Upstream Gateway" angehakt?

WAN3_GW (active)   WAN3   IPv4   20 (upstream)   10.102.4.1   8.8.4.4   10.8 ms   6.7 ms   0.0 %   
WAN2_GW                  WAN2   IPv4   30 (upstream)   10.102.3.1   1.0.0.1   12.1 ms   2.2 ms   0.0 %   

Und wenn du in die WAN Interface-Konfiguration gehst, ist da das jeweilige Gateway als Upstream Gateway ausgewählt?

Du  meinst "IPv4 gateway rules" < ja, ist es

Und "Gateway switching" ist nun auch aktiviert?

Gateway switching    Allow default gateway switching < Ja, war es auch schon vorher

Da ich ja alles in den Tunnel routen möchte, muß ich eine Default-Route auf den Tunnel setzten.

Aber was spricht dagegen, dass die beiden anderen Gateways auch als upstream Gateway festgelegt werden?
Wenn gewünscht oder nötig, kannst du für jedes auch eine Priorität definieren, um festzulegen, welches bevorzugt wird und in welcher Reihenfolge.
Dann werden die Gateways entsprechend dessen und ihrer Verfügbarkeit automatisch verwendet (dynamisch).

Eine statische Route ist aber, wie der Name andeutet, statisch. Diese besteht auch, wenn das Gateway nicht erreichbar ist.

Na die beiden Uplink sind in der Konfiguration als Gateway markiert, aber eine Default Route 0.0.0.0/0 kann ich dort ja nicht setzten, weil die ja in den Tunnel gehen soll. Und mehrere aktive Default Routen kann es nicht geben.
Eine statische Route sollte so lange aktiv sein, wie das Gateway auf das sie zeigt aktiv ist. (So eine art Tracking)
Und wenn man mehrere gleiche statische Routen einträgt, sollte doch die aktiv sein, die auf das Uplink-GW mit der geringsten Metrik (also das aktive GW) zeigt.
Ich frage mich, warum ich der einzige bin, der das Problem hat. Hat kein anderer zwei Uplinks und möchte Routen schwenken, wenn ein Monitoring eines Uplink auslöst und der Uplink als offline markiert wird.

Hi Viragomann,
vielleicht fehlt mir da etwas.
Da ich ja alles in den Tunnel routen möchte, muß ich eine Default-Route auf den Tunnel setzten. Somit routet die OPNsense allen Traffic (für den sie keinen besseren Weg kennt) in den Tunnel.
Mit den more specific static Routes will ich die "Default-Route" übersteuern, damit die OPNsense den IP-Sec Hub erreichen kann.
( Mein IPSec Tunnel ist Route-Based )
Und vom Routing Verständnis her müssen meine Lösung auch gehen, die OPNsense händelt meine statischen Routen nur leider nicht so, wie es ein Router macht :-)

Soweit ich das Verstanden habe, geht es da ja um die Remote-Gateway für die IPSec, nicht um die Default-Route, die IPSec beim Verbinden einrichtet.

Ja, ich setzte die statischen Routen um das Remote-GW (Hub-Standort)  über beide Uplinks erreichen zu können. Und die Route soll halt immer über den gerade aktiven Uplink aktiviert sein.
Die default-Route 0.0.0.0/0 ist in den IPSec gesetzt, da halt der ganze Traffic der Lokation in den Tunnel gehen soll.

ja, aber dann müßte ich ja die Routen über OSPF announcen und bräuchte noch ein weiteres Systemen.

Ich glaube ja einfach nur, das ich irgendwo ein Haken vergessen habe, oder das es einfach ein Bug ist, das die statische Route nicht verschwindet, wenn das entsprechende GW down ist. ( Ist ja auch schon komisch, das die Metriken vom GW nicht auf die statischen Routen übertragen werden )

Moin und Danke für die Rückmeldung,
Danke für den Tip, das hatte ich tatsächlich auch schon gesehen und aktiviert, aber hat leider nichts geändert.
Unter System > Gateways > Configuration > zeigt die OPNsenses den Status des entsprechenden GW auch als Offline an.
Die statische Route die ich auf das Gateway konfiguriert habe, verschwindet aber nicht.
( Als weiteres Phänomen sehe ich, das wenn man zwei gleiche statischen Routen auf unterschiedliche GW anlegt, nicht die Metrik des GW als Routingentscheidung genommen wird, sondern die Reihenfolge der statischen Routen. Die letzte konfigurierte Route ist die aktive )
Fragt man die Routen über die CLI netstat -rn ab, ist auch das U Flag für Up vorhanden

meine OPNsense hat zwei Gateways mit jeweils einem aktivierten Monitoring.

Zusätzlich zum Default Gateway, also nicht auf dem WAN?

Nein, ich meine die Default Gateway, also die beiden WAN-Interface

Jetzt habe ich zwei gleiche statische Routen auf die jeweiligen GW gesetzt.

Was genau ist der Sinn?
Sollen LAN-Geräte für bestimmte Ziel-IPs auf die Gateway geroutet werden? Wenn das eine nicht verfügbar ist, über das andere?

Ja, so ist es. Genau gesagt, baue ich über eine LoO einen IP-Sec zu einer Gegenstelle mit einer festen IP-Adresse auf und wenn der eine WAN down ist, soll der IPSec automatisch über das andere WAN gehen.
( Es soll halt aller Traffic in den IPSec Tunnel gehen und daher habe ich die Default Route in den IP-Sec gesetzt und den IPSec Hup möchte ich über die beiden gleichen statischen Routen erreichbar machen )

Hallo,
meine OPNsense hat zwei Gateways mit jeweils einem aktivierten Monitoring.
Jetzt habe ich zwei gleiche statische Routen auf die jeweiligen GW gesetzt.
Fällt ein GW aus, zeigt die OPNsense den Status des GW auch als Down an, die entsprechende statische Route bleibt aber aktiv und somit kann die zweite gleiche Route nicht aktiv werden.
Hat einer eine Erklärung dafür?

Hi trixter,

hast du das mit den zwei statischen Routen mal ausprobiert?
Ich wollte es mir einfach machen und wollte es nutzen, leider schwenken die Routen nicht. Auch wenn ich das Main-Gateway auf down schalte, wird die zweite Route nicht aktiv.
Laut des Hilfe-Buttons
"Choose a value between 1 and 255. Influences sort order when selecting a (default) gateway, lower means more important."
Gewinnt die kleinere Priorität. Aber egal wie ich es anstelle, die statischen Routen schwenken nicht.
Getestet mit Version 24.7.2