WireGurad Instance ohne Tunnel Address

[sm-vm]

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

[Monviech (Cedrik)]

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.

[Patrick M. Hausen]

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.

[Monviech (Cedrik)]

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.

[franco]

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

[Monviech (Cedrik)]

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

[Patrick M. Hausen]

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.

[franco]

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

[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

[Patrick M. Hausen]

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.

[franco]

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

[Bob.Dig]

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?

[Patrick M. Hausen]

Natürlich. AllowedIPs per Peer passend setzen und dann fluppt das. Ist hier im Einsatz.

[Bob.Dig]

Natürlich.

Nice!

[Bob.Dig]

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. 

Edit: Wobei dann gäbe es Probleme beim Aufbau des Tunnels, doch keine "gute" Idee.