Hallo Forum,
so gut kenne ich mich mit WireGuard noch nicht aus. Ich habe eine Firewall bei uns im RZ die den WireGuard Server macht. Das heißt die OPNsense ist eigentlich nur ein Peer.
Muss ich in dem Tap Instance dann eine Tunnel Address eintragen? Wenn ich das nicht mache funktioniert auch alles nur bekomme ich im Log folgenden Fehler: /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/ifconfig 'wg1' 'inet' '' alias' returned exit code '1', the output was 'ifconfig: : bad value'
Muss ich mir hier Gedanken machen oder kann ich das Ignorieren?
Gruß
SM
Hallo
Wie ist das Wireguard konfiguriert?
Ist es ein Tunnel mit Transfernetz?
https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html
Beispiel:
LAN A Interface 192.168.1.254/24 <---> wg1 A tunnel addr. 10.4.4.1/24 <-----> wg1 B tunnel addr. 10.4.4.2/24 <---> LAN B Interface 192.168.2.254/24
Ist es ein Tunnel ohne Transfernetz?
https://forum.opnsense.org/index.php?topic=36273.0
Beispiel:
LAN A Interface 192.168.1.254/24 <---> wg1 A tunnel addr. 192.168.1.0/24 <-----> wg1 B tunnel addr. 192.168.2.0/24 <---> LAN B Interface 192.168.2.254/24
Wireguard baut mit der "Endpoint IP" des "Peers" die Verbindung zur Gegenselle auf, dort kann die IP leerbleiben wenn die Gegenstelle der Initiator ist. Die IP in "Instance" "Tunnel Address" leerzulassen hab ich noch nie gemacht. Interessante Info, dass es dann auch funktioniert.
Punkt-zu-Punkt Verbindungen brauchen nicht zwingend Interface-Adressen, daher kann man die Tunnel-Adresse auch weglassen. Das geht erst dann schief, wenn die Firewall selbst durch den Tunnel irgendetwas schicken soll, z.B. DNS-Anfragen. Dann hat sie keine Source-Adresse dafür ...
Aber wenn es darum geht z.B. die LANs zweier Standorte zu verbinden, braucht der Tunnel keine Adressen.
Ah okay gut zu wissen. Bisher hab ich bei solchen Konfigurationen eine Netzadresse eingetragen (z.b.192.168.1.0/24 wenn die OPNsense im LAN die Interface IP 192.168.1.1/24 hat) (wie z.B. Wireguard zur Fritzbox). Aber wenn man es leerlassen kann dann ist Wireguard wohl wie IPsec im Transport Mode.
Also "tunneladdress" beim Peer ist Pflicht, bei der Instance aber nicht, d.h. der Fehler kommt von hier:
https://github.com/opnsense/core/blob/edeff46f3fbfd6b067c65a66176db37e5b13c717/src/opnsense/scripts/Wireguard/wg-service-control.php#L70L73
@Monviech was für dich? :)
Grüsse
Franco
@Franco
Ich schau es mir mal an.
Du meinst hier muss etwas drinstehen:
https://github.com/opnsense/plugins/blob/c45755f6dc2272f21f64102cd8befafc20edb8ad/net/wireguard/src/opnsense/mvc/app/views/OPNsense/Wireguard/general.volt#L105C1-L105C127
Aber hier kann es leer sein?
https://github.com/opnsense/plugins/blob/c45755f6dc2272f21f64102cd8befafc20edb8ad/net/wireguard/src/opnsense/mvc/app/views/OPNsense/Wireguard/general.volt#L134
So verstehe ich das.
Franco, tut mir leid, da irrst du dich. WireGuard braucht definitiv keine Adresse im Tunnel. Die Gegenstelle hat auch keine.
23.7.6 auf beiden Seiten - läuft so.
Die Stelle die ich zeigte macht aus einer leeren tunneladdress ('') einen Array mit einem Element: [''] und das leere Element wird dann verwendet, um eine Adresse zu setzen was natürlich fehlschlägt. In dem Fall müsste man abbrechen mit z.B. empty(). Ansonsten sehe ich keine Nachteile, auch wenn die Konfiguration generell nicht Vorteilhaft ist. Man spart halt ein Feld Arbeit.
Grüsse
Franco
Patrick, wir missverstehen uns hier.
Im Peer Modell die "tunneladdress" sind die Allowed IPs in der GUI. Diese sind Pflichtargumente. (Required=Y)
https://github.com/opnsense/plugins/blob/c45755f6dc2272f21f64102cd8befafc20edb8ad/net/wireguard/src/opnsense/mvc/app/models/OPNsense/Wireguard/Client.xml#L21L25
Im Instance Modell die "tunneladdress" sind die Tunnel Address(es). Diese sind optional. (kein Required)
https://github.com/opnsense/plugins/blob/c45755f6dc2272f21f64102cd8befafc20edb8ad/net/wireguard/src/opnsense/mvc/app/models/OPNsense/Wireguard/Server.xml#L37L40
Das sieht man auch so auf deinen Screenshots.
Grüsse
Franco
Allowed IPs != Tunnel Address :-)
Jetzt sprechen wir wieder vom Selben.
Aber dann nennt sie doch im Modell in Valens Namen "AllowedIPs" und nicht "Tunneladdress" ... WireGuard hat eine zugegebenermaßen gewöhnungsbedürftige aber eindeutige Terminologie. Zwei komplett verschiedene Dinge gleich zu benennen, halte ich zumindest für ungeschickt.
Ich versteck mich da hinter Michael der es vor langer Zeit mal so eingeführt hat. :)
Wir wollen die Models noch etwas umstellen, aber nicht vor 24.1.
Grüsse
Franco
Quote from: Patrick M. Hausen on October 19, 2023, 10:40:36 AM
Aber wenn es darum geht z.B. die LANs zweier Standorte zu verbinden, braucht der Tunnel keine Adressen.
Hallo Patrick, interessantes Thema!
Hältst Du es auch für möglich, dass ein WireGuard Interface ohne IP-Adresse für mehr als zwei "Standorte" genutzt werden kann? Indem nämlich das interne Cryptokey Routing von WG den Traffic trotzdem passend zustellt?
Natürlich. AllowedIPs per Peer passend setzen und dann fluppt das. Ist hier im Einsatz.
Quote from: Patrick M. Hausen on March 19, 2024, 07:26:02 PM
AllowedIPs per Peer passend setzen und dann fluppt das.
Was sagst Du zu folgendem Gedankenspiel: Ich habe 3 Linux-Hosts über das Internet verteilt, die jeweils lediglich eine eigene, öffentliche (statische) IP-Adresse haben.
Könnte ich nun hergehen und wieder ein WireGuard-Interface anlegen und dabei die jeweils anderen zwei Hosts als Allowed IPs und wenn nötig als Routen hinterlegen, so dass diese drei Hosts direkt über ihre öffentlichen Adressen im Tunnel kommunizieren?
Mein Kopf dreht sich gerade. ;D
Edit: Wobei dann gäbe es Probleme beim Aufbau des Tunnels, doch keine "gute" Idee. :P
Was meinst du mit "über ihre öffentlichen Adressen im Tunnel"? Die öffentlich Adressen sind außerhalb der Tunnel. Wenn du "hinter" den 3 Hosts keine weiteren Netze hast, die du miteinander verbinden möchtest, was möchtest du denn erreichen?
Du kannst dir ein privates /24 würfeln, daraus 3 Addressen "für im Tunnel" auswählen, und ein full-mesh oder auch nur hub-and-spoke aufsetzen.
Und wenn es "nur" um verschlüsselte Kommunikation der 3 Hosts untereinander geht, dann gibt es da auch noch den IPsec Transport Mode ...
Quote from: Patrick M. Hausen on March 19, 2024, 07:54:38 PM
was möchtest du denn erreichen?
Nichts bestimmtes, war nur ein Gedankenspiel und kein kluges, s. mein Edit weiter oben.
DNS geht also nicht, ebenso NAT nicht. Wenn ich das mal machen würde, dann nur, weil ich es könnte. :D
Danke Dir.