Messages

Dann ist das ein falsches Design und die OPNsense sollte mit einer Forti ersetzt werden. Ansonsten hast du immer ne Sonderlocke in einem standardisierten Design.

@mimugmail - Ja, eine "Sonderlocke" wird der Einsatz der OpnSenses sein. Dieses ist uns aber vorgegeben, leider. Allerdings ist aber OSPF ein standardisiertes Protokoll, auch das jeder Router eine ID im Sinne einer IP für die Kommunikation benötigt. Dies bildet, wie erwähnt das Tuninterface auf der Fortinetseite, wo ich mich auf der OpnSense nicht im Stande sehe, dies mit Bindung zum physischen Interface zu erzeugen.

Gegenwärtig arbeiten wir an einem Szenario was statische Routen zur OpnSense überträgt und diese via Filter im OSPF an andere Router propagiert. Im Ansible zieht das zumindest auf der Fortinetseite eine Erweiterung der Playbooks für das Routing nach sich. Ob und inwieweit OpnSense die Konfiguration via Ansible zulässt und ob die entsprechende Module existieren, entzieht sich meiner Kenntnis.
Genau hier gebe ich dir Recht, dass das Gesamtkonzept beginnt wackelig zu werden.

Best Grüße
AnPa

Guten Morgen,

OSPF is highly not recommended for WAN connections due to the convergence design. Please use BGP.
If one fortinet starts flapping for 5 min all your network will be down.

@lilsense: Kannst du bitte die vollständige Quelle zu diesem Textfragment posten? Aus meiner Sicht kommt das Problem jedoch nur dann zum tragen, wenn eine Fortinet auf L1/2a via DSL o.ä. angebunden ist. Dies ist jedoch kein Problem, wenn standortübergreifende, multiredundante Standleitungen mit Active-Active Fortinetclustern verbunden sind. Generell gilt dann IPSec als Verbindungsschicht und OSPF als Routinginstanz, die über Metrikpriorisierungen pro externem Anschluss, Metriktypen und ggf. Filtern, sozusagen granuliert wird.

BGP ist derzeit keine Option, weil derzeit, über mehrere Standorte verteilt, alle Fortinetcluster über Ansible administriert sind und demzufolge die L3 Struktur (IPSec) übergreifend die Grundlage für OSPF ist. Dies wird ebenfalls via Ansible konfiguriert bzw. optimiert und läuft reibungslos. Der Fall der nun aktuell ist, ist die Fremdanbindung der OpnSense an einen der Fortinetcluster. Die momentan eine OpnSense soll im nächsten Schritt ebenfalls redundant werden. OSPF seitig wird die Priorität der Leitungswahl dann zwar über die Metriken gesteuert, doch spricht bisher nichts dagegen davon abzuweichen.
Dafür brauche ich aber auf der OpnSense ein (n) Tuninterface(s), welche auf IPSec basierend, das OSPF-Netz zum Routenaustausch ergibt. Und das bekomme ich auf der OpnSense nicht erstellt. Auf der Forti ist hingegen alles konfiguriert. Das Debugglog zeigt, das das Gegenüber nicht vorhanden ist.

Nette Grüße
anpa

Guten Tag,

hat jemand Erfahrungen, eine OSPF Beziehung zwischen der Fortinet und der OpnSense herzustellen? Beide Router sind in der selber Area. Die Fortinet hat eine funktionierende IPSec Verbindung zur OpnSense. Auf der Fortinet ist dem physischen (externen) Interface ein Tunnelinterface zugeordnet, welches aber auf der OpnSense-Seite kein Äquivalent hat.

IPSec funktioniert mit statischen Routen problemlos, nur benötige ich auf der OpnSense-Seite ebenfalls ein Tun-Interface auf der Basis von IPSec, was von OSPF benutzt werden soll.

Bisher habe ich nur OSPF-Beziehungen zwischen Fortinets hergestellt, was jetzt mit der OPnSense zum Problem geworden ist.

Nette Grüße
AnPa

Hallo,

Dein Screenshot sagt aus meiner Sicht schon etwas aus: Syslog-ng detektiert das Problem und wird angehalten; P_pax produziert dann den eigentlichen Fehler. Bist Du sicher, dass die SSD in Ordnung ist? Kannst Du zum Testen mal einen anderen Datenträger einbauen? Vielleicht ist es wirklich ein I/O Problem mit Deiner SSD.

Ich verwende ähnliche Systeme mit ULV CPUs, allerdings von Shuttle u./o. von Thomas-Krenn. Ich achte allerdings darauf die BIOS-Versionen immer aktuell zu halten. Hast Du überprüft, ob es für Deine Hardware ein aktuelles BIOS gibt?

Gruß anpa

Hallo misu,

aus meiner Sicht ganz schön teuer. Vielleicht wäre zum Preis unter 500 Euro der LES compact 4L eine Alternative:

https://www.thomas-krenn.com/de/produkte/low-energy-systeme/les-compact-4l.html

Ich habe die LES Geräte mehrfach im Einsatz.

Nette Grüße
anpa

Hallo,

Du möchtest von Deinem Lan 1 und dem Lan 20 auf das Druckernetzwerk zugreifen. Du bräuchtest eigentlich nur in den Quellnetzwerken eine Zugriffsregel auf Deinen Drucker, mehr nicht. Alternativ kannst Du Dir unter "Firewall - Groups" eine "Interface Group" einrichten, was den entscheidenden Vorteil hat, dass die Quellnetzwerke werden zusammengefasst werden.

Nette Grüße
anpa

In OPNSense gibst Du unter "Interfaces  > Other Types > VLAN" die ID, also das implizite Tag, vor. Dann kannst Du unter "Interfaces > Assignments" das Parentinterface auswählen. Ist dies das LAN musst Du im (Netgear-) Swicht zum einen das VLan anlegen und im VLAN selber den Port an dem Deine OPNSense hängt "T"agged anklicken. Die PVID stellst Du auf "1"

Sollte Dein pysischer LAN Port auf dem Switch untagged sein, muss Du den Port auf dem Netgear Switch die entsprechende PVID geben.

Doch Vorsicht die PVID1 ist immer dem Default-VLAN vergeben, wenn Du Dich zu sehr auf das VLAN1 beziehst wirst Du früher oder später auf Probleme stoßen. Lt. IEEE802.1Q kannst Du 4096 VLAN-Ids vergeben. Bei Netgeargeräten sind auch die VLANs 2/3 hard gecoded. Verwende mit den GS-108(v2) lieber VLANs >3.

Vielleicht hilft Dir auch das hier:
https://forum.opnsense.org/index.php?topic=12721.0


cu anpa

Danke rantwolf, das hat funktioniert. An der Konsole das Vorhaben umzusetzen war wohl meinerseits etwas übertrieben.

Hallo,

ich bin erst seit wenigen Tagen OPNSense Anwender. Hatte vorher IPCop am Laufen, ärgerte mich aber ständig über die Beschränkung auf die max. 4 Firewallzonen. Nach der OPNSense Installation fiel mir beim ausführlicheren Lesen der Dokumentation auf, dass ich bei der Installation hätte angeben können, das physische LAN Interface (bge0) bereits mit dem VLAN für das interne Netz hätte taggen (bge0_vlan123) können. Switchseitig ist das natürlich ebenfalls umzusetzen.

Nun ist die Frage, wie ich das nachträglich realisieren kann? Ich bin trotz Neuzuordnungen der Interfaces für LAN und WAN nicht mehr in der Lage mich via SSH oder HTTPS an der Firewall anzumelden; außer ich greife auf das Backup der config.xml zurück.

Die /config/config.xml enthält alle durch mich getätigten Einstellungen, auch die an der Konsole getätigten VLAN Zuordnungen. Die Alternative, die VLANs von dem untagged VLAN, was bei mir LAN (bge0) repräsentiert, abzuleiten funktioniert problemlos über das Webinterface, doch wollte ich alle VLANs auf dem Interface getaggt anliegen haben, um die internen Port aus dem Defaultvlan des Switches heraus zu bekommen.

Kann es sein, dass die gesetzte Anti-Lockout Regel auf das zuerst eingerichtete Interface zeigt und nicht auf das bge0_vlan123? Wie kann ich das per Regel an der Konsole umstellen? Muss der Webserver separat auf das neue Interface gematcht werden?

Habt ihr für das Vorhaben eine Lösung?

Nette Grüße
anpa