28
PfSense Wireguard - Tunnel über spezifisches WAN Interface
Moin zusammen,
ich teste gerade ein Konstrukt mit zwei Wireguard Tunneln, welche jeweils über ein spezifisches WAN Gateway aufgebaut werden sollen.
Die Tunnel funktionieren auch. Allerdings immer über die default Routing Tabelle.
Wie möchte ich dies ändern. Ich habe für jede Zieladresse des jeweiligen Tunnel eine Floating Rule (Match) erstellt und darüber per Policy Based Route die entsprechende WAN Schnittstelle ausgewählt.
Leider greifen die Rules nicht wie gewünscht.
Hat jemand schonmal so etwas gebaut? Ich kann bei Wireguard ja leider keinen Tunnel an ein WAN Interface binden und muss daher das Routing anpassen.
Klar, als Alternative kann ich das ganze auch per IPsec bauen. Möchte ich hier aber nicht.
Damit wäre das ganze einfach zu bewerkstelligen. WG biete in meinem Scenario allerdings Vorteile. Wobei ich auch noch nicht weiß ob das Routing mit zwei identischen Wegen klar kommt. Das soll das Testscenario im Anschluss zeigen wenn die Tunnel jeweils korrekt gebunden sind.
Hier hat jemand quasi das gleiche Versucht:
https://forum.netgate.com/topic/169466/multi-wan-multi-tunnels-peers-wir ...
Das ganze ist etwas kompliziert zu beschreiben.
Vielleicht bau ich später mal ein Schaubild zusammen.
Gruß
Spirit
ich teste gerade ein Konstrukt mit zwei Wireguard Tunneln, welche jeweils über ein spezifisches WAN Gateway aufgebaut werden sollen.
Die Tunnel funktionieren auch. Allerdings immer über die default Routing Tabelle.
Wie möchte ich dies ändern. Ich habe für jede Zieladresse des jeweiligen Tunnel eine Floating Rule (Match) erstellt und darüber per Policy Based Route die entsprechende WAN Schnittstelle ausgewählt.
Leider greifen die Rules nicht wie gewünscht.
Hat jemand schonmal so etwas gebaut? Ich kann bei Wireguard ja leider keinen Tunnel an ein WAN Interface binden und muss daher das Routing anpassen.
Klar, als Alternative kann ich das ganze auch per IPsec bauen. Möchte ich hier aber nicht.
Damit wäre das ganze einfach zu bewerkstelligen. WG biete in meinem Scenario allerdings Vorteile. Wobei ich auch noch nicht weiß ob das Routing mit zwei identischen Wegen klar kommt. Das soll das Testscenario im Anschluss zeigen wenn die Tunnel jeweils korrekt gebunden sind.
Hier hat jemand quasi das gleiche Versucht:
https://forum.netgate.com/topic/169466/multi-wan-multi-tunnels-peers-wir ...
Das ganze ist etwas kompliziert zu beschreiben.
Vielleicht bau ich später mal ein Schaubild zusammen.
Gruß
Spirit
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7131371480
Url: https://administrator.de/forum/pfsense-wireguard-tunnel-ueber-spezifisches-wan-interface-7131371480.html
Ausgedruckt am: 24.12.2024 um 18:12 Uhr
28 Kommentare
Neuester Kommentar
Oft wird vergessen das WG Tunnelinterface an sich und seine feste, statische IP im Setup zuzuweisen wie es z.B. HIER am Beispiel der OPNsense erklärt ist. Für die pfSense gilt exakt das gleiche Setup!
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/assign.html
Es ist also wichtig das Tunnel Interface über das Interface Assignment hinzuzufügen und dann eine statische IP zu setzen.
Das Ruleset wird dann NUR auf diesem definierten Tunnelinterface gemacht nicht auf dem den das System automatisch erstellt!
Das System generierte Interface muss immer leer bleiben!
Das kann ggf. ein möglicher Grund sein warum die Policy Regeln nicht greifen.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/assign.html
Es ist also wichtig das Tunnel Interface über das Interface Assignment hinzuzufügen und dann eine statische IP zu setzen.
Das Ruleset wird dann NUR auf diesem definierten Tunnelinterface gemacht nicht auf dem den das System automatisch erstellt!
Das System generierte Interface muss immer leer bleiben!
Das kann ggf. ein möglicher Grund sein warum die Policy Regeln nicht greifen.
Hey aqui,
das ist soweit klar. Ich möchte allerdings für jeden WG Tunnel ein spezifisches WAN Interface nutzen.
Dafür habe ich für jeden Tunnel eine eigene Zieladresse auf der Gegenstelle welche per Floating Rule über ein spezifisches WAN Interface laufen soll.
Das Thema bezüglich Routing über den Tunnel kommt erst im Anschluss.
Das ganze möchte jedoch noch nicht greifen.
das ist soweit klar. Ich möchte allerdings für jeden WG Tunnel ein spezifisches WAN Interface nutzen.
Dafür habe ich für jeden Tunnel eine eigene Zieladresse auf der Gegenstelle welche per Floating Rule über ein spezifisches WAN Interface laufen soll.
Das Thema bezüglich Routing über den Tunnel kommt erst im Anschluss.
Das ganze möchte jedoch noch nicht greifen.
Setz doch einfach ne statische Route für den Wireguard Endpoint als /32er Ziel und mit dem passenden Gateway als Nexthop. Feddisch.
Gruß
Gruß
Zitat von @7010350221:
Setz doch einfach ne statische Route für den Wireguard Endpoint als /32er Ziel und mit dem passenden Gateway als Nexthop. Feddisch.
Gruß
Setz doch einfach ne statische Route für den Wireguard Endpoint als /32er Ziel und mit dem passenden Gateway als Nexthop. Feddisch.
Gruß
Auf dem WG Interface wird mir das wohl nichts bringen.
Aber als statische Route auf der default Routing Table müsste das tatsächlich klappen da diese eine höhere prio bekommt 🤔
Zitat von @Spirit-of-Eli
Aber als statische Route auf der default Routing Table müsste das tatsächlich klappen da diese eine höhere prio bekommt 🤔
Genau das meinte ich. Das klappt auf jeden Fall, da spezifischere Routen immer Vorrang in der RT haben...Aber als statische Route auf der default Routing Table müsste das tatsächlich klappen da diese eine höhere prio bekommt 🤔
Zitat von @7010350221:
Zitat von @Spirit-of-Eli
Aber als statische Route auf der default Routing Table müsste das tatsächlich klappen da diese eine höhere prio bekommt 🤔
Genau das meinte ich. Das klappt auf jeden Fall, da spezifischere Routen immer Vorrang in der RT haben...Aber als statische Route auf der default Routing Table müsste das tatsächlich klappen da diese eine höhere prio bekommt 🤔
Ja stimmt, Sorry. Ich habe das falsch gelesen.
Im Grunde ist das ganze Konstrukt allerdings eh wieder hinfällig da ich das Routing über die beiden Tunnel nicht dynamisch gestallten kann. Ich muss zwingend mit statischen Routen in und eben auch Rückrouten arbeiten.
Daher kann ich die Routing Entscheidung nicht per GW-Group fahren. Somit funktioniert das Setup nicht mit zwei WG Tunneln. Sehr schade.
Rückrouten ja nicht, denn die werden ja durch die Absender IP der Tunnel Source immer vorgegeben. Ein Paket was mit WAN-1 Source IP gesendet würde kann vom Ziel niemals eine Antwort an WAN-2 bekommen.
Man müsste verstehen warum die Policy nicht greift wenn du in einer Balancing Policy fest definierst das Tunnle 1 Destination IP immer fest über WAN-1 rennen soll und Tunnel 2 Destination IP immer fest über WAN-2.
Für alle Anwendungen funktioniert das ja fehlerlos. Nur mit dem Unterschied das die Balancing Policy dann vermutlich nur auf die Forwarding Chain wirkt, also geroutete Pakete und nicht auf die Outbound Chain also Pakete die die FW als Source selber sendet.
Aber mal ganz abgesehen davon... Was für OpenVPN gilt sollte eigentlich auch analog für WG gelten da beide SSL basierte VPNs sind.
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/multi-wan.html
Zitat: "...will work properly on all WANs and respond back using the address clients expect."
Sprich wenn die Firewall als reiner VPN Responder arbeitet kommt sie auch immer mit der WAN IP zurück die von extern (Client, Initiator) angesprochen wird, was ja auch so sein muss.
Wenn du also den WG Server auf der pfSense als reinen Responder laufen lässt sollte es auch immer ohne jegliche Policy und statische Routen out of the Box funktionieren! Du bestimmst dann quasi immer mit dem Client über welchen WAN Port der Tunnel aufgebaut wird.
Man müsste verstehen warum die Policy nicht greift wenn du in einer Balancing Policy fest definierst das Tunnle 1 Destination IP immer fest über WAN-1 rennen soll und Tunnel 2 Destination IP immer fest über WAN-2.
Für alle Anwendungen funktioniert das ja fehlerlos. Nur mit dem Unterschied das die Balancing Policy dann vermutlich nur auf die Forwarding Chain wirkt, also geroutete Pakete und nicht auf die Outbound Chain also Pakete die die FW als Source selber sendet.
Aber mal ganz abgesehen davon... Was für OpenVPN gilt sollte eigentlich auch analog für WG gelten da beide SSL basierte VPNs sind.
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/multi-wan.html
Zitat: "...will work properly on all WANs and respond back using the address clients expect."
Sprich wenn die Firewall als reiner VPN Responder arbeitet kommt sie auch immer mit der WAN IP zurück die von extern (Client, Initiator) angesprochen wird, was ja auch so sein muss.
Wenn du also den WG Server auf der pfSense als reinen Responder laufen lässt sollte es auch immer ohne jegliche Policy und statische Routen out of the Box funktionieren! Du bestimmst dann quasi immer mit dem Client über welchen WAN Port der Tunnel aufgebaut wird.
Die Transfer Einträge im WG Peer reichen definitiv nicht.
Ich muss für spezifische Netze die z.b. an der entfernten Sense anliegen definitiv statische Routen setzen. Das gleich gilt für die andere Richtung. Also quasi den Rückweg da ansonsten ebenfalls keine Kommunikation möglich ist.
Eine für mich völlig unverständliche Ausnahme ist das scenario mit force tunneling (0.0.0.0/0). An der Stelle muss keine zusätzliche Route angelegt werden. Allerdings reicht dies auch nicht um an die lokalen Netze der entfernten Sense zu kommen.
Irgend wo ist das bei WG noch der Wurm drin. Abgesehen davon ist das ja auch nach wie vor nicht die neueste Version da das Package auf der Sense immer noch nicht aktualisiert wurde.
Bei OVPN oder IPsec im VTI Mode wäre ein simples Routing an das entsprechende GW möglich. Alles per Policy. Bei der WG implementation funktioniert es nicht.
Ich muss für spezifische Netze die z.b. an der entfernten Sense anliegen definitiv statische Routen setzen. Das gleich gilt für die andere Richtung. Also quasi den Rückweg da ansonsten ebenfalls keine Kommunikation möglich ist.
Eine für mich völlig unverständliche Ausnahme ist das scenario mit force tunneling (0.0.0.0/0). An der Stelle muss keine zusätzliche Route angelegt werden. Allerdings reicht dies auch nicht um an die lokalen Netze der entfernten Sense zu kommen.
Irgend wo ist das bei WG noch der Wurm drin. Abgesehen davon ist das ja auch nach wie vor nicht die neueste Version da das Package auf der Sense immer noch nicht aktualisiert wurde.
Bei OVPN oder IPsec im VTI Mode wäre ein simples Routing an das entsprechende GW möglich. Alles per Policy. Bei der WG implementation funktioniert es nicht.
@aqui, hast du gerade einen WG Tunnel zwischen zwei PfSense Systemen aktiv? Ich komme definitiv nicht um statische Routen umher. Keine Chance.
Jau, hab ich und funktioniert fehlerlos.
Allerdings musst du genau definieren WAS du mit "statische Routen" hier meinst. Vermutlich nur das Routing der internen IP Netze über den Tunnel, richtig?
Eigentlich betrifft das in der Tat lediglich das Tunnel interne Routing, da die pfSense und auch die OPNsense kein dynamisches Crypto Routing supporten, sprich also die automatische Übernahme in die Routing Tabelle wie man es bei Linux oder Winblows Clients kennt. Eine statische Route und auch ein statisches Gateway im internen Tunnelnetz anzulegen ist deshalb immer Pflicht.
Ausnahme natürlich man bedient sich dynamischer Routing Protokolle wie RIPv2, OSPF oder BGP die das dann vollautomatisch ohen was Statisches erledigen:
Merkzettel: VPN Installation mit Wireguard
Verständnisfrage zu OSPF-Routing bei MikroTik-Routern (RouterOS)
OPNsense mehrere Wireguard Interfaces mit Split-Tunnel
Statisches Routing für die Tunnelverbindung selber ist normal nicht erforderlich. Ggf. mit der Ausnahme der Hostroute oben um in Dual WAN Szenarien den Ausgangsport zu erzwingen. Allerdings ist das auch im Responder Mode nicht erforderlich.
Allerdings musst du genau definieren WAS du mit "statische Routen" hier meinst. Vermutlich nur das Routing der internen IP Netze über den Tunnel, richtig?
Eigentlich betrifft das in der Tat lediglich das Tunnel interne Routing, da die pfSense und auch die OPNsense kein dynamisches Crypto Routing supporten, sprich also die automatische Übernahme in die Routing Tabelle wie man es bei Linux oder Winblows Clients kennt. Eine statische Route und auch ein statisches Gateway im internen Tunnelnetz anzulegen ist deshalb immer Pflicht.
Ausnahme natürlich man bedient sich dynamischer Routing Protokolle wie RIPv2, OSPF oder BGP die das dann vollautomatisch ohen was Statisches erledigen:
Merkzettel: VPN Installation mit Wireguard
Verständnisfrage zu OSPF-Routing bei MikroTik-Routern (RouterOS)
OPNsense mehrere Wireguard Interfaces mit Split-Tunnel
Statisches Routing für die Tunnelverbindung selber ist normal nicht erforderlich. Ggf. mit der Ausnahme der Hostroute oben um in Dual WAN Szenarien den Ausgangsport zu erzwingen. Allerdings ist das auch im Responder Mode nicht erforderlich.
Kurz um, dass Routing in den Tunnel lässt sich nicht vollständig per Policy based Route definieren. Korrekt?
Denn nur dann ließen sich Gateway Gruppen nutzen.
Denn nur dann ließen sich Gateway Gruppen nutzen.
Hier mal ein Beispiel für Sense A und der Peer Eintrag zu Seite B:
1. LAN Subnetz auf Seite B
2. Transfer Netz im WG Tunnel
3. Force Tunneling Route da an der Stelle für spezifische Clients auf Sense A darüber der Traffic ins Internet abgewickelt wird.
Mindestens diese statische Route auf Sense A brauche ich um das LAN Subnetz auf Sense B zu erreichen:
Auf Sense B ist das Pendant zu dem ganzen konfiguriert. Jedoch brauche ich eine statische Route für meine LAN Subnetze auf Sense A wie folgt per Supernetting:
Das Routing per default Route über Sense B funktioniert solange wie diese eben weiß wie Sie die LAN Clients Sense A erreicht. Soweit so logisch.
Ich muss diese Einträge aber dynamisch über zwei verschiedene Wege, in dem Fall zwei Tunnel schalten können.
Das heißt, dass GW für diese Routen muss in dem ganzen Scenario geändert werden.
Wobei, je länger ich gerade drüber nachdenke und das ganze hier nieder schreibe komme ich zu dem Schluss, dass ganze lässt sich ja nur über OSPF oder BGP lösen.
Das Ursprüngliche Problem lässt sich mit den statischen Routen pro Ziel Adresse (Sense B ist ohne hin nur Responder) definitiv lösen.
Nachtrag:
Ich habe zum testen auf Sense A mal die statische Route durch eine PBR Rule ersetzt. Das ganze funktioniert wie erwartet nicht:
2. Transfer Netz im WG Tunnel
3. Force Tunneling Route da an der Stelle für spezifische Clients auf Sense A darüber der Traffic ins Internet abgewickelt wird.
Mindestens diese statische Route auf Sense A brauche ich um das LAN Subnetz auf Sense B zu erreichen:
Auf Sense B ist das Pendant zu dem ganzen konfiguriert. Jedoch brauche ich eine statische Route für meine LAN Subnetze auf Sense A wie folgt per Supernetting:
Das Routing per default Route über Sense B funktioniert solange wie diese eben weiß wie Sie die LAN Clients Sense A erreicht. Soweit so logisch.
Ich muss diese Einträge aber dynamisch über zwei verschiedene Wege, in dem Fall zwei Tunnel schalten können.
Das heißt, dass GW für diese Routen muss in dem ganzen Scenario geändert werden.
Wobei, je länger ich gerade drüber nachdenke und das ganze hier nieder schreibe komme ich zu dem Schluss, dass ganze lässt sich ja nur über OSPF oder BGP lösen.
Das Ursprüngliche Problem lässt sich mit den statischen Routen pro Ziel Adresse (Sense B ist ohne hin nur Responder) definitiv lösen.
Nachtrag:
Ich habe zum testen auf Sense A mal die statische Route durch eine PBR Rule ersetzt. Das ganze funktioniert wie erwartet nicht:
Kurz um, dass Routing in den Tunnel lässt sich nicht vollständig per Policy based Route definieren. Korrekt?
Nicht das du hier jetzt was verwechselst. Das Routing der internen IP Netze hat nichts mit dem externen Routing der Tunnel Endpoints zu tun. Das sind 2 verschiedene Baustellen!Hier mal ein Beispiel für Sense A und der Peer Eintrag zu Seite B:
Da hast du schon einen gravierenden Fehler gemacht!!!Du hast hier ein Gateway Redirect Setup (0.0.0.0/0 "3.") mit einem Split Tunneling Setup gemixt. Sowas geht per se gar nicht und damit scheitert das VPN schon im Ansatz!
Du musst dich hier entscheiden: Entweder Redirect oder Split Tunneling. Beides gemixt geht definitiv nicht und wäre abgesehen davon auch unsinnig! Bei einem Redirect müsste man ja niemals mehr dedizierte Netze definieren wenn eh alles in den Tunnel geroutet wird. Wäre ja überflüssig.
Das WG Tutorial weist HIER in aller Deutlichkeit darauf hin! Diese Logik gilt im Übrigen für alle VPN Installationen.
Wenn du mit Split Tunneling arbeitest kannst du auch an deinem Screenshot sehen das du mit falschen Subnetzmasken ("2.") gearbeitet hast bei den Allowed IPs. Der Server selber bzw. die Clients hat intern immer eine /32er Hostmaske und das jeweils remote Netz dann seine Netzwerk Maske in deinem Falle die /24.
Du hast hier am internen Netz aber auch fälschlicherweise eine /24er Maske eingetragen, damit ist dann das interne Routing nicht mehr eindeutig.
Ein sauberes pfSense Setup im Split Tunneling Mode mit korrekten Masken kannst du z.B. HIER sehen. (Man beachte die Masken unter den "AllowedIPs"!)
Ich muss diese Einträge aber dynamisch über zwei verschiedene Wege, in dem Fall zwei Tunnel schalten können.
Wie ist das genau gemeint?? Als Redundanz bzw. Failover für die internen IP Netze? Sprich ein Port fällt aus und du willst dynamisch über einen anderen Port und auch ein anderes internes WG Netz redundant routen?Dann solltest du in der Tat besser dynamisch routen z.B. mit RIPv2 oder OSPF. Das ist zwar etwas mehr Konfig Aufwand aber im Endeffekt klappt das Failover damit dann vollständig dynamisch ohne das du riesige Klimmzüge mit einem statischen Routing Setup und unterschiedlichen Metriken usw. machen musst.
Ggf. machst du mal eine kurze Skizze vom geplanten Setup damit wir alle den gleichen Wissenstand haben und das Ziel kennen. Der BGP Thread des Kollegen @Fenris14 beschreibt grundsätzlich so ein Setup wenn auch mit größerem Aufwand durch doppelte FW Core Systeme. Bei dir wäre das, wenn man dein Design richtig versteht, etwas einfacher gestrickt.
Ich antworte nochmal ausführlich sobald ich Zeit habe mich wieder dran zu setzen.
Im Prinzip habe ich versucht ein Konstrukt wie das Fortinet VPN mit dem Fabric Management nachzubauen. Oder das Loadbalacing bei Barracuda über mehrere VPN Wege.
Das ganze ist hier allerdings nur für meine Heimanbindung gedacht da ich gerade mit so einer LTE Hybrid Krücke und einer zweiten LTE Anbindung herum Ochse.
In beiden Beispielen Klicke ich mir einfach einen weiteren Tunnel dazu und definiere die Endpunkte. Naja, die Preise haben schon ihre Gründe. Wahrscheinlich bin ich etwas verwöhnt 😂
Das Ausgangsproblem war der hängenbleibende Tunnel auf WAN2 wenn WAN1 weg bricht. Darauf hin der Gedanke schlicht zwei Tunnel auf zu bauen und nur das Routing zu switchen.
Das ist aber alles nicht lebenswichtig und wird sich mit der Glasfaser Anbindung hier eh erledigen.
Im Prinzip habe ich versucht ein Konstrukt wie das Fortinet VPN mit dem Fabric Management nachzubauen. Oder das Loadbalacing bei Barracuda über mehrere VPN Wege.
Das ganze ist hier allerdings nur für meine Heimanbindung gedacht da ich gerade mit so einer LTE Hybrid Krücke und einer zweiten LTE Anbindung herum Ochse.
In beiden Beispielen Klicke ich mir einfach einen weiteren Tunnel dazu und definiere die Endpunkte. Naja, die Preise haben schon ihre Gründe. Wahrscheinlich bin ich etwas verwöhnt 😂
Das Ausgangsproblem war der hängenbleibende Tunnel auf WAN2 wenn WAN1 weg bricht. Darauf hin der Gedanke schlicht zwei Tunnel auf zu bauen und nur das Routing zu switchen.
Das ist aber alles nicht lebenswichtig und wird sich mit der Glasfaser Anbindung hier eh erledigen.
1
Generell ist das genau der richtige Weg für redundante VPN Anbindungen und so ein Konstrukt funktioniert auch fehlerlos mit Wireguard.
Wenn du allerdings Volumina abhängige Kosten hast mit Mobilfunknetz Anbindungen musst du beim Einsatz von dynamischen Routing Protokollen etwas aufpassen, denn die verursachen durch Keepalives und Routing Updates natürlich immer eine, wenn auch nur geringe, Grundlast an Traffic.
Das gleiche gilt natürlich auch für statische Tunnel wenn diese mit einem Peer Keepalive betrieben werden.
Wenn du allerdings Volumina abhängige Kosten hast mit Mobilfunknetz Anbindungen musst du beim Einsatz von dynamischen Routing Protokollen etwas aufpassen, denn die verursachen durch Keepalives und Routing Updates natürlich immer eine, wenn auch nur geringe, Grundlast an Traffic.
Das gleiche gilt natürlich auch für statische Tunnel wenn diese mit einem Peer Keepalive betrieben werden.
Das ist kein Problem.
Beide Anbindungen sind unlimited.
Ich denke am Wochende habe ich wieder Zeit mich damit nochmal auseinander zu setzen.
Ich habe das ganze auch als besteht pratice im Kopf.
Beide Anbindungen sind unlimited.
Ich denke am Wochende habe ich wieder Zeit mich damit nochmal auseinander zu setzen.
Ich habe das ganze auch als besteht pratice im Kopf.
Beide Anbindungen sind unlimited.
Perfekt! 👍 Dann...go for it! 😉
Das Setup mit redundanten WG-VPNs machen wir wie folgt:
- Auf beiden Seiten werden 2 öffentliche IPs benötigt.
- Es müssen zwei WireGuard Configs angelegt werden, mit je einem Peer. Für jeden Endpoint ein eigenes Interface.
- Die Endpoint-IPs der Gegenseite werden mit statischen Routen an das entsprechende WAN Gateway gebunden.
- Jeder Tunnel erhält ein internes Transfer-Netz /30.
- Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
- Für das Routing wird ein dynamisches Protocol verwendet. Z.b. BGP oder OSPF.
- Auf beiden Seiten werden 2 öffentliche IPs benötigt.
- Es müssen zwei WireGuard Configs angelegt werden, mit je einem Peer. Für jeden Endpoint ein eigenes Interface.
- Die Endpoint-IPs der Gegenseite werden mit statischen Routen an das entsprechende WAN Gateway gebunden.
- Jeder Tunnel erhält ein internes Transfer-Netz /30.
- Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
- Für das Routing wird ein dynamisches Protocol verwendet. Z.b. BGP oder OSPF.
1Zitat von @QDaniel:
Das Setup mit redundanten WG-VPNs machen wir wie folgt:
- Auf beiden Seiten werden 2 öffentliche IPs benötigt.
- Es müssen zwei WireGuard Configs angelegt werden, mit je einem Peer. Für jeden Endpoint ein eigenes Interface.
- Die Endpoint-IPs der Gegenseite werden mit statischen Routen an das entsprechende WAN Gateway gebunden.
- Jeder Tunnel erhält ein internes Transfer-Netz /30.
- Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
- Für das Routing wird ein dynamisches Protocol verwendet. Z.b. BGP oder OSPF.
Das Setup mit redundanten WG-VPNs machen wir wie folgt:
- Auf beiden Seiten werden 2 öffentliche IPs benötigt.
- Es müssen zwei WireGuard Configs angelegt werden, mit je einem Peer. Für jeden Endpoint ein eigenes Interface.
- Die Endpoint-IPs der Gegenseite werden mit statischen Routen an das entsprechende WAN Gateway gebunden.
- Jeder Tunnel erhält ein internes Transfer-Netz /30.
- Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
- Für das Routing wird ein dynamisches Protocol verwendet. Z.b. BGP oder OSPF.
Danke, das entspricht auch dem Idealfall welchen ich im Kopf hatte. Ohne die von mir abgerissenen Fälle mit Fortinet Barracuda hätte ich es auch so gebaut.
Ich habe gerade überlegt. Da ich hier auf meiner Home Seite keine zwei public IPs habe müsste es auch zwei response only Tunnel klappen.
Ich baue das ganze wahrscheinlich am Wochenende mit BGP auf und schau mal.
Im Endeffekt ist es hier ja nur eine Spielerei für ein dummes Problem.
Zitat von @Spirit-of-Eli:
Ich habe gerade überlegt. Da ich hier auf meiner Home Seite keine zwei public IPs habe müsste es auch zwei response only Tunnel klappen.
Ich habe gerade überlegt. Da ich hier auf meiner Home Seite keine zwei public IPs habe müsste es auch zwei response only Tunnel klappen.
Das geht nur, wenn die Gegenseite "schlau genug ist" und die Verbindungen über das gleiche Gateway sendet wo es angekommen ist.
1Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
M.W. gibt es diesen (in einem dynamischen Routing Umfeld richtigen) Schalter nur bei der OPNsense oder ich habe ihn bei der pfSense übersehen. Zitat von @aqui:
Die WG Peers bekommen je Table = Off (Deaktiviert das Routing der AllowedIPs ) und AllowedIPs = 0.0.0.0/0 ,::/0.
M.W. gibt es diesen (in einem dynamischen Routing Umfeld richtigen) Schalter nur bei der OPNsense oder ich habe ihn bei der pfSense übersehen. Ich glaube auch. Vermutlich kommt das erst wenn endlich die überarbeitete saubere Version raus kommt. Aber da ist die PfSense ja leider lange hinter her obwohl das Package für FreeBSD schon länger existiert.
Ich meine aber da die pfSense generell eh keinerlei Wireguard Crypto Routings dynamisch ausführt das es bei ihr dann so oder so Default ist das bei WG generell nichts automatisch in die Routing Tabelle übernommen wird.
Bei der pfSense muss ohne dynamisches Routing Protokoll ja so oder so jedes remote Netz statisch geroutet werden. Das gilt sehr wahrscheinlich dann auch für die Default Route.
In sofern ist es dann eh auf der pfSense "Default" so das es dann auch fehlerlos klappen sollte ohne diesen Schalter im Setup.
Die 0.0.0.0 sorgt dann nur dafür das alles in den Tunnel geht und das dynamische Protokoll händelt dann automatishc die Gateways wie es das ja soll.
Das o.a. beschriebene einfache Setup für BGP bestätigt das. Hier sind allerdings noch die übertragenen IP Netze alle mit einer Summary Route statisch angegeben. Das kann man sich mit dem 0.0.0.0/0 Gateway Redirect und einem dynamischen Routing Protokoll dann ganz sicher sparen. Kann ich auch nochmal testen...
Bei der pfSense muss ohne dynamisches Routing Protokoll ja so oder so jedes remote Netz statisch geroutet werden. Das gilt sehr wahrscheinlich dann auch für die Default Route.
In sofern ist es dann eh auf der pfSense "Default" so das es dann auch fehlerlos klappen sollte ohne diesen Schalter im Setup.
Die 0.0.0.0 sorgt dann nur dafür das alles in den Tunnel geht und das dynamische Protokoll händelt dann automatishc die Gateways wie es das ja soll.
Das o.a. beschriebene einfache Setup für BGP bestätigt das. Hier sind allerdings noch die übertragenen IP Netze alle mit einer Summary Route statisch angegeben. Das kann man sich mit dem 0.0.0.0/0 Gateway Redirect und einem dynamischen Routing Protokoll dann ganz sicher sparen. Kann ich auch nochmal testen...
Ja wir machen das unter OpnSense da muss das Routing deaktiviert werden. Wenn pfSense nicht automatisch Routen anlegt ist das auch ok. Mikrotik z.b. legt auch keine Routen selber an.
1
Ich habe es jetzt mit OSPF am laufen. Ein IPsec Tunnel funktioniert als haupt Weg und der Wireguard Tunnel als Backup.
War nicht ganz trivial zumal das Routing im WG Tunnel sich ja nach wie vor nicht deaktivieren lässt. (hier klappt es wieder nur wenn unter allowed IP die 0.0.0.0/0 drin steht)
Außerdem musste ich mich etwas in OSPF rein fuchsen.
Mit aktiviertem "gateway flush on failer" klappt auch der Übergang in beide Richtung wenn eine Leitung ausfällt.
Um den Traffic spezifisch per PBR über den Tunnel zu schieben müssen die Prioritäten bei der Gateway Group sowie unter OSPF identisch sein. Sonst führt das ganze unweigerlich zum Routing missmatch.
Ich mache den Thread damit zu.
Übrigens klappt das ganze wunderbar mit drei public Adressen solange das Ziel statisch ist.
War nicht ganz trivial zumal das Routing im WG Tunnel sich ja nach wie vor nicht deaktivieren lässt. (hier klappt es wieder nur wenn unter allowed IP die 0.0.0.0/0 drin steht)
Außerdem musste ich mich etwas in OSPF rein fuchsen.
Mit aktiviertem "gateway flush on failer" klappt auch der Übergang in beide Richtung wenn eine Leitung ausfällt.
Um den Traffic spezifisch per PBR über den Tunnel zu schieben müssen die Prioritäten bei der Gateway Group sowie unter OSPF identisch sein. Sonst führt das ganze unweigerlich zum Routing missmatch.
Ich mache den Thread damit zu.
Übrigens klappt das ganze wunderbar mit drei public Adressen solange das Ziel statisch ist.
Glückwunsch! 👏 👍
Dieser Thread zeigt es am Beispiel mit BGP.
zumal das Routing im WG Tunnel sich ja nach wie vor nicht deaktivieren lässt.
Das ist zumindestens für die OPNsense nicht ganz richtig. Dort kann man das automatische WG Routing auch komplett deaktivieren und muss man sogar wenn man mit OSPF oder anderen dynamischen Routing Protokollen routet, denn dann soll natürlich OSPF die Routen propagieren und nicht das WG interne Cryptokey Routing. Dieser Thread zeigt es am Beispiel mit BGP.
Das was du ansprichst ist halt der Schönheitsfehler in dem Konstrukt. Komischerweise läuft es auch hier wieder mit Supernetting im WG Peer bei "Allowed Adresses" genau so wie eben mit zusätzlicher Default Rule.
Ich habe auch schon wieder drüber nachgedacht auf OPNsense zu wechseln, aber ich habe hier viel zu viel gebastelt.
Die Sense läuft mit 30 VLans, 2x VPN und gut 200 fw regeln. Dazu service Konfigs usw.
Ich habe auch schon wieder drüber nachgedacht auf OPNsense zu wechseln, aber ich habe hier viel zu viel gebastelt.
Die Sense läuft mit 30 VLans, 2x VPN und gut 200 fw regeln. Dazu service Konfigs usw.
Oha, ja.... Never touch a running system. 😉
Man muss aber sagen das dies zumindestens bei der OPNsense im WG Setup deutlich besser gelöst ist mit dem abschaltbaren Cryptokey Routing. Bei Mikrotik Routern ist es ja genau so.
Für ein Umfeld mit dynamischen Routing Protokollen schafft das abschaltbare Cryptokey Routing ein erheblich besseres Setup aus Konfig Sicht.
Man muss aber sagen das dies zumindestens bei der OPNsense im WG Setup deutlich besser gelöst ist mit dem abschaltbaren Cryptokey Routing. Bei Mikrotik Routern ist es ja genau so.
Für ein Umfeld mit dynamischen Routing Protokollen schafft das abschaltbare Cryptokey Routing ein erheblich besseres Setup aus Konfig Sicht.
1
