71
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
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: 6656932323
Url: https://administrator.de/contentid/6656932323
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
71 Kommentare
Neuester Kommentar
Moin,
nun du möchtest einen "Split-Tunnel" und setzt eine default Route 0.0.0.0/0?
Den Widerspruch erkennt du, oder?
Gruß
Spirit
nun du möchtest einen "Split-Tunnel" und setzt eine default Route 0.0.0.0/0?
Den Widerspruch erkennt du, oder?
Gruß
Spirit
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/
Ähnlich wie hier:
https://www.klehr.de/michael/opnsense-s2s-mit-wireguard-frr-und-ospf/
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.
Zitat von @Spirit-of-Eli:
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.
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.
Ich habe aber zumindest mal erwähnt das ich "Disable Routes" aktiviert habe, siehe hier:
Jeweils wg1 und wg2 als Interface. Bei beiden ist "Disable Routes" der Haken gesetzt.
Das ich dynamisches Routing verwenden will, habe ich tatsächlich nirgends geschrieben. Aber wäre im erwähnten Phänomen aus meiner Sicht sowieso erstmal irrelevant, da ja bei der Verwendung von zwei Mal der gleichen Subnetzmaske aber für zwei unterschiedlichen Netzen nicht mal Layer2-Verbindung zustande kommt.
Ansonsten ja, es ist möglich, da bisher noch kein Peering mit Wireguard nativ implementiert wurde. Zumindest unter FreeBSD/OPNsense lässt es noch auf sich warten.
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 ...
diesen Guide gefunden:
Beschreibt ja auch oben das hiesige WG Tutorial in einer laufenden Praxiskonfig.
Wenn ich ein zweites getrenntes Wireguard-Netzwerk aufziehen möchte, dann kann man doch von Instanzen sprechen oder nicht? Mit mehreren Instanzen für Ausfallsicherheit wäre doch möglich?! Ich will ja kein Point-to-Multipoint.
Was hätte dann der Einsatz von BGP für einen Sinn wenn ich dann trotzdem alle Netze eintragen muss? Dann kann ich ja gleich statische Routen verwenden. Es wird iBGP verwendet.
So sieht die Config von Wireguard aus:
Tunnel Address ist 192.168.100.110/24. Das ist das Interface was funktioniert. BGP Config per FRR:
Was hätte dann der Einsatz von BGP für einen Sinn wenn ich dann trotzdem alle Netze eintragen muss? Dann kann ich ja gleich statische Routen verwenden. Es wird iBGP verwendet.
So sieht die Config von Wireguard aus:
interface: wg1
public key: <pubkey>
private key: (hidden)
listening port: 55555
peer: <pubkey>
endpoint: 207.133.77.111:55555
allowed ips: 0.0.0.0/0
latest handshake: 43 seconds ago
transfer: 7.72 MiB received, 826.70 KiB sentTunnel Address ist 192.168.100.110/24. Das ist das Interface was funktioniert. BGP Config per FRR:
Current configuration:
!
frr version 7.5.1
frr defaults datacenter
hostname OPNsense0.Testus
log syslog notifications
!
router bgp 65111
bgp router-id 10.11.0.1
no bgp default ipv4-unicast
no bgp network import-check
neighbor 192.168.100.252 remote-as 65255
!
address-family ipv4 unicast
network 10.11.0.0/16
redistribute static
neighbor 192.168.100.252 activate
neighbor 192.168.100.252 next-hop-self
exit-address-family
!
address-family ipv6 unicast
redistribute static
exit-address-family
!
line vty
!
endMit 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...
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
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.
Auch hier auf beiden ein klassisches iBGP Standardsetup.
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.
Works as designed!! 👍 😉
Inhaltsverzeichnis
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.
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!! 👍 😉
Interessant. Ich meine, es ist ja nicht so das meine Variante nicht laufen würde. Es geht halt nur die zweite Instanz nicht.
Mal rein hypothetisch: Man hat zwei Peers als Hauptstandorte, beide haben jeweils zu allen anderen kleineren Standorten eine VPN-Verbindung (Mal völlig egal wie das im Detail jetzt aussehen würde) und betreiben vor Ort jeweils dynamisches Routing. Wenn einer dieser Hauptstandorte, durch was auch immer nun ausfällt, wäre es doch legitim den anderen Hauptstandort noch als weiteren Neighbor für BGP zu haben, oder nicht?
BTW: Will mal nicht ausschließen das ich einen groben Denkfehler im Bezug auf Wireguard habe, weil in 100 verschiedenen TUTs findest du 100 verschiedene Herangehensweisen. Bisher Privat nur kleinere 0815-Setups gemacht, das ging soweit ohne Probleme.
Ich werde das mal versuchen so umzusetzen wie du es geschrieben hast, dann mal sehen was passiert. Danke für deine Mühe.
Mal rein hypothetisch: Man hat zwei Peers als Hauptstandorte, beide haben jeweils zu allen anderen kleineren Standorten eine VPN-Verbindung (Mal völlig egal wie das im Detail jetzt aussehen würde) und betreiben vor Ort jeweils dynamisches Routing. Wenn einer dieser Hauptstandorte, durch was auch immer nun ausfällt, wäre es doch legitim den anderen Hauptstandort noch als weiteren Neighbor für BGP zu haben, oder nicht?
BTW: Will mal nicht ausschließen das ich einen groben Denkfehler im Bezug auf Wireguard habe, weil in 100 verschiedenen TUTs findest du 100 verschiedene Herangehensweisen. Bisher Privat nur kleinere 0815-Setups gemacht, das ging soweit ohne Probleme.
Ich werde das mal versuchen so umzusetzen wie du es geschrieben hast, dann mal sehen was passiert. Danke für deine Mühe.
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?
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.
Genau so meine ich das. Also wäre im Endeffekt einfach nur ein weiterer Endpoint zu konfigurieren, der den selben Tunnel verwendet nur eine andere IP, richtig?
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 @aqui:
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. 😉
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.
- 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. 😉
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.
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 2023Wireguard Settings
Routing-Table
Connectivity-Check zu den Peers.
Fazit: Arbeitet so wie erwartet einwandfrei! 👍
Cheers briggs
2Scheinbar 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.
Zitat von @6247018886:
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 :
Fazit: Arbeitet so wie erwartet einwandfrei! 👍
Cheers briggs
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 2023Wireguard Settings
Routing-Table
Connectivity-Check zu den Peers.
Fazit: Arbeitet so wie erwartet einwandfrei! 👍
Cheers briggs
Eben genau das funktioniert nicht bei mir. Ebenfalls 23.1.5_4 und sobald ich da einen zweiten Tunnel anlege und die Tunnel Address die selbe Subnetzmaske hat, kommt kein WG Handshake zustande.
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". 😉
So, ich habe das jetzt nochmal nachgebaut wie @6247018886 dies getan hat und wie ich es auch schon hatte. Leider aber immer noch nicht funktioniert. Die OPNsense ist in diesem Fall der Initiator:
Setze ich jetzt die Subnetzmaske aber so hier:
... funktioniert es. Was übersehe ich?
BTW: Wenn ich das wie im letzten Bild ohne Angabe von Subnetzmaske tätige, wird einfach pauschal die Subnetzmaske /8 hinterlegt. Der Tunnel ist dann auch funktional. Sobald ich wieder /24 Maske verwende, sehe ich auf dem WAN-Interface nicht mal mehr UDP-Traffic zum gegebenen Endpoint. Woran soll das liegen?
Setze ich jetzt die Subnetzmaske aber so hier:
... funktioniert es. Was übersehe ich?
BTW: Wenn ich das wie im letzten Bild ohne Angabe von Subnetzmaske tätige, wird einfach pauschal die Subnetzmaske /8 hinterlegt. Der Tunnel ist dann auch funktional. Sobald ich wieder /24 Maske verwende, sehe ich auf dem WAN-Interface nicht mal mehr UDP-Traffic zum gegebenen Endpoint. Woran soll das liegen?
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.
OPNsense WG IP Adresse (Peer1, WGTUN1) = 100.64.65.1 /27
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
Works as designed! 👍
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.
Inhaltsverzeichnis
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! 👍
Auf den beiden Endpunkten, bei dir Mikrotik und RasPI, setzen wir Hub and Spoke (Point-to-Multipoint) ein. Wenn ich den zweiten Tunnel allerdings als reinen Peer-to-Peer verwende, wo auf beiden Seiten "allowed-ips 0.0.0.0/0" steht... dann geht es auch mit der /24er Subnetzmaske. Aber dann auch nur wenn ich unter "Disable Routes" ein fiktives Gateway angebe. Wie es hier z.B. steht:
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.htm ...
Beide Interfaces sind zugewiesen und in der Firewall für das Interface einmal Scheunentor.
Hier hatte einmal jemand das selbe Problem, leider ist die einzige Antwort nicht sonderlich hilfreich:
https://community.serversideup.net/t/wireguard-opnsense-handshake-issues ...
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.htm ...
Beide Interfaces sind zugewiesen und in der Firewall für das Interface einmal Scheunentor.
Hier hatte einmal jemand das selbe Problem, leider ist die einzige Antwort nicht sonderlich hilfreich:
https://community.serversideup.net/t/wireguard-opnsense-handshake-issues ...
Im o.a. Setup sind derzeit /27er Masken eingestellt und die Allowed IPs sind mit einer /32 Hostmaske versehen.
Letzteres konfiguriere ich eben mal um auf 0.0.0.0/0 bei den Allowed IPs.
Routes sind in den Peer Definitionen der OPNsense Peers auf den MT und den RasPi disabled.
Letzteres konfiguriere ich eben mal um auf 0.0.0.0/0 bei den Allowed IPs.
Routes sind in den Peer Definitionen der OPNsense Peers auf den MT und den RasPi disabled.
Keine Ahnung. Jetzt falle ich langsam vom Glauben ab. Ich habe es exakt so wie du jetzt. Es geht nicht. Ich muss mir das zuhause nochmal nachbauen.
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..
Kommen bei dir denn nur die Peers nicht zustande oder kannst du schlicht und einfach die Peer Adressen nicht pingen.
Letzteres bedeutet dann häufig ein FW Regelproblem.
Letzteres bedeutet dann häufig ein FW Regelproblem.
Das reine WG Handshaking klappt schon nicht. Die Gegenseite ist eigentlich auch irrelevant erstmal, weil Layer2 schon nicht zustande kommt. Die OPNsense ist Initiator und soll sich verbinden, nicht anders herum. Die Gegenseite funktioniert ja auch, aber nur unter bestimmten Umständen, wenn ich sinnfreie Configs mache.
Ich habe exakt das selbe Problem bei zwei verschiedenen OPNsensen. Ein Tunnel läuft immer ohne Probleme, der zweite Streikt. Kann nur aktiviert werden, indem man die Subnetzmaske raus löscht aus der Tunnel Address oder ich auf reines Peering umstelle mit der Angabe eines fiktiven Gateways.
So sieht die Routing Table derzeit aus, wenn ich es exakt so habe wie @aqui
Ich habe exakt das selbe Problem bei zwei verschiedenen OPNsensen. Ein Tunnel läuft immer ohne Probleme, der zweite Streikt. Kann nur aktiviert werden, indem man die Subnetzmaske raus löscht aus der Tunnel Address oder ich auf reines Peering umstelle mit der Angabe eines fiktiven Gateways.
So sieht die Routing Table derzeit aus, wenn ich es exakt so habe wie @aqui
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 irgendwie fehlt mir eine Gehirnwindung um zu sehen wo das Problem liegt. Ich habe jetzt nochmal alles nachgebaut und versuche das in einer virtuellen Umgebung nachzustellen. Es scheitert am simplen Aufbau des WG Tunnel. Ich muss das mal für Begriffsstutzige wie mich aufdröseln...
Sieht jetzt so hier aus, schnell und dreckig:
Vor dem Erstellen des Tunnels können sich die OPNsense und der Debian Server sich gegenseitig anpingen. Das passt und klappt wunderbar. Config vom WG auf dem Debian:
Routing Table
OPNsense Local
OPNsense Endpoint
OPNsense Routing Table
Hier noch der Beweis das ich das Interface zugewiesen und auf dem WG_Interface jeglichen Traffic durch lasse... zusätzlich auch noch ein Pass für jeglichen Verkehr auf dem WAN-Interface für den WG-Port....
Und es funktioniert nicht. Langsam denke ich an eine Verschwörung.
Ich bin mir sicher das ich irgendwo einen kapitalen Denkfehler habe, aber ich sehe es nicht. Bestimmt irgendwas ganz banales. Eigenartig ist, das die OPNsense nicht mal versucht etwas an ihr Standard-Gateway zu senden. Ich sehe da nichts was in die Richtung des Debian Servers geht.
Sieht jetzt so hier aus, schnell und dreckig:
Vor dem Erstellen des Tunnels können sich die OPNsense und der Debian Server sich gegenseitig anpingen. Das passt und klappt wunderbar. Config vom WG auf dem Debian:
Routing Table
OPNsense Local
OPNsense Endpoint
OPNsense Routing Table
Hier noch der Beweis das ich das Interface zugewiesen und auf dem WG_Interface jeglichen Traffic durch lasse... zusätzlich auch noch ein Pass für jeglichen Verkehr auf dem WAN-Interface für den WG-Port....
Und es funktioniert nicht. Langsam denke ich an eine Verschwörung.
wg1 tsfT2WQAP40bL9ddzydMoe0ACm7nMLqE6nh6Hd6rjH8= 0interface: wg1
public key: ouKvS+BwiAnxHfe/+ZugeZ8kcXh4/aoYHiB/HfrpYgU=
private key: (hidden)
listening port: 55555
peer: tsfT2WQAP40bL9ddzydMoe0ACm7nMLqE6nh6Hd6rjH8=
endpoint: 122.64.231.110:55555
allowed ips: 0.0.0.0/0Ich bin mir sicher das ich irgendwo einen kapitalen Denkfehler habe, aber ich sehe es nicht. Bestimmt irgendwas ganz banales. Eigenartig ist, das die OPNsense nicht mal versucht etwas an ihr Standard-Gateway zu senden. Ich sehe da nichts was in die Richtung des Debian Servers geht.
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 @6247018886:
Also wenn du das Interface zuweist sollte man dort auch eine IPv4 Config hinterlegen, ist zwar bei WG nicht zwingend nötig aber manche Features benötigen es.
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 ...
Also wenn du das Interface zuweist sollte man dort auch eine IPv4 Config hinterlegen, ist zwar bei WG nicht zwingend nötig aber manche Features benötigen es.
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 ...
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.
Das zweie macht auch keinen Sinn. Wenn ich auf dem WAN-Interface mal Packet Capture laufen lassen und da auf UDP Port 55555 mitschneide und da einfach nichts kommt. Dann ist doch das Problem die OPNsense. Oder sehe ich das Falsch? Da spielt doch das nachgelagerte Gateway noch gar keine Rolle. Die OPNsense versucht nicht mal zu verbinden. Nichts, nada, cero, niente.
Wenn er auf dem WAN-Interface was senden würde und dann kein Handshake zustande kommt, ok, dann muss es an einer anderen Firewall liegen. Aber das kann in diesem beschrieben Problem nicht das Problem sein.
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!
Zitat von @6247018886:
Bei UDP gibt es in dem Sinne auch keine Verbindung, das ist kein TCP!
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!
Das mag ja sein, aber dafür müsste er doch mal überhaupt irgendwas an den Endpoint senden um festzustellen das etwas nicht stimmt. Aber da geht nicht mal ein Hauch einer Anfrage an den gegenüberliegenden Endpoint. Nichts. Erst wenn ich Pinge oder eine Port Probe mache, dann kommt auch was an. Aber vom Wireguard-Daemon kommt nichts.
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 ...
Oh man. Es geschehen noch Zeichen und Wunder.
Ich habe die OPNsense nochmal komplett zurückgesetzt. Ich habe dann folgende Dinge getan:
Danach hat der Daemon endlich aus dem WAN die Pakete geschickt. Was jetzt aber genau zum Erfolg geführt hat, muss ich jetzt noch im Detail über Reproduzierbarkeit prüfen. Zumindest tut sich jetzt was:
Ich habe die OPNsense nochmal komplett zurückgesetzt. Ich habe dann folgende Dinge getan:
- FRR mal rausgeschmissen => Auf gut Glück, weil meine Vermutung das da irgendwas grundlegend umgebaut wird
- Firewall=>Rules=>Floating eine Regel hinzugefügt, die Direction Any alle Pakete vom Port UDP 55555 und Destination "This FIrewall" durch lässt.
- Statt jedes Mal Manual Outbound dieses Mal Hybrid genommen und NAT wie folgende eingestellt...
Danach hat der Daemon endlich aus dem WAN die Pakete geschickt. Was jetzt aber genau zum Erfolg geführt hat, muss ich jetzt noch im Detail über Reproduzierbarkeit prüfen. Zumindest tut sich jetzt was:
General
Local
Endpoints
Status
Handshakes
interface: wg1
public key: WVM6AiXkqIWKHMfuIcAOFW6dWgFE8SnJHCqIwa8lrx8=
private key: (hidden)
listening port: 55555
peer: tsfT2WQAP40bL9ddzydMoe0ACm7nMLqE6nh6Hd6rjH8=
endpoint: 122.64.213.110:55555
allowed ips: 0.0.0.0/0
latest handshake: 1 minute, 27 seconds ago
transfer: 1.05 KiB received, 69.89 KiB sent
Da wird ja der Hund in der Pfanne verrückt 
.
Denke das wird dann der Fehler bei dir gewesen sein.
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.1
Unerklärliches Verhalten... kann derzeit nicht sagen ob es an OPNsense oder an den VMs liegt. Mal funktioniert, mal nicht.
Habe jetzt eine saubere Maschine hochgezogen und das selbe Spiel nochmal durchgeführt. Exakt mich am laufenden Beispiel orientiert. Jetzt geht es wieder nicht. Hatte dann zwei Mal das Phänomen das ich selbst nach Zurücksetzen der kompletten Config, die WAN-Verbindung keine Lust hatte. Egal wie man diese konfigurierte immer, man konnte diese nicht verwenden, war als wäre kein Kabel angeschlossen. Einstellungen des Hypervisors (Virtualbox) wurden aber überprüft. Dann nochmal komplett neuinstalliert und dann ging es wieder.
Dann hatte der WG Daemon kurzzeitig ausgehenden Traffic vermeldet. Aber egal wie, ich konnte auf keinen Interface Traffic ausmachen.
An der Stelle scheint mir aber auch OPNsense nicht ganz stable zu sein. Sobald man FRR Package vor WG installiert, geht gar nichts. Obwohl das Packet ausgeschalten ist.
Ich werde mir doch nochmal paar physische Maschinen raussuchen müssen um das zu testen.
Habe jetzt eine saubere Maschine hochgezogen und das selbe Spiel nochmal durchgeführt. Exakt mich am laufenden Beispiel orientiert. Jetzt geht es wieder nicht. Hatte dann zwei Mal das Phänomen das ich selbst nach Zurücksetzen der kompletten Config, die WAN-Verbindung keine Lust hatte. Egal wie man diese konfigurierte immer, man konnte diese nicht verwenden, war als wäre kein Kabel angeschlossen. Einstellungen des Hypervisors (Virtualbox) wurden aber überprüft. Dann nochmal komplett neuinstalliert und dann ging es wieder.
Dann hatte der WG Daemon kurzzeitig ausgehenden Traffic vermeldet. Aber egal wie, ich konnte auf keinen Interface Traffic ausmachen.
An der Stelle scheint mir aber auch OPNsense nicht ganz stable zu sein. Sobald man FRR Package vor WG installiert, geht gar nichts. Obwohl das Packet ausgeschalten ist.
Ich werde mir doch nochmal paar physische Maschinen raussuchen müssen um das zu testen.
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
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
OPNsense von Rechner im Layer 2 WAN Netzwerk ansprechen
Die Info hätte ich vor paar Stunden gebraucht. Aber ich habe mir beholfen indem ich zwei Netze aufgespannt habe und dazwischen einen weiteren Router installiert.
Der erste Tunnel steht nun und funktioniert. Der zweite Tunnel kann ich nicht mit 0.0.0.0/0 anlegen. Sobald das passiert, wird nicht mal das Interface angelegt. Erst wenn ich Disable Route den Haken setze, wird zumindest mal das Interface angelegt für den zweiten Tunnel. Soweit, so bescheiden. Aber nun senden beide nicht mehr.
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:
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 😉
Nochmal: OPNsense sendet nichts. Das mit TCPdump habe ich mehrmals auf der OPNsense als auf der Debian-Gegenstelle geprüft. Sie hat keinen Bock. Sie sendet nichts, also kann eine zwischengeschaltete Firewall oder Router nicht das Problem sein.
Die ganzen Configs sind haargenau gleich. Wie bei euch auch. Kann mir mittlerweile nur vorstellen, das ihr irgendwas bei der Installation/Einrichtung von OPNsense anders macht als ich. Aber im Endeffekt wüsste ich nicht was.
Ich gebe es auf. Mach ich halt wieder IPsec.
Die ganzen Configs sind haargenau gleich. Wie bei euch auch. Kann mir mittlerweile nur vorstellen, das ihr irgendwas bei der Installation/Einrichtung von OPNsense anders macht als ich. Aber im Endeffekt wüsste ich nicht was.
Ich gebe es auf. Mach ich halt wieder IPsec.
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:
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.
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.
Jetzt sind es auch physische Maschinen.
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.
1
Ggf. deinstallierst du das gesamte WG Plugin nochmal komplett, rebootest die FW und reinstallierst das jungfräulich nochmal neu um auf Nummer sicher zu gehen!
Achte darauf das du nicht das os-wireguard-go Plugin installierst!! Das ist Tabu!!!
Achte darauf das du nicht das os-wireguard-go Plugin installierst!! Das ist Tabu!!!
Zitat von @6247018886:
Es gilt, wenn Interface zugewiesen wird dann bitte auch zwingend mit hinterlegte statischer IPv4 Config wie oben bereits geschrieben, NICHT auf None!!
Ohne Interface-Zuweisung geht es auch so, aber halt ohne Firewall Kontrolle.
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!!
Ohne Interface-Zuweisung geht es auch so, aber halt ohne Firewall Kontrolle.
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.
Bei zweiten Tunnel, Interface nicht zugewiesen, muss ich "Disable Routes" deaktivieren.... dann geht es. Komisch das er es einma zulässt und einmal nicht.
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.
1
Hmm... es wird reproduzierbar.
Tunnel1: Interface zugewiesen, keine IP, Disable Routes Haken gesetzt. 0.0.0.0/0 gesetzt
Tunnel2: Interface nicht zugewiesen, keine IP, Disable Routes Haken nicht gesetzt, 0.0.0.0/0 gesetzt
Tunnel Addressen, Ports und Endpunkte sind dabei unterschiedlich
Ergebnis: Funktioniert
Beide Tunnel nicht zugewiesen, 0.0.0.0/0 gesetzt, Egal ob Disable Routes gesetzt ist oder nicht => geht nicht.
Es geht immer nur eine bestimmte Kombination. Die störende Config scheint sich um 0.0.0.0/0 in Kombi mit dem "Disable Routes" zu drehen. Diese Kombi wird nur einmal zugelassen. Es wundert mich das es bei euch läuft.
Tunnel1: Interface zugewiesen, keine IP, Disable Routes Haken gesetzt. 0.0.0.0/0 gesetzt
Tunnel2: Interface nicht zugewiesen, keine IP, Disable Routes Haken nicht gesetzt, 0.0.0.0/0 gesetzt
Tunnel Addressen, Ports und Endpunkte sind dabei unterschiedlich
Ergebnis: Funktioniert
Beide Tunnel nicht zugewiesen, 0.0.0.0/0 gesetzt, Egal ob Disable Routes gesetzt ist oder nicht => geht nicht.
Es geht immer nur eine bestimmte Kombination. Die störende Config scheint sich um 0.0.0.0/0 in Kombi mit dem "Disable Routes" zu drehen. Diese Kombi wird nur einmal zugelassen. Es wundert mich das es bei euch läuft.
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:
(Hier als "WGTUNx" weil ich möglichst vermeide Default Systemnamen zu verwenden)
Ihr habt mich richtig verstanden. Es lief auch ohne die Angabe der IP. Aber scheinbar nicht stable... ich habe nun die Lösung gefunden:
Interfaces nicht zugewiesen und folgendes bei den Endpoints eingetragen unter Allowed IPs:
Damit klappt es. Es handelt sich dabei um die Tunnel Netzwerke. Scheinbar wird das gebraucht. BGP läuft nun auch und tut was es soll.
Interessant ist auch das immer der zweite Tunnel in der Liste scheinbar paar Minuten brauch um die Verbindung herzustellen. Aber wenn diese einmal steht, läuft diese ohne Probleme.
Interfaces nicht zugewiesen und folgendes bei den Endpoints eingetragen unter Allowed IPs:
Damit klappt es. Es handelt sich dabei um die Tunnel Netzwerke. Scheinbar wird das gebraucht. BGP läuft nun auch und tut was es soll.
Interessant ist auch das immer der zweite Tunnel in der Liste scheinbar paar Minuten brauch um die Verbindung herzustellen. Aber wenn diese einmal steht, läuft diese ohne Probleme.
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 @aqui:
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
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
Na, ich verstehe den Zweck nicht. Es funktioniert ja auch so. Wenn es nur um den Extra Tab unter Firewall und NAT geht, dann wird der nicht unbedingt gebraucht. Mir reicht unter Firewall>Rules der "Wireguard (Group)"... lasse da sowieso alles durch.
Im Endeffekt hätte ich dann im /24 Tunnel Netz zwei Adressen für die selbe Maschine. Muss irgendwo dann auch erklärbar sein was es für einen Zweck hat und dann zur Verständlichkeit dokumentiert werden.
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?!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.
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.
Zitat von @6247018886:
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.
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.
Beste Erklärung zu dem Thema.
Langsam dämmert es mir und würde meinen vermeintlichen "Probleme" erklären. Ich bin davon ausgegangen das er initial versucht selbst zu verbinden und für die Funktion anfangs ein Handshake da sein muss. Klassischer Trugschluss. Ich habe dann meist ein Problem in der Config vermutet, wenn ich keinen Handshake gesehen habe. Deshalb habe ich dann mit der weiteren Config nicht weitergemacht.
Erklärt auch warum ich in einigen Configs, die im Netz kursieren, immer mal wieder bei Site2Site die Gegenstelle als Gateway angelegt wird. Damit hat man immer konstanten Traffic durch den dpinger. Es war für mich nicht logisch. Aber nun gut und wie immer: Man lernt nie aus.
Besten Dank an @aqui und @6247018886 das ihr bis zum Schluss dabei geblieben seit.
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....Zitat von @aqui:
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...
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...
Nur zum Verständnis: Ich habe bereits die IP eigentlich unter Local angegeben und ich soll zusätzlich nochmal eine im selben Netz einsetzen? Als Beispiel
192.168.253.110/24 => Tunnel Address unter Local beim Client
192.168.253.111/24 => IP des zugewiesenen Interfaces und gleichzeitig Neighbor im BGP?
192.168.253.253/24 => Adresse des Endpoints im WG-Netz Server
Weil derzeit verwende ich die Tunnel Address als BGP Neighbor und das funktioniert auch.
Was soll denn die "Local" IP sein?
Das WG Interface auf jeder Seite braucht einfach "eine" IP.
Unter allowed IPs entsprechend die range angeben.
Das WG Interface auf jeder Seite braucht einfach "eine" IP.
Unter allowed IPs entsprechend die range angeben.
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. 😉
Damit habe ich direkt eine Adresse. Funktioniert.
Ja, aber ist diese Adresse, wie oben beschreiben, auch fest einem Interface zugewiesen was dann in der Interface Assignment Liste auftaucht??
Nur DAS zählt und ist relevant für ein korrektes Setup der WG Interfaces!!
Nur DAS zählt und ist relevant für ein korrektes Setup der WG Interfaces!!
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!
1
Ok. Verstanden. Vielen Dank!
Kurze Rückmeldung: Habe es jetzt wie beschrieben 1 zu 1 so übernommen, seit drei Tagen funktioniert es bisher tadellos. Auch von der Performance her sehr überzeugend. Da kann ich meine alte Maschine mit IPsec und GRE-Tunnel in den Ruhestand schicken.
Rückblickend, waren eigentlich nur die Eigenheiten von OPNsense das Hindernis in Kombination mit Halbwissen über den Verbindungsaufbau von WG.
Rückblickend, waren eigentlich nur die Eigenheiten von OPNsense das Hindernis in Kombination mit Halbwissen über den Verbindungsaufbau von WG.
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.
