Apr 05, 2023, updated at 18:52:30 (UTC)

4743

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 6656932323

Url: https://administrator.de/contentid/6656932323

Printed on: April 27, 2024 at 09:04 o'clock

71 Comments

Latest comment

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

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/

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/

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:

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/

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...

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

Hilfreich wäre hier auch dein WG Setup und dein BGP Setup. Dort dann auch die Frage ob du mit Quagga oder FRR oder mit welchem Routing Package auch imemr arbeitest?!

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.

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 ...

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:

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 sent

Tunnel 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
!
end

Mit mehreren Instanzen für Ausfallsicherheit wäre doch möglich?! Ich will ja kein Point-to-Multipoint.

Das ist doch aber Unsinn. Mit Ausfallsicherheit hat das doch gar nichts zu tun wenn du nur ein singuläres Device hast was du über nur eine einzige IP Adresse nutzt. Da nützen dir auch 2 oder 2 Wireguard Prozesse logischerweise nix. Im Gegenteil das kostet nur unnötige Performance und ist zudem völlig überflüssig, denn du routest ja zentral über einen Tunnel.
Hier machst du vermutlich einen gehörigen Denkfehler, kann das sein?!
Zudem ist deine WG Konfig auch falsch!

Es fehlt auf dem Initiator (WG Client) die interne Wireguard IP! So kann der Tunnel niemals funktionieren
Auf einem Initiator (WG Client) definiert man niemals Pubic und Private Key zusammen!
allowed ips: 0.0.0.0/0 ist, wie oben schon gesagt, sinnfrei bei dynamischem Routing und führt das per se ad absurdum. Wenn du so oder so alles mit einer default Route in den Tunnel routest warum willst du dann noch dynamisch routen, das wäre ja dann Quatsch. Sinnvoll wäre hier "allowed ips: 192.168.100.252/32, 10.11.0.0/16" Genau kann man das aber nur sagen wenn man deinen IP Adressplan kennen würde und vor allem dein internes WG Netzwerk.

Die BGP Konfig ist soweit OK. Die WG Konfig leider nicht.
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...

Table of contents

Wireguard - BGD Netzwerk Design

Wireguard Setup

Wireguard Peer Setup pfSense

Wireguard Peer Setup Mikrotik

BGP Setup

BGP Peer Setup pfSense

BGP Peer Setup Mikrotik

BGP Peer Setup Cisco Router

Routing Tabellen und Ping Checks

Wireguard - BGD Netzwerk Design

Die pfSense Firewall ist mit dem Mikrotik über einen Wireguard VPN Tunnel verbunden. Beide Systeme sind hier im gleichen AS 65530.
Der Mikrotik hat zusätzlich eine eBGP Connection auf einen Cisco 2611 Router mit dem AS 64714.
Dieser redistrubuiert BGP in OSPF und sendet das weiter an den Cisco 2621 was aber erstmal für das Setup nur ein kosmetisches Goodie ist.
Ein großer und entscheidender Vorteil bei dynamischem Routing ist das das mühsame Eintragen von statischen Routen und Gateways bei Wireguard Komponenten die kein automatisches Cryptokey Routing supporten wie z.B. pfSense, OPNsense und Mikrotik entfällt. Damit hat man bei Designs mit vielen Routen ein sehr sehr geringes Fehlerrisiko. Ebenso bei mehreren Links auch ein automatisches Failover was aber bekanntlich generell ein Vorteil von dynamischem Routing ist.

Anhand der Routing Tabellen kannst du sehen das die Routen sauber übertragen werden

Wireguard Setup

Das Wireguard Setup ist unspektakulär und wichtig ist nur dann man in den Allowed IPs die korrekten Einträge macht. Gateway Redirect scheidet bei dynamischem Routing generell aus.

Wireguard Peer Setup pfSense

Wireguard Peer Setup Mikrotik

BGP Setup

Auch hier auf beiden ein klassisches iBGP Standardsetup.

BGP Peer Setup pfSense

BGP Peer Setup Mikrotik

Der Mikrotik hat den iBGP Peer auf die pfSense, FRR und einen eBGP Peer auf den Cisco zum AS 64714 um beide Varianten zu sehen.

BGP Peer Setup Cisco Router

router bgp 64714
 bgp router-id 172.22.22.11
 bgp log-neighbor-changes
 neighbor 192.168.87.1 remote-as 65530
 neighbor 192.168.87.1 description Mikrotik
 neighbor 192.168.87.1 update-source Ethernet1/1
 !
 address-family ipv4
 neighbor 192.168.87.1 activate
 auto-summary
 no synchronization
 network 172.22.22.11 mask 255.255.255.255
 network 172.26.11.0 mask 255.255.255.0
 exit-address-family 

Routing Tabellen und Ping Checks

pfSense, FRR

Mikrotik

Cisco

Cisco_2611#sh ip bgp
BGP table version is 6, local router ID is 172.22.22.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.168.87.1                           0 65530 i
*> 100.65.65.0/28   192.168.87.1                           0 65530 i
*> 172.22.22.11/32  0.0.0.0                  0         32768 i
*> 172.26.11.0/24   0.0.0.0                  0         32768 i
*> 192.168.2.0      192.168.87.1                           0 65530 i

Cisco_2611#ping 192.168.87.1 source ethernet 1/3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.87.1, timeout is 2 seconds:
Packet sent with a source address of 172.26.11.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Cisco_2611#ping 192.168.2.1 source ethernet 1/3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 172.26.11.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms 

Fazit

Works as designed!! 👍 😉

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.

Es geht halt nur die zweite Instanz nicht.

Wie bereits gesagt: Eine 2te "Instanz" ist generell unsinnig und überflüssig in so einen Setup.

legitim den anderen Hauptstandort noch als weiteren Neighbor für BGP zu haben, oder nicht?

Absolut!! Das wäre auch best Practise aber dafür benötigt man logischerweise keine 2 WG "Instanzen". Wozu auch...?!
Versteht man dich recht, sähe das von dir oben beschriebene Szenario mit 2 kleinen Beispielstandorten ungefähr so aus, richtig?

(BGP Peer ist der Übersicht halber nur einmal eingezeichnet)

Will mal nicht ausschließen das ich einen groben Denkfehler im Bezug auf Wireguard habe

Ich glaube das ist hier (etwas) die Fall... 😉

findest du 100 verschiedene Herangehensweisen.

Das kann ich mir nicht wirklich vorstellen, denn WG ist was das Setup anbetrifft sehr einfach. Man hat genau 2 Optionen und Varianten: Responder und Initiator....nicht mehr und nicht weniger.

dann mal sehen was passiert.

Du wirst sehen das das 100% klappen wird. Einen besseren Beweis als die saubere Funktionalität über 3 Hersteller hinweg, wie oben dokumentiert, spricht ja für sich.
Ansonsten, wenns mal kneifen sollte, einfach hier fragen.

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.

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.

Damit hast du dann ein vollredundantes Routing und kannst über die Tunnel, die sich ja quasi wie virtuelle Standleitungen verhalten, dynamisch routen.
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.

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.

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.

Hi,
habe das gerade mal getestet, funktioniert hier testweise absolut fehlerfrei mit zwei Wireguard Interfaces (wg1/wg2) jeweils mit 0.0.0.0/0 in den AllowedIPs durchlässig gemacht und natürlich mit Häkchen bei Disable Routes und selbst mit den bei dir genutzten 24 Masken für die Transfernetze!!
Muss also definitiv ein Config-Fehler auf deiner Seite sein. Hätte mich nämlich schwer gewundert wenn das nicht funktioniert hätte, denn Wireguard ist ja perfekt im aktuellen Kernel integriert solche Routing basics würden bei den automatisierten Kernel-Tests nämlich direkt auffallen!

Meine Version getestete Version von OPNSense ist : OPNsense 23.1.5_4-amd64 / FreeBSD 13.1-RELEASE-p7 / OpenSSL 1.1.1t 7 Feb 2023

Wireguard Settings

Routing-Table

Connectivity-Check zu den Peers.

Fazit: Arbeitet so wie erwartet einwandfrei! 👍

Cheers briggs

Scheinbar wenn ich zwei Mal die selbe Subnetzmaske für das Tunnel-Netzwerk verwende

Dieselbe Subnetzmaske ist auch falsch.
Der Server bekommt immer eine /32er Hostmaske der Tunnel IP bei den "Allowed IPs". Die zu übertragenden Netze werden dann je nach Größe mit einer entsprechenden CIDR Maske verwendet je nachdem was man übertragen will bzw. muss.
Ggf. missversteht man dich jetzt auch weil nicht ganz klar ist was du mit der gleichen Maske meinst. Deine Konfig bzw. ein Screenshot wäre hier hilfreich für eine zielführende Antwort.

Bei dynamischem Routing solltest du m.E. nicht mit WG 0.0.0.0/0 Redirects in den Allowed IPs arbeiten, weil das den gesamten Traffic der kleinen Standorte in den Tunnel routet was man keinesfalls will.
Es soll ja nur der Traffic der remoten VPN Netze in den Tunnel, deshalb sollte man das immer dediziert mit entsprechenden CIDR Masken einschränken. Immer Split Tunneling also.
Ansonsten rennt auch sämtlicher lokaler Internet Traffic dieser kleinen Standorte in den Tunnel was sicher nicht gewollt ist. Sieh dir das oben beim BGP Setup im Wireguard Screenshot an!

Er stellt nicht mal eine Layer2-Verbindung her. Kein Handshake.

Leider etwas doppeldeutig?! WAS genau meinst du? Das WG Handshaking. Das BGP Handshaking?

Ansonsten rennt auch sämtlicher lokaler Internet Traffic dieser kleinen Standorte in den Tunnel was sicher nicht gewollt ist.

Nope, dafür ist ja gerade der Haken bei Disable Routes auf der OPNSense zuständig, welcher das automatische Hinzufügen der AllowedIPs in die Routing-Tabelle verhindert und somit auch kein Gateway Redirect auf der OPNSense stattfindet ... 😉.
Es gibt Szenarien da braucht man die 0.0.0.0/0 zwingend auch in den AllowedIPs, z.B. wenn man den Internet-Traffic nur für bestimmte Clients per PolicyRule über den Tunnel leiten möchte, den Rest aber weiterhin über das normale DefaultGW.

Zitat von @6247018886:

Wireguard 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?

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.

Table of contents

WG Setup OPNsense

OPNsense WG Interface Zuweisungen

Firewall Regeln auf den Tunnelinterfaces

OPNsense Ping Check

Mikrotik Connection Check (Peer1, WGTUN1)

RasPi Connection Check (Peer2, WGTUN2)

Fazit

WG Setup OPNsense

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

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 ...

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.

So, beide OPNsense Peers auf Redirect 0.0.0.0/0 umgestellt und funktioniert ebenso fehlerlos.

WG Peers

Peer Status

Ping Checks

Works as designed!

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..

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.

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

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.

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.

wg1	tsfT2WQAP40bL9ddzydMoe0ACm7nMLqE6nh6Hd6rjH8=	0

interface: 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/0

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.

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!

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 ...

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!
Bei UDP gibt es in dem Sinne auch keine Verbindung, das ist kein TCP!

Zitat von @6247018886:

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.

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 ...

Oh man. Es geschehen noch Zeichen und Wunder.

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

Zitat von @Fenris14:
Es geschehen noch Zeichen und Wunder.

Da wird ja der Hund in der Pfanne verrückt

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.

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.

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

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.

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 

Der Ablauf ist hier auf dem Debian sehr schön zu sehen:

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!!

Nur just for Info das du den Wireguard Daemon auf dem Debian mit wg-quick up wg0 immer händisch starten musst sofern du das nicht beim Booten mit systemctl enable wg-quick@wg0.service automatisiert hast. Auch bei einer WG Konfig Änderung musst du mit wg-quick down/up wg0 oder systemctl restart wg-quick@wg0.service den Daemon neu starten. Gut hast du als alter Netzwerk Hase ja sicher auf deinem Radar!

Analog dazu der "tcpdump" des zweiten WG Peers mit UDP Port 57821 auf den Mikrotik:

Auch da: Works as designed!!

Das Setup hier entspricht exakt deinem.

Aquí también ...

Works as designed!

Absolutamente

Mehr 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.

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:

Du schreibst deine OPNsense ist auch eine VM. Ist dem so? Wenn ja, wie ist das Setup dort? Wäre ja auch möglich das der WAN Port in der VM Umgebung ins Nirwana geht. Obwohl du sagst ja das du OPNsense (Im Ping Menü Source immer auf WAN Port IP!!) und Debian pingen kannst, richtig?
Ggf. noch einmal deine WG OPNsense Setups posten. Kollege @6247018886 hat oben Recht das du im Interface Assignment der OPNsense zwingend das WG Interface zuweisen musst mit einer statischen IP Adresse. Regelwerk am WAN Port das inbound WG UDPs auf die WAN IP Adresse erlaubt sind ist auch klar.

Hier nochmals das entsprechende OPNsense Setup zum Peer2 auf den Debian (RasPi) mit UDP 57822:

Vergleiche das Setup genau mit deinem und finde den Fehler!

Firewall Regeln am WAN sind für WG nicht erforderlich sofern OPNsense hier Initiator ist also die WG Sessions aufbaut.
Peer Keepalives sind nur dann erforderlich wenn keine dynamischen Routing Protokolle aktiv sind. Die BGP oder OSPF Session Keepalives halten bei dynamischem Routing dann so oder so immer die Peers aktiv.

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.

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.

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.

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!!!

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.

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.

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.

Interface zugewiesen, keine IP,

Wieso "keine IP"! Das ist falsch und damit kann die WG Konfig nicht funktionieren! Ist ja auch klar wenn die Interface IP Adresse fehlt!
Es ist zwingend erforderlich im Interface Assignment immer das WG Interface hinzuzufügen und diesem eine statische IP Adresse zu gegeben! Ohne diesen Schritt kann das Wireguard VPN nicht sauber funktionieren!
Die pfSense WG Dokumentation ist hier besser und vollständiger als die der OPNsense die das "übersieht"!
Dieser Setup Schritt ist analog zu sehen zur statischen Interface Konfig des WG Interfaces:
[Interface]
Address = 100.64.65.62/27
Wenn diese zentrale Konfig fehlt ist es doch klar das das WG Setup ohne IP per se scheitern muss.
Die statische IP Adressierung des WG Interfaces ist ein Muss. Kollege @6247018886 hat das oben mehrfach explizit beschrieben:

Die Interfaces tauchen dann auch entsprechend mit ihrer Adressierung in der Dashboard Übersicht auf:
(Hier als "WGTUNx" weil ich möglichst vermeide Default Systemnamen zu verwenden)

Oder haben wir dich jetzt irgendwie missverstanden?!

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.

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

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

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.

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.
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:

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:

Na, ich verstehe den Zweck nicht. Es funktioniert ja auch so.

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.

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!!

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!

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.

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.

German solved Question LAN, WAN, Wireless Routers, Routing VPN