OPNsense mehrere Wireguard Interfaces mit Split-Tunnel
Hallo,
ich habe ein komisches Problem unter OPNsense 23.1 und bin mich nicht sicher ob es sich um einen Bug handelt, vielleicht kann da jemand was zu sagen:
Im möchte zwei unterschiedliche Instanzen und Interfaces jeweils mit 0.0.0.0/0 zu zwei unterschiedlichen Endpoints.
Die eine Instanz hat als Tunnel Address 192.168.100.110/24 und die andere 192.168.101.110/24. Jeweils wg1 und wg2 als Interface. Bei beiden ist "Disable Routes" der Haken gesetzt. Die Endpunkte haben im Transfernetz von wireguard jeweils die IP 192.168.100.252 und 192.168.101.252. Es handelt sich aber um zwei unterschiedliche öffentliche Adressen!
Der Tunnel über Interface wg1 funktioniert soweit ohne Probleme. Aber wg2 funktioniert nicht. Wenn ich die Subnetzmaske unter Local für wg2 herausnehme und nur die IP eintrage, dann steht in der Routing Table statt "192.168.101.110/24" dann "192.168.101.110/8". Dann bekomme ich einen Handshake und der Tunnel steht. Ich kann also quasi nicht zweimal eine Tunnel Address mit /24er Subnetzmaske anlegen. Keine Ahnung wie das zusammenhängt, weil eigentlich sollte da zumindest dennoch der Handshake auf Layer 2 funktionieren. Aber selbst das passiert nicht.
Weiß jemand mehr?
Grüße
ich habe ein komisches Problem unter OPNsense 23.1 und bin mich nicht sicher ob es sich um einen Bug handelt, vielleicht kann da jemand was zu sagen:
Im möchte zwei unterschiedliche Instanzen und Interfaces jeweils mit 0.0.0.0/0 zu zwei unterschiedlichen Endpoints.
Die eine Instanz hat als Tunnel Address 192.168.100.110/24 und die andere 192.168.101.110/24. Jeweils wg1 und wg2 als Interface. Bei beiden ist "Disable Routes" der Haken gesetzt. Die Endpunkte haben im Transfernetz von wireguard jeweils die IP 192.168.100.252 und 192.168.101.252. Es handelt sich aber um zwei unterschiedliche öffentliche Adressen!
Der Tunnel über Interface wg1 funktioniert soweit ohne Probleme. Aber wg2 funktioniert nicht. Wenn ich die Subnetzmaske unter Local für wg2 herausnehme und nur die IP eintrage, dann steht in der Routing Table statt "192.168.101.110/24" dann "192.168.101.110/8". Dann bekomme ich einen Handshake und der Tunnel steht. Ich kann also quasi nicht zweimal eine Tunnel Address mit /24er Subnetzmaske anlegen. Keine Ahnung wie das zusammenhängt, weil eigentlich sollte da zumindest dennoch der Handshake auf Layer 2 funktionieren. Aber selbst das passiert nicht.
Weiß jemand mehr?
Grüße
Please also mark the comments that contributed to the solution of the article
Content-ID: 6656932323
Url: https://administrator.de/contentid/6656932323
Printed on: October 6, 2024 at 17:10 o'clock
71 Comments
Latest comment
Zitat von @Fenris14:
Deshalb habe ich ja "Disable Routes" gesetzt. Ich will Routing über BGP betreiben.
Ähnlich wie hier:
https://www.klehr.de/michael/opnsense-s2s-mit-wireguard-frr-und-ospf/
Deshalb habe ich ja "Disable Routes" gesetzt. Ich will Routing über BGP betreiben.
Ähnlich wie hier:
https://www.klehr.de/michael/opnsense-s2s-mit-wireguard-frr-und-ospf/
Ich habe deinen Text jetzt drei mal gelesen. Erwähnt hast du dies nirgend wo.
Nun gut, bis gerade war mir neu, dass so etwas überhaupt schon mit Wireguard funktioniert.
Es ist, wie die Kollegen oben ja auch schon anmerken, nicht ganz einfach anhand der wenig themenbezogenen Thread Überschrift und kryptischen Bezeichnungen wie "Instanzen" zu erkennen das es schlicht und einfach um dynamisches Routing mit BGP über Wireguard Tunnel geht. Aber nundenn...
Wie man dynamisches Routing mit WG umsetzt zeigt dir das hiesige Wireguard Tutorial an einem Praxisbeispiel mit OSPF.
Statt OSPF wäre es bei dir dann ein BGP Peer. Bedeutet dann das du in den allowed IPs die Multicast Adressen weglassen kannst denn BGP nutzt dafür bekanntlich TCP 197 Sessions.
Gateway Redirect Setups mit Wireguard (0.0.0.0/0) sind dabei natürlich unsinnig, denn das führt ja dann auch gleichzeitig BGP ad absurdum.
Im Grunde ist das Setup doch kinderleicht.
Ich will Routing über BGP betreiben.
Und warum dann so einen Unsinn mit 2 Instanzen?? Das bei dynamischen Routing doch Quatsch, was sollte der tiefere Sinn davon sein?Wie man dynamisches Routing mit WG umsetzt zeigt dir das hiesige Wireguard Tutorial an einem Praxisbeispiel mit OSPF.
Statt OSPF wäre es bei dir dann ein BGP Peer. Bedeutet dann das du in den allowed IPs die Multicast Adressen weglassen kannst denn BGP nutzt dafür bekanntlich TCP 197 Sessions.
Gateway Redirect Setups mit Wireguard (0.0.0.0/0) sind dabei natürlich unsinnig, denn das führt ja dann auch gleichzeitig BGP ad absurdum.
Im Grunde ist das Setup doch kinderleicht.
- Zuallererst solltest du hier mal klären ob due iBGP machst, also nur innerhalb des AS routetst oder eBGP AS übergreifend
- Dann setzt du erstmal einen WG Tunnel auf und routets erstmal nur die BGP Peer Adressen in den Tunnel
- BGP Peer etablieren idealerweise mit Route Summarization und die Routing Table auf beiden Seiten checken
- Dann trägst du die aggregierten Routen in die Allowed IPs ein, damit diese aggregierten Netze über den Peer übertragen werden
- Fertisch
Ich sag dir ganz ehrlich, ich müsste das Konstrukt erst nachbauen. Schwer zu sagen, ob sich hier jemand findet der ebenfalls Wireguard in einer Konstellation mit BGP betreibt.
Wieso nutzt du nicht OSPF wie in deinem Guide angesprochen? Das scheint ja zu funktionieren.
Auf einer PfSense ist das anscheint möglich. Allerdings lässt sich sowas wohl nicht per Gui konfigurieren.
Wieso nutzt du nicht OSPF wie in deinem Guide angesprochen? Das scheint ja zu funktionieren.
Auf einer PfSense ist das anscheint möglich. Allerdings lässt sich sowas wohl nicht per Gui konfigurieren.
Wireguard in einer Konstellation mit BGP betreibt.
Das ist nicht ungewöhnlich und funktioniert problemlos! Wenn man es denn richtig macht... Wieso nutzt du nicht OSPF wie in deinem Guide angesprochen?
Das muss er nicht. BGP ist sogar in dem VPN Umfeld etwas effizienter weil es kein Multicasting nutzt sondern über einen TCP Link funktioniert. Letztlich ist das aber eine Geschmacksfrage...Auf einer PfSense ist das anscheint möglich.
Ob OPNsense oder pfSense spielt dabei keine Rolle.Allerdings lässt sich sowas wohl nicht per Gui konfigurieren.
Doch, sofern der TO das Quagga oder FRR Package nutzt, denn beide sind ins GUI integriert.
Klingt auf jeden Fall interessant.
Ich habe auf die schnelle Bspw. diesen Guide gefunden:
https://docs.netgate.com/tnsr/en/latest/recipes/wireguard-ospf/index.htm ...
Ich habe auf die schnelle Bspw. diesen Guide gefunden:
https://docs.netgate.com/tnsr/en/latest/recipes/wireguard-ospf/index.htm ...
Mit mehreren Instanzen für Ausfallsicherheit wäre doch möglich?! Ich will ja kein Point-to-Multipoint.
Das ist doch aber Unsinn. Mit Ausfallsicherheit hat das doch gar nichts zu tun wenn du nur ein singuläres Device hast was du über nur eine einzige IP Adresse nutzt. Da nützen dir auch 2 oder 2 Wireguard Prozesse logischerweise nix. Im Gegenteil das kostet nur unnötige Performance und ist zudem völlig überflüssig, denn du routest ja zentral über einen Tunnel.Hier machst du vermutlich einen gehörigen Denkfehler, kann das sein?!
Zudem ist deine WG Konfig auch falsch!
- Es fehlt auf dem Initiator (WG Client) die interne Wireguard IP! So kann der Tunnel niemals funktionieren
- Auf einem Initiator (WG Client) definiert man niemals Pubic und Private Key zusammen!
- allowed ips: 0.0.0.0/0 ist, wie oben schon gesagt, sinnfrei bei dynamischem Routing und führt das per se ad absurdum. Wenn du so oder so alles mit einer default Route in den Tunnel routest warum willst du dann noch dynamisch routen, das wäre ja dann Quatsch. Sinnvoll wäre hier "allowed ips: 192.168.100.252/32, 10.11.0.0/16" Genau kann man das aber nur sagen wenn man deinen IP Adressplan kennen würde und vor allem dein internes WG Netzwerk.
Wie sieht die Routing Table auf dem neighbor 192.168.100.252 aus? Kommen dort die BGP Routen an?
Hier als Ostergeschenk nochmal ein Setup aus der Praxis um dir zu zeigen das es mit den richtigen Settings fehlerlos mit BGR Routing über Wireguard auch mit unterschiedlichen Komponenten fehlerlos klappt...
Der Mikrotik hat zusätzlich eine eBGP Connection auf einen Cisco 2611 Router mit dem AS 64714.
Dieser redistrubuiert BGP in OSPF und sendet das weiter an den Cisco 2621 was aber erstmal für das Setup nur ein kosmetisches Goodie ist.
Ein großer und entscheidender Vorteil bei dynamischem Routing ist das das mühsame Eintragen von statischen Routen und Gateways bei Wireguard Komponenten die kein automatisches Cryptokey Routing supporten wie z.B. pfSense, OPNsense und Mikrotik entfällt. Damit hat man bei Designs mit vielen Routen ein sehr sehr geringes Fehlerrisiko. Ebenso bei mehreren Links auch ein automatisches Failover was aber bekanntlich generell ein Vorteil von dynamischem Routing ist.
Anhand der Routing Tabellen kannst du sehen das die Routen sauber übertragen werden
Table of contents
Wireguard - BGD Netzwerk Design
Die pfSense Firewall ist mit dem Mikrotik über einen Wireguard VPN Tunnel verbunden. Beide Systeme sind hier im gleichen AS 65530.Der Mikrotik hat zusätzlich eine eBGP Connection auf einen Cisco 2611 Router mit dem AS 64714.
Dieser redistrubuiert BGP in OSPF und sendet das weiter an den Cisco 2621 was aber erstmal für das Setup nur ein kosmetisches Goodie ist.
Ein großer und entscheidender Vorteil bei dynamischem Routing ist das das mühsame Eintragen von statischen Routen und Gateways bei Wireguard Komponenten die kein automatisches Cryptokey Routing supporten wie z.B. pfSense, OPNsense und Mikrotik entfällt. Damit hat man bei Designs mit vielen Routen ein sehr sehr geringes Fehlerrisiko. Ebenso bei mehreren Links auch ein automatisches Failover was aber bekanntlich generell ein Vorteil von dynamischem Routing ist.
Anhand der Routing Tabellen kannst du sehen das die Routen sauber übertragen werden
Wireguard Setup
Das Wireguard Setup ist unspektakulär und wichtig ist nur dann man in den Allowed IPs die korrekten Einträge macht. Gateway Redirect scheidet bei dynamischem Routing generell aus.Wireguard Peer Setup pfSense
Wireguard Peer Setup Mikrotik
BGP Setup
Auch hier auf beiden ein klassisches iBGP Standardsetup.BGP Peer Setup pfSense
BGP Peer Setup Mikrotik
Der Mikrotik hat den iBGP Peer auf die pfSense, FRR und einen eBGP Peer auf den Cisco zum AS 64714 um beide Varianten zu sehen.BGP Peer Setup Cisco Router
router bgp 64714
bgp router-id 172.22.22.11
bgp log-neighbor-changes
neighbor 192.168.87.1 remote-as 65530
neighbor 192.168.87.1 description Mikrotik
neighbor 192.168.87.1 update-source Ethernet1/1
!
address-family ipv4
neighbor 192.168.87.1 activate
auto-summary
no synchronization
network 172.22.22.11 mask 255.255.255.255
network 172.26.11.0 mask 255.255.255.0
exit-address-family
Routing Tabellen und Ping Checks
pfSense, FRR
Mikrotik
Cisco
Cisco_2611#sh ip bgp
BGP table version is 6, local router ID is 172.22.22.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 192.168.87.1 0 65530 i
*> 100.65.65.0/28 192.168.87.1 0 65530 i
*> 172.22.22.11/32 0.0.0.0 0 32768 i
*> 172.26.11.0/24 0.0.0.0 0 32768 i
*> 192.168.2.0 192.168.87.1 0 65530 i
Cisco_2611#ping 192.168.87.1 source ethernet 1/3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.87.1, timeout is 2 seconds:
Packet sent with a source address of 172.26.11.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Cisco_2611#ping 192.168.2.1 source ethernet 1/3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 172.26.11.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Fazit
Works as designed!! 👍 😉Es geht halt nur die zweite Instanz nicht.
Wie bereits gesagt: Eine 2te "Instanz" ist generell unsinnig und überflüssig in so einen Setup.legitim den anderen Hauptstandort noch als weiteren Neighbor für BGP zu haben, oder nicht?
Absolut!! Das wäre auch best Practise aber dafür benötigt man logischerweise keine 2 WG "Instanzen". Wozu auch...?!Versteht man dich recht, sähe das von dir oben beschriebene Szenario mit 2 kleinen Beispielstandorten ungefähr so aus, richtig?
(BGP Peer ist der Übersicht halber nur einmal eingezeichnet)
Will mal nicht ausschließen das ich einen groben Denkfehler im Bezug auf Wireguard habe
Ich glaube das ist hier (etwas) die Fall... 😉findest du 100 verschiedene Herangehensweisen.
Das kann ich mir nicht wirklich vorstellen, denn WG ist was das Setup anbetrifft sehr einfach. Man hat genau 2 Optionen und Varianten: Responder und Initiator....nicht mehr und nicht weniger.dann mal sehen was passiert.
Du wirst sehen das das 100% klappen wird. Einen besseren Beweis als die saubere Funktionalität über 3 Hersteller hinweg, wie oben dokumentiert, spricht ja für sich.Ansonsten, wenns mal kneifen sollte, einfach hier fragen.
Nicht denselben Tunnel, denn das würde dann mit redundanten Routing über die Hauptstandorte nicht klappen.
Ich vermute langsam dämmert es was du mit "weiteren Instanzen" meintest.
Vermutlich nicht einen 2ten WG Daemon sondern nur ein weiteres wgx Tunnel Interface, richtig?
Da hast du dann natürlich Recht. Jeder Knoten in dem o.a. Design hat immer 2 WG Interfaces, wg0 und wg1 in separaten IP Netzen.
Ob mit BGP, OSPF oder RIPv2 ist dabei eher eine Geschmacks- bzw. Skalierungsfrage. FRR kann ja so oder so alles. 😉
Ich vermute langsam dämmert es was du mit "weiteren Instanzen" meintest.
Vermutlich nicht einen 2ten WG Daemon sondern nur ein weiteres wgx Tunnel Interface, richtig?
Da hast du dann natürlich Recht. Jeder Knoten in dem o.a. Design hat immer 2 WG Interfaces, wg0 und wg1 in separaten IP Netzen.
- Die Hauptstandorte wg0 für ihren Tunnel untereinander ( /30er IP Netz würde hier reichen) und wg1 zur Annahme der Tunnel aus den kleinen Standorten.
- Die kleinen Standorte dann jeweils ihren wg0 Tunnel auf den Standort 1 wg1 Tunnel und ihr wg1 auf den Standort 2 wg1 Tunnel.
Ob mit BGP, OSPF oder RIPv2 ist dabei eher eine Geschmacks- bzw. Skalierungsfrage. FRR kann ja so oder so alles. 😉
Zitat von @Fenris14:
Das meinte ich eigentlich und da kommt scheinbar ein Bug bei OPNsense zum tragen. Scheinbar wenn ich zwei Mal die selbe Subnetzmaske für das Tunnel-Netzwerk verwende, funktioniert der eine Tunnel einfach nicht. Er stellt nicht mal eine Layer2-Verbindung her. Kein Handshake. Während der erste Tunnel normal läuft. Ich kann auch auf dem WAN-Interface keine ausgehenden Pakete feststellen, obwohl bereits ein anderer Port und natürlich auch ein andere öffentliche IP erreicht werden soll. Es ist skandalös.
Das meinte ich eigentlich und da kommt scheinbar ein Bug bei OPNsense zum tragen. Scheinbar wenn ich zwei Mal die selbe Subnetzmaske für das Tunnel-Netzwerk verwende, funktioniert der eine Tunnel einfach nicht. Er stellt nicht mal eine Layer2-Verbindung her. Kein Handshake. Während der erste Tunnel normal läuft. Ich kann auch auf dem WAN-Interface keine ausgehenden Pakete feststellen, obwohl bereits ein anderer Port und natürlich auch ein andere öffentliche IP erreicht werden soll. Es ist skandalös.
Hi,
habe das gerade mal getestet, funktioniert hier testweise absolut fehlerfrei mit zwei Wireguard Interfaces (wg1/wg2) jeweils mit 0.0.0.0/0 in den AllowedIPs durchlässig gemacht und natürlich mit Häkchen bei Disable Routes und selbst mit den bei dir genutzten 24 Masken für die Transfernetze!!
Muss also definitiv ein Config-Fehler auf deiner Seite sein. Hätte mich nämlich schwer gewundert wenn das nicht funktioniert hätte, denn Wireguard ist ja perfekt im aktuellen Kernel integriert solche Routing basics würden bei den automatisierten Kernel-Tests nämlich direkt auffallen!
Meine Version getestete Version von OPNSense ist :
OPNsense 23.1.5_4-amd64 / FreeBSD 13.1-RELEASE-p7 / OpenSSL 1.1.1t 7 Feb 2023
Wireguard Settings
Routing-Table
Connectivity-Check zu den Peers.
Fazit: Arbeitet so wie erwartet einwandfrei! 👍
Cheers briggs
Scheinbar wenn ich zwei Mal die selbe Subnetzmaske für das Tunnel-Netzwerk verwende
Dieselbe Subnetzmaske ist auch falsch.Der Server bekommt immer eine /32er Hostmaske der Tunnel IP bei den "Allowed IPs". Die zu übertragenden Netze werden dann je nach Größe mit einer entsprechenden CIDR Maske verwendet je nachdem was man übertragen will bzw. muss.
Ggf. missversteht man dich jetzt auch weil nicht ganz klar ist was du mit der gleichen Maske meinst. Deine Konfig bzw. ein Screenshot wäre hier hilfreich für eine zielführende Antwort.
Bei dynamischem Routing solltest du m.E. nicht mit WG 0.0.0.0/0 Redirects in den Allowed IPs arbeiten, weil das den gesamten Traffic der kleinen Standorte in den Tunnel routet was man keinesfalls will.
Es soll ja nur der Traffic der remoten VPN Netze in den Tunnel, deshalb sollte man das immer dediziert mit entsprechenden CIDR Masken einschränken. Immer Split Tunneling also.
Ansonsten rennt auch sämtlicher lokaler Internet Traffic dieser kleinen Standorte in den Tunnel was sicher nicht gewollt ist. Sieh dir das oben beim BGP Setup im Wireguard Screenshot an!
Er stellt nicht mal eine Layer2-Verbindung her. Kein Handshake.
Leider etwas doppeldeutig?! WAS genau meinst du? Das WG Handshaking. Das BGP Handshaking?Ansonsten rennt auch sämtlicher lokaler Internet Traffic dieser kleinen Standorte in den Tunnel was sicher nicht gewollt ist.
Nope, dafür ist ja gerade der Haken bei Disable Routes auf der OPNSense zuständig, welcher das automatische Hinzufügen der AllowedIPs in die Routing-Tabelle verhindert und somit auch kein Gateway Redirect auf der OPNSense stattfindet ... 😉.Es gibt Szenarien da braucht man die 0.0.0.0/0 zwingend auch in den AllowedIPs, z.B. wenn man den Internet-Traffic nur für bestimmte Clients per PolicyRule über den Tunnel leiten möchte, den Rest aber weiterhin über das normale DefaultGW.
dafür ist ja gerade der Haken bei Disable Routes auf der OPNSense zuständig
OK, sorry hatte ich im Eifer des Gefechts glatt überlesen! Der Haken ist dann bei Verwendung eines dynamischen Routings mit FRR dann sogar Pflicht!
@Fenris14
und die Tunnel Address die selbe Subnetzmaske hat, kommt kein WG Handshake zustande.
Bedenke das die beiden wg Interfaces natürlich in unterschiedlichen IP Netzen liegen müssen die sich NICHT mit anderen IP Netzen überschneiden dürfen!Das Setup des Kollegen @6247018886 rennt hier auf einer latest OPNsense mit 2 wg Interfaces ebenso fehlerlos. Diesmal auch mit "disabled Routes". 😉
Irgendwas hast du in deinem Setup noch falsch gemacht.
Vermutlich vergessen die WG Tunnelinterface im Interface Assignement zuzuweisen und entsprechende Regeln dort zu setzen?! Oder was auch immer.
Das obige Setup des Kollegen @6247018886 (ex "@briggs") rennt fehlerlos! Hier an einem einfachen OPNsense (WG Initiator) live Basissetup wo ein Peer (1) einen Mikrotik Router bedient und der andere Peer (2) einen Raspberry Pi.
Beides aktuell noch ohne BGP Peer.
Mikrotik WG IP Adresse (Peer1) = 100.64.65.30 /27
OPNsense WG IP Adresse (Peer2, WGTUN2) = 100.64.65.33 /27
RasPi WG IP Adresse (Peer2) = 100.64.65.62 /27
Vermutlich vergessen die WG Tunnelinterface im Interface Assignement zuzuweisen und entsprechende Regeln dort zu setzen?! Oder was auch immer.
Das obige Setup des Kollegen @6247018886 (ex "@briggs") rennt fehlerlos! Hier an einem einfachen OPNsense (WG Initiator) live Basissetup wo ein Peer (1) einen Mikrotik Router bedient und der andere Peer (2) einen Raspberry Pi.
Beides aktuell noch ohne BGP Peer.
Table of contents
WG Setup OPNsense
OPNsense WG IP Adresse (Peer1, WGTUN1) = 100.64.65.1 /27Mikrotik WG IP Adresse (Peer1) = 100.64.65.30 /27
OPNsense WG IP Adresse (Peer2, WGTUN2) = 100.64.65.33 /27
RasPi WG IP Adresse (Peer2) = 100.64.65.62 /27
OPNsense WG Interface Zuweisungen
Firewall Regeln auf den Tunnelinterfaces
OPNsense Ping Check
Mikrotik Connection Check (Peer1, WGTUN1)
RasPi Connection Check (Peer2, WGTUN2)
[Interface]
Address = 100.64.65.62/27
ListenPort = 57822
PrivateKey = 8C+KNbxJXmNOvASetoqRXm2+01234567V5s9AC0rIVs=
[Peer]
PublicKey = Hy+UJy+hzwO99pkU3m21234567BAp2tSYrVnOfSBo=
AllowedIPs = 100.64.65.33/32
root@raspi:~# ping -c 3 100.64.65.33
PING 100.64.65.33 (100.64.65.33) 56(84) bytes of data.
64 bytes from 100.64.65.33: icmp_seq=1 ttl=64 time=1.33 ms
64 bytes from 100.64.65.33: icmp_seq=2 ttl=64 time=1.63 ms
64 bytes from 100.64.65.33: icmp_seq=3 ttl=64 time=1.38 ms
--- 100.64.65.33 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.331/1.446/1.631/0.132 ms
Fazit
Works as designed! 👍
Also wenn dir zwei Leute sagen das es definitiv ohne Verrenkungen einwandfrei funktioniert dann wird deine OPNSense vergriesgnaselt sein, setze sie zurück und starte nochmal clean, du wirst sehen das es geht.
Wir sehen hier ja noch nicht mal deine Routing-Tabelle, vor sowie während des Tunnelaufbaus, geschweige denn das Setup der WG-Server-Instanzen, da wird es sehr wahrscheinlich irgendwo Subnetz-Überschneidungen oder sonstige Unstimmigkeiten geben, so meine Glaskugeln..
Wir sehen hier ja noch nicht mal deine Routing-Tabelle, vor sowie während des Tunnelaufbaus, geschweige denn das Setup der WG-Server-Instanzen, da wird es sehr wahrscheinlich irgendwo Subnetz-Überschneidungen oder sonstige Unstimmigkeiten geben, so meine Glaskugeln..
Wenn sich beide Sensen so verhalten ist entweder schon die Serverseite unstimmig oder du machst den gleichen Fehler bei der Einrichtung auf beiden Sensen.
Am Ende sind es zu 99% wieder die berühmten 50cm oder die 🍅🍅 auf der Linse 😉. We will see, gib dir einfach noch mal etwas Ruhe, und gehe in dich, dann löst sich das von i.d.R. von selbst.
Am Ende sind es zu 99% wieder die berühmten 50cm oder die 🍅🍅 auf der Linse 😉. We will see, gib dir einfach noch mal etwas Ruhe, und gehe in dich, dann löst sich das von i.d.R. von selbst.
Das reine WG Handshaking klappt schon nicht.
Oha, dann hast du aber schon ein grundsätzliches IP Connectivity Problem zwischen den Tunnelendpunkten generell. Oder...du hast beim Responder (Endpoint) vergessen eine entsprechende Firewall / Access Regel auf den verwendeten Wireguard UDP Port zu setzen?!Bei der o.a. Initiator Konfig ist das nicht erforderlich beim Responder aber sehr wohl. Oben z.B. der Mikrotik und beim RasPi sinds die nftables sofern aktiv.
Wenn das bei dir auch eine Firewall ist musst du diese Regel entsprechend einrichten, genau wie die Regeln für den Tunneltraffic.
Du kannst dir mit der Packet Capture Funktion einen Filter auf die UDP Ports legen und den eingehenden Traffic mitschneiden um zu sehen ob da überhaupt was ankommt.
Das hört sich so an als ob dein Fehler gar nicht am WG Setup selber liegt sondern eher an der grundsätzlichen Basis IP Connectivity. Wenns da schon scheitert, scheitert natürlich auch der ganze Rest.
Der letzte Tip vom Kollegen @6247018886 sollte da immer helfen. In Ruhe nochmal alles durchdenken bei dir... 😉
Der Vollständigkeit halber hier die Routing Table zum o.a. Setup:
Also wenn du das WG-Interface zuweist sollte man dort auch eine IPv4 Config hinterlegen und dort die WG-IP im Transfernetz hinterlegen und nicht auf NONE stehen lassen!
Des weiteren sollte natürlich die Firewall des Debian Traffic auf dem Port 55555(UDP) zulassen, das man den Debian "anpingen" kann heißt eben noch lange nicht das er auf dem Port UDP Traffic entgegen nimmt ...
Wenn du schon einen Tunnel nicht zum fluppen bringst brauchst du erst gar nicht mit zwei anfangen!
Des weiteren sollte natürlich die Firewall des Debian Traffic auf dem Port 55555(UDP) zulassen, das man den Debian "anpingen" kann heißt eben noch lange nicht das er auf dem Port UDP Traffic entgegen nimmt ...
Wenn du schon einen Tunnel nicht zum fluppen bringst brauchst du erst gar nicht mit zwei anfangen!
Zitat von @Fenris14:
Du, das macht keine Sinn dort eine Adresse zu vergeben, was bringt mir da eine Adresse wenn Layer2 noch nicht hergestellt ist? Es ist kein Handshake da.
Doch, ein Handshake gibt es bei Wireguard erst wennn Traffic da ist, ohne gültigen Traffic von einer korrekten Absender-IP kein Handshake-Counter Increase!Du, das macht keine Sinn dort eine Adresse zu vergeben, was bringt mir da eine Adresse wenn Layer2 noch nicht hergestellt ist? Es ist kein Handshake da.
Bei UDP gibt es in dem Sinne auch keine Verbindung, das ist kein TCP!
Läuft der Dienst/Daemon denn überhaupt?
Outbound NAT überprüft?
WAN Output-Chain(Firewall) der Sense gecheckt?
TCPDump auf allen Interfaces (Konsole) gemacht?
Echt eine schwere Geburt hier ...
Outbound NAT überprüft?
WAN Output-Chain(Firewall) der Sense gecheckt?
TCPDump auf allen Interfaces (Konsole) gemacht?
Echt eine schwere Geburt hier ...
Da wird ja der Hund in der Pfanne verrückt .
Immer Step by Step lautet die Devise!
Ich habe die OPNsense nochmal komplett zurückgesetzt.
Das hätte ich ja mal als erstes gemacht, bei solchen unerklärlichen Dingen.* FRR mal rausgeschmissen => Auf gut Glück, weil meine Vermutung das da irgendwas grundlegend umgebaut wird
Das ist doch im Neuzustand erst gar nicht installiert Denke das wird dann der Fehler bei dir gewesen sein.Immer Step by Step lautet die Devise!
* Firewall=>Rules=>Floating eine Regel hinzugefügt, die Direction Any alle Pakete vom Port UDP 55555 und Destination "This FIrewall" durch lässt.
Wird nicht benötigt, da Verbindung ausgehend aufgebaut. Eingehend benötigt man nur eine Regel am WAN wenn aus der Ferne auf die Sense zugegriffen werden soll, oder man kein Keep-Alive auf dem WG Interface gesetzt hat.* Statt jedes Mal Manual Outbound dieses Mal Hybrid genommen und NAT wie folgende eingestellt...
Im Endeffekt auch alles Standard.An der Stelle scheint mir aber auch OPNsense nicht ganz stable zu sein
Hm, dann müsste von den 20 Sensen (auf unterschiedlichster Hardware und auch virtuell) die ich unter meinen Fittichen habe, zumindest eine davon solche Zicken zeigen, davon ist aber absolut keine Spur. Das sind ja nun absolute Basics, die bei Tests sofort auffallen würden. Denke da hat eher deine Umgebung eine Macke.Ach ja, fällt mir gerade noch ein, in diese Falle hier fällt man leicht herein wenn man in Testumgebungen hantiert:
OPNsense von Rechner im Layer 2 WAN Netzwerk ansprechen
Das Setup hier entspricht exakt deinem.
Du kannst doch auf deinem Debian ganz einfach mit tcpdump einmal checken ob dort von der OPNsense (Initiator) Wireguard Pakete eingehen. Dein Debian ist ja genau wie hier der Responder.
Hier ein entsprechender Output dazu:
OPNsense = 10.1.10.98 /24 (VM auf Proxmox 7.4)
Debian = 10.11.1.148 /24
Dazwischen routet ein Cisco L3 Switch.
Der Ablauf ist hier auf dem Debian sehr schön zu sehen:
Analog dazu der "tcpdump" des zweiten WG Peers mit UDP Port 57821 auf den Mikrotik:
Auch da: Works as designed!!
Du kannst doch auf deinem Debian ganz einfach mit tcpdump einmal checken ob dort von der OPNsense (Initiator) Wireguard Pakete eingehen. Dein Debian ist ja genau wie hier der Responder.
Hier ein entsprechender Output dazu:
OPNsense = 10.1.10.98 /24 (VM auf Proxmox 7.4)
Debian = 10.11.1.148 /24
Dazwischen routet ein Cisco L3 Switch.
root@debian:~# tcpdump -i eth0 port 57822
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:36:11.885284 IP 10.1.10.98.57822 > debian.57822: UDP, length 148
10:36:17.277003 IP 10.1.10.98.57822 > debian.57822: UDP, length 148
10:36:22.660745 IP 10.1.10.98.57822 > debian.57822: UDP, length 148
10:36:27.979032 IP 10.1.10.98.57822 > debian.57822: UDP, length 148
10:36:27.987359 IP debian.57822 > 10.1.10.98.57822: UDP, length 92
10:36:27.988443 IP 10.1.10.98.57822 > debian.57822: UDP, length 32
root@debian:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 100.64.65.62/27 dev wg0
[#] ip link set mtu 1420 up dev wg0
root@debian:~# wg show
interface: wg0
public key: CrsBhWgYSAQ/hVOwdhAScOu1234567SQaKJqhFDp2HA=
private key: (hidden)
listening port: 57822
peer: Hy+UJy+hzwO99pkU3m2+SOK1234567p2tSYrVnOfSBo=
endpoint: 10.1.10.98:57822
allowed ips: 100.64.65.33/32
latest handshake: 24 seconds ago
transfer: 180 B received, 92 B sent
root@debian:~# cat /etc/wireguard/wg0.conf
[Interface]
Address = 100.64.65.62/27
ListenPort = 57822
PrivateKey = 8C+KNbxJXmNOvA1234567m2+07tM2xuqV5s9AC0rIVs=
[Peer]
PublicKey = Hy+UJy+hzwO99pkU3m2+SOK1234567p2tSYrVnOfSBo=
AllowedIPs = 100.64.65.33/32
- OPNsense sendet Wireguard Connect Pakete
- Nach dem 3ten Paket wurde der WG Daemon mit wg-quick up wg0 auf dem Debian gestartet und sofort die Tunnelsession etabliert. Ein wg show zeigt dies.
- Am Ende die einfach gehalteten Konfig auf dem Debian
- Works as designed!!
Analog dazu der "tcpdump" des zweiten WG Peers mit UDP Port 57821 auf den Mikrotik:
Auch da: Works as designed!!
Das Setup hier entspricht exakt deinem.
Aquí también ...Works as designed!
AbsolutamenteMehr Silbertablett geht nun echt nicht mehr.
Zwei ausführliche Tutorials in einem Beitrag, das schreit langsam aber sicher nach Kaffeekasse 😀.
Ich hol schon mal den Latt-Hammer zum Nagel aus dem Brett ziehen. In weiser Voraussicht 😉
Das ist ja Unsinn! Nicht so schnell aufgeben...! 😉 Irgendwo machst du noch einen kleinen Fehler.
Dann gehen wir mit dir eben nochmal genau die OPNsense Settings durch. Lösche ggf. die bestehenden Peers und setze die neu auf um ganz sicher zu gehen. Fange mit einem an auf den Debian.
Zwei Dinge:
Hier nochmals das entsprechende OPNsense Setup zum Peer2 auf den Debian (RasPi) mit UDP 57822:
Vergleiche das Setup genau mit deinem und finde den Fehler!
Firewall Regeln am WAN sind für WG nicht erforderlich sofern OPNsense hier Initiator ist also die WG Sessions aufbaut.
Peer Keepalives sind nur dann erforderlich wenn keine dynamischen Routing Protokolle aktiv sind. Die BGP oder OSPF Session Keepalives halten bei dynamischem Routing dann so oder so immer die Peers aktiv.
Dann gehen wir mit dir eben nochmal genau die OPNsense Settings durch. Lösche ggf. die bestehenden Peers und setze die neu auf um ganz sicher zu gehen. Fange mit einem an auf den Debian.
Zwei Dinge:
- Du schreibst deine OPNsense ist auch eine VM. Ist dem so? Wenn ja, wie ist das Setup dort? Wäre ja auch möglich das der WAN Port in der VM Umgebung ins Nirwana geht. Obwohl du sagst ja das du OPNsense (Im Ping Menü Source immer auf WAN Port IP!!) und Debian pingen kannst, richtig?
- Ggf. noch einmal deine WG OPNsense Setups posten. Kollege @6247018886 hat oben Recht das du im Interface Assignment der OPNsense zwingend das WG Interface zuweisen musst mit einer statischen IP Adresse. Regelwerk am WAN Port das inbound WG UDPs auf die WAN IP Adresse erlaubt sind ist auch klar.
Hier nochmals das entsprechende OPNsense Setup zum Peer2 auf den Debian (RasPi) mit UDP 57822:
Vergleiche das Setup genau mit deinem und finde den Fehler!
Firewall Regeln am WAN sind für WG nicht erforderlich sofern OPNsense hier Initiator ist also die WG Sessions aufbaut.
Peer Keepalives sind nur dann erforderlich wenn keine dynamischen Routing Protokolle aktiv sind. Die BGP oder OSPF Session Keepalives halten bei dynamischem Routing dann so oder so immer die Peers aktiv.
Zitat von @Fenris14:
Ich habe jetzt zum fünften Mal neu angefangen. Es fällt auf: Das sobald ich am zweiten Tunnel "Disable Routes" deaktiviere, auf einmal OPNsense anfängt etwas zu senden. Dieses Mal habe ich auch das Interface nicht zugewiesen und er sendet. Dieses Verhalten erschließt sich mir nicht.
Jetzt sind es auch physische Maschinen.
Ich habe jetzt zum fünften Mal neu angefangen. Es fällt auf: Das sobald ich am zweiten Tunnel "Disable Routes" deaktiviere, auf einmal OPNsense anfängt etwas zu senden. Dieses Mal habe ich auch das Interface nicht zugewiesen und er sendet. Dieses Verhalten erschließt sich mir nicht.
Jetzt sind es auch physische Maschinen.
Es gilt, wenn Interface zugewiesen wird dann bitte auch zwingend mit hinterlegte statischer IPv4 Config wie oben bereits geschrieben, NICHT auf None sonst löscht die Sense die bestehenden WG-Interface-Routen und es kommt zu einer inkonsistenten Routing-Tabelle !!
Ohne Interface-Zuweisung geht es auch so, aber halt mit Nachteilen zur FW-Kontrolle etc.
Zitat von @Fenris14:
OKay. Da machen wohl einige Tutorials die zu diesem Thema existieren einen Fehler. Weil dort ist jedes Mal die rede davon das man Zuweisen soll und nur aktivieren. So läuft bei mir auch derzeit der erste Tunnel.
Die sind oft für ältere Sensen, bei der aktuellen klappt das oft nicht mehr zuverlässig und bei Interface-Restarts/Config-Änderungen kommt es dann dabei zu fehlenden Routen.OKay. Da machen wohl einige Tutorials die zu diesem Thema existieren einen Fehler. Weil dort ist jedes Mal die rede davon das man Zuweisen soll und nur aktivieren. So läuft bei mir auch derzeit der erste Tunnel.
Interface zugewiesen, keine IP,
Wieso "keine IP"! Das ist falsch und damit kann die WG Konfig nicht funktionieren! Ist ja auch klar wenn die Interface IP Adresse fehlt!Es ist zwingend erforderlich im Interface Assignment immer das WG Interface hinzuzufügen und diesem eine statische IP Adresse zu gegeben! Ohne diesen Schritt kann das Wireguard VPN nicht sauber funktionieren!
Die pfSense WG Dokumentation ist hier besser und vollständiger als die der OPNsense die das "übersieht"!
Dieser Setup Schritt ist analog zu sehen zur statischen Interface Konfig des WG Interfaces:
[Interface]
Address = 100.64.65.62/27
Wenn diese zentrale Konfig fehlt ist es doch klar das das WG Setup ohne IP per se scheitern muss.
Die statische IP Adressierung des WG Interfaces ist ein Muss. Kollege @6247018886 hat das oben mehrfach explizit beschrieben:
Die Interfaces tauchen dann auch entsprechend mit ihrer Adressierung in der Dashboard Übersicht auf:
(Hier als "WGTUNx" weil ich möglichst vermeide Default Systemnamen zu verwenden)
Oder haben wir dich jetzt irgendwie missverstanden?!
Warum "wehrst" du dich denn so gegen die korrekte statische Angabe der Interface IP Adresse auf dem Tunnel Interface?! 🤔
Unverständlich, denn das ist doch immer zwingende Vorgabe bei der WG Einrichtung egal welche Plattform.
Die pfSense Doku diesbezüglich ist im Kapitel Assignment Procedure da ebenfalls eindeutig.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/assign.html
Ohne Tunnel IP Adresse ist dein WG Setup nicht wirklich korrekt aus IP Sicht.
Unverständlich, denn das ist doch immer zwingende Vorgabe bei der WG Einrichtung egal welche Plattform.
Die pfSense Doku diesbezüglich ist im Kapitel Assignment Procedure da ebenfalls eindeutig.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/assign.html
Scheinbar wird das gebraucht.
Nein, das ist falsch, denn mit 0.0.0.0/0 machst du ja schon ein vollständiges Redirect allen Traffics in den Tunnel. Zumindestens der per BGP gelernten Netze wenn du das Cryprokey Routing richtigerweise im Peer Setup disablest bei dynamischem Routing.Ohne Tunnel IP Adresse ist dein WG Setup nicht wirklich korrekt aus IP Sicht.
das immer der zweite Tunnel in der Liste scheinbar paar Minuten brauch
Bei den BDP Neighbors oder was meinst du?!Zitat von @Fenris14:
Nein. Ich meine den Tunnel. Ich habe sogar feststellen können wenn ich die Adresse aus dem Tunnel Netzwerk versuche anzupingen, das dadurch die Initialisierung des Tunnels getriggert wird. Vorher war wieder kein Traffic. Gepingt, plötzlich sendet er an den Peer.
Du verstehst das Cryptokey-Routing bei Wireguard offensichtlich noch nicht ganz.Nein. Ich meine den Tunnel. Ich habe sogar feststellen können wenn ich die Adresse aus dem Tunnel Netzwerk versuche anzupingen, das dadurch die Initialisierung des Tunnels getriggert wird. Vorher war wieder kein Traffic. Gepingt, plötzlich sendet er an den Peer.
Es gibt hier in dem Sinne keine dauerhafte VPN-Verbindung wie bei IPSec, die Verbindung ist immer dann da, wenn auch Traffic mit den korrekten Cryptos fließt, gibt es kein Traffic, ist die Verbindung auch nicht existent. Heißt konkret, du wirst auch keinen Traffic sehen solange du unter "KeepAlive" keinen Wert hinterlegst. Sieh Wireguard wie ein zustandsloses VPN das jederzeit existent ist sobald entsprechender Traffic fließt.
Bei jedem Handshake erhällt das Gegenüber auch die Absender-IP und Port welche der Server für den Peer aktualisiert, sofern kein fester Endpoint für den Peer hinterlegt ist.
Das macht Wireguard ja gerade so robust wenn man sich in wechselnden Netzen wie unzuverlässigen Mobilnetzen bewegt. Das "VPN" kann quasi gar nicht zusammenbrechen weil bei der nächsten Verbindung mit einem neuen Netz automatisch sehr schnell ein Handshake erfolgt und die Peer IP wieder aktualisiert wird. Das ist quasi transparente Verschlüsselung und bei weitem nicht so aufwendig wie die Initialisierung einer IPSec Verbindung, trotzdem vergleichbar so sicher.
Na, ich verstehe den Zweck nicht. Es funktioniert ja auch so.
Nur nochmal der Vollständigkeit halber....Du konfigurierst einen Debian, Windows oder Apple Wireguard Client doch auch nicht gänzlich ohne IP Adresse? Mal abgesehen davon das der Client dann gar nicht funktioniert, muss das virtuelle Interface eines WG Clients doch immer eine IP aus dem internen WG IP Netz haben. Andernfalls ist das VPN gar nicht (richtig) funktionsfähig. Das kann man also niemals einfach ignorieren.
Auf einem LAN Interface vergibst du ja auch immer eine IP und würdest den Zweck so einer IP dort niemals in Frage stellen, warum also am WG Interface wo eine IP ebenfalls zwingend ist?!
Zum Rest hat Kollege @6247018886 ja oben schon alles gesagt.
Die WG Interface IP hat auch gerade in deinem BGP Setup mit dynamischem Routing eine sehr wichtige Funktion, denn sie ist (oder sollte) von den externen Devices immer die BGP Neighbor Peer Adresse sein.
Damit schlägst du 2 Fliegen mit einer Klappe...
Das WG Interface ist ein virtuelles Interface. Solange also der WG Prozess rennt und das Interface aktiv ist, ist auch der BGP Link und deine Routen darüber aktiv. Man hat damit also quasi genau die Funktion die ein Loopback Interface auf einem Router hat.
Damit schafft man also eine Routing Redundanz nicht nur des Interfaces sondern auch des WG Prozesses. Win Win also...
Damit hat man immer konstanten Traffic durch den dpinger.
Der ist bei dynamischem Routing eher kontraproduktiv und sollte immer deaktiviert werden. Bei OPNsense ist dieses unsägliche "Gateway Monitoring" glücklicherweise im Default deaktiviert. Bei der pfSense muss man das leider immer händisch machen.In einem dynamischen Routing Umfeld ist ein "Gateway Monitoring" natürlich so oder so Quatsch, denn das macht das Routing Protokoll ja schon per se selber. Bei OSPF durch Multicasting Updates bei BGP durch die Peer Keepalives und Updates.
Besten Dank
Immer gerne! 😉 Dank aber auch an dich für ein spannendes Thread Thema. BGP über VPN (Wireguard) ist ja mal eine interessante Sache als das tägliche "Fritzbox geht nicht" Allerlei....unter Local angegeben und ich soll zusätzlich nochmal eine im selben Netz einsetzen?
Die Konfig ist in der Tat etwas komisch sowohl bei pfSense als auch OPNsense. Im WG GUI kann man eine Local IP einsetzen. Das ist in der Tat die Client IP die man gemeinhin im klassischen WG Setup ja immer unter[Interface]
Address = 100.64.65.62/27
konfiguriert.
Dadurch wird in den Senses erst das virtuelle WG Interface erzeugt und genau DAS weist man in beiden Senses dann immer unter dem "Interface Assignment" fest den Interfaces zu so das diese Interfaces in der Firewall Interface List auftauchen.
Diese Interfaces haben dann üblicherweise einen "OPTx" Namen den man dann anklickt und ihm einen aussagekräftigen Namen gibt z.B. wie "WGTUNx" in der oben geposteten Konfig.
Dann klickt man dort den Haken auf enable aktiviert so das Interface und setzt die IP Adressierung auf Static und weist diesem Interface nochmals exakt die gleiche IP zu die man im Local Interface schon zuvor gesetzt hat z.B. 100.64.65.62 mit einem /27er Prefix um beim Beispiel von oben zu bleiben.
Fertig! Damit ist das WG Interface dann korrekt gesetzt.
Klingt etwas doppelt gemoppelt aber nur so ist das WG Setup richtig konfiguriert bei beiden Senses.
Achtung:
Das FW Regelwerk wird ausschliesslich nur auf dem so erzeugten WG Interface aktiviert und nicht auf dem System angelegten Interface (Wireguard Group Tab) was in der Regelübersicht auftaucht. Das bleibt vollkommen unberührt. Das ist sehr wichtig weil nur so über diese Interface Regeln sichergestellt ist das WG Traffic immer aus dem gleichen Interface ausgesendet wird was beim Group Tab nicht der Fall ist. Ohne würde return Traffic dem Default Gateway folgen.
Gut, bei dynamischem Routing jetzt nicht kriegsentscheident beim reinen Cryptokey Routing aber schon!
Unter allowed IPs entsprechend die range angeben.
Nein, das muss er nicht, denn Kollege @Fenris14 macht dynamisches Routing mit BGP und hat im Peer Setup Redirect 0.0.0.0/0 eingestellt ohne Übernahme in die Routing Table. Das erledigt dann sein FRR Package mit BGP. 😉
Zusammenfassend kann sagen das es ohne Interface-Zuweisung anfangs zwar funktioniert, aber werden irgendwo Interface-Änderungen gemacht oder Firewall Reloads etc. mit Apply gemacht kommt es früher oder später ohne Zuweisung von WG zu definierten Interfaces dazu, dass die Wireguard-Interface-Routen für das Transfernetz teilweise in der Routing-Tabelle verloren gehen (Eigenheit bei OPNSense)! Also besser gleich, wie @aqui und ich hier schon mehrfach empfohlen haben, gleich Interface zuweisen und die feste IP dort hinterlegen dann ist es ein definierter Zustand und auch zuverlässig nutzbar!
Wie erwartet 👍
👍👏
Diese "WG Eigenheiten" im Setup hat analog auch die pfSense. Wenn man sie aber beachtet, alles kein Thema! 😉
Übrigens rennt auch die BGP Redundanz mit dem o.a. Design fehlerlos.
Hier müsste man sich fragen ob man mit OSPF als Routing Protokoll nicht besser fährt weil es einfacher im Setup und im Management ist.
Aber das ist wie immer eine Frage der Skalierung und hängt davon ab wieviele externe Geräte auf die beiden Core Firewalls terminieren.
Diese "WG Eigenheiten" im Setup hat analog auch die pfSense. Wenn man sie aber beachtet, alles kein Thema! 😉
Übrigens rennt auch die BGP Redundanz mit dem o.a. Design fehlerlos.
Hier müsste man sich fragen ob man mit OSPF als Routing Protokoll nicht besser fährt weil es einfacher im Setup und im Management ist.
Aber das ist wie immer eine Frage der Skalierung und hängt davon ab wieviele externe Geräte auf die beiden Core Firewalls terminieren.