OPNsense und Wireguard s2s zu VPS

[TheManneken]

Edit: Nachfolgend eine Beschreibung im Zusammenhang mit OpenWRT - zwischenzeitlich wurde aber auf OPNsense umgestellt. Der Tunnel steht inzwischen auch. Weiter ab hier

Hallo,

Da mein ISP nur CGNAT macht und ich gern von extern klassisch per IPv4 auf verschiedene Dienste in meinem Heimnetz zugreifen möchte, habe ich mir dazu einen kleinen VPS bei Ionos mit eigener IPv4 gemietet und habe auf diesem einen Wireguard Server aufgesetzt.

Mit einem Windows Client kann ich mich auch problemlos mit diesem Server verbinden. Anschließend habe ich einen OpenWRT Router frisch aufgesetzt und Wireguard als Client dort eingerichtet. An diesem hängt derzeit auch nur ein Test-Client. Da Wireguard neu für mich ist, halte ich mich an diverse Anleitungen, u.a. diese hier.

Allerdings bekomme ich es nicht hin. Sobald ich das entsprechende Interface in OpenWRT einrichte, geht kein Internetverkehr mehr durch.

Das sind meine Verbindungsdaten laut der *.conf Datei auf dem Server:

[Interface]
PrivateKey = xxx
Address = 10.7.0.3/24
DNS = 212.227.123.16, 212.227.123.17

[Peer]
PublicKey = yyy
PresharedKey = zzz
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 217.154.xxx.xxx:51820
PersistentKeepalive = 25

Damit habe ich entsprechend das Interface eingerichtet:

Und die Daten zum Peer im entsprechenden Tab:

Auf der Interfaces-Übersicht kommt auch eine Verbindung zustande. Auf der Seite Status -> Wireguard wird jedoch bei "Latest Handshake" -> Never angezeigt.

Auch die entsprechende Zone unter Network -> Firewall habe ich nach Anleitung angelegt.

Was mich irritiert ist, dass der Public Key in den Interface Setting bei jeder Übernahme überschrieben wird. Ehrlich gesagt versuche ich dort jedoch, den PublicKey des Peers einzutragen - einen anderen habe ich nicht. Leer lassen darf ich das Feld jedoch auch nicht.

Den Peer-PresharedKey übrigens im entsprechenden Tab einzutragen oder wegzulassen (optional) macht keinen Unterschied.

Mit dem Anlegen statischer IPv4 Routen habe ich schon rumexperimentiert. Abgesehend davon, dass ich damit nichts bewirkt habe, soll das ohnehin nicht nötig sein.

Und da bin ich mit meinem Latein erst mal ein Ende. Ich hoffe, jemand hat einen erleuchtenden Tipp für mich.

Grüße
Manneken

 

[TheCadillacMan]

OpenWRT wird den Public Key jedes mal überschrieben, weil dieser vom Private Key abgeleitet wird. Damit dein eingegebener Public Key bleibt müsstest du dann den zugehörigen Private Key auch eintragen.

Der korrekte (und sicherste) ist aber anders herum: Das Key-Paar am OpenWRT-Client generieren lassen ("Generate new key pair") und dann den dort angezeigten Public Key nehmen und in den Peer am Server eintragen.

 

[kieleich]

wahrscheinlich machst du dir die routen kaputt mit dem allow ip

 

[TheManneken]

@TheCadillacMan
Habe es nun nochmal wie von dir beschrieben neu angelegt. Aber leider ohne Erfolg.

Gibt's denn irgendwo ein Log, wo man einsehen kann, ob überhaupt und was passiert/fehlschlägt?
Im System Log sehe ich nur wann das If überhaupt down/up geht. Allerdings nicht, ob eine Verbindung zum Server hergestellt wird. Das If scheint grundsätzlich immer "online" zu sein, völlig egal, wie ich es konfiguriere.

Systemzeit hab ich auch nochmal abgeglichen - passt

@kieleich
Hab's auch mal ohne versucht, aber es scheint gar kein Tunnel aufgebaut zu werden.

 

[TheManneken]

Zwischenstand:
Inzwischen steht der Tunnel und es wurde in dem Zusammenhang auch ein Wechsel auf OPNsense vollzogen. Die eigentliche Probleme mit dem Tunnel haben aber wohl eher was mit dem eigenen Missverständnis zu den Schlüsseln zu tun. Der Wechsel erfolgte hauptsächlich wegen der Unterbaus und weil die höchste kompatible OpenWRT-Version längst EOL war.

Der Tunnel steht also nun, Problem gibt es jetzt aber immer noch mit der Erreichbarkeit verschiedener Ziele:
Obwohl der Tunnel steht, kann ich vom LAN aus nicht das Gateway des Wireguard-Netzes 10.7.0.1/24 erreichen. Baue ich direkt von einem Client mit WireGuard einen Tunnel auf, erreiche ich diesen aber per ICMP. Das Gleiche gilt umgekehrt für den VPS: von diesem kann ich den verbunden Client anpingen, nicht aber die verbundene OPNsense. Ebensowenig kann ich über Wireguard irgendeine IP in meinem lokalen LAN 192.168.178.0/24 erreichen. Meine Vermutung geht daher in die Richtung, dass seitens OPNsense noch Firewallregeln zu erstellen sind.

Ich habe allerdings beim Versuch festgestellt, die Anfragen an der OPNsense mitzuloggen, dass dort gar keine ICMP-Anfragen an die entsprechenden Ziele eingehen. Daher bin ich davon ausgegangen, dass das Routing über den Tunnel noch nicht korrekt funktioniert. Mein Ansatz war hier dann wiederum der VPS mit Ubuntu und ich habe versuch, mit iptables in der wg0.conf zu arbeiten. Zum Test wollte ich die WebUI meines NAS (192.168.178.20) über Port 5001 erreichen.

Entsprechend sieht meine wg0.conf aktuell so aus:

Spoiler: wg0.conf

[Interface]
Address = 10.7.0.1/24
PrivateKey = <PRIVATE_KEY>
ListenPort = 51820
PostUp = iptables -A FORWARD -i ens6 -o wg0 -j ACCEPT
PostUp = iptables -A FORWARD -i wg0 -o ens6 -j ACCEPT
PostUp = iptables -t nat -A PREROUTING -i ens6 -p tcp -m multiport --dport 5001 -j DNAT --to 192.168.178.20
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -p tcp -d 192.168.178.20 --dport 5001 -j MASQUERADE

PostDown = iptables -D FORWARD -i ens6 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -o ens6 -j ACCEPT
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp -m multiport --dport 5001 -j DNAT --to 192.168.178.20
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -p tcp -d 192.168.178.20 --dport 5001 -j MASQUERADE

# BEGIN_PEER wg_opnsense
[Peer]
PublicKey = <PUBLIC_KEY>
PresharedKey = <PSK>
AllowedIPs = 10.7.0.0/24, 192.168.178.0/24
# END_PEER wg_opnsense
# BEGIN_PEER test-pc
[Peer]
PublicKey = <PUBLIC_KEY>
PresharedKey = <PSK>
AllowedIPs = 10.7.0.0/24, 192.168.178.0/24
# END_PEER test-pc

Zwischendurch habe ich natürlich den/die Tunnel auch neugestartet, damit die iptables überhaupt Anwendung finden. Da ich sie nur für die Tunnel selbst brauche, wollte ich ich sie nicht direkt im System anlegen.

Btw: wenn ich dem Client bei AllowedIPs 0.0.0.0/0 eintrage, wird wie erwartet der gesamte Netzwerkverkehr durch den Tunnel geroutet. Was halt in beiden Fällen noch nicht klappt, ist das Erreichen irgendeines Ziels im Netz 192.168.178.0/24.

Hoffe, jemand kann mir hierbei ein paar Tipps geben.

 

[TheCadillacMan]

AllowedIPs sollte man besser anders konfigurieren:
Beim Server sollte als AllowedIPs bei den Peers nur die jeweilige Adresse des Peers (z. B. 10.7.0.2/32) stehen und falls relevant die Netzwerke, die über den Peer erreichbar sein sollen.
Bei den Clients sollten beim Server-Peer die Netzwerke stehen, die über den Server erreichbar sein sollen (z. B. 192.168.178.0/24).

Auch müssen die Geräte in 192.168.178.0/24 einen Weg ins WG-Netz finden können:
Entweder über eine statische Route für das 10.7.0.0/24-Netz oder in dem man MASQUERADE dafür konfiguriert. Z. zt. machst du das für Traffic der in den WG-Tunnel geht, nicht aber für den aus dem Tunnel. Das würde nicht nochmal überdenken.

 

[Avenger84]

Du hast zwei Peers mit den gleichen allowed IPs (Routen) , das ist falsch bzw. kann nicht klappen.
Ich würde nicht mit masquerade arbeiten, wenn es nicht unbedingt sein muss.

P.s.
Iptables ist legacy, nftables ist aktuell.

 

[TheManneken]

Das mit den allowed IPs kam mir ehrlich gesagt schon komisch vor. Werde ich anpassen.

Auch müssen die Geräte in 192.168.178.0/24 einen Weg ins WG-Netz finden können:

Ich nahm an, dass dazu in erster Linie die Default Route zuständig sei. Die OPNsense kennt ja den Weg zum WG-Netz. Auf Seite des VPS (bei Ionos) gibt es auch kein weiteres (mir bekanntes) Subnetz, so existiert auch nur ein LAN-Interface: ens6, das direkt nach Aufsetzen des VPS mit der öffenltichen IP gestartet wird. Beim Wireguard-Netz nutze ich eine /24er Maske.

Das Ding ist - damit ihr besser versteht, wie meine Expertise ist: meine Kenntnisse mit Linux, vor allem abseits einer GUI, sind äußerst überschaubar. Ich könnte ehrlich gesagt nicht aus dem Stehgreif sagen, welche Zeile in meinen iptables exakt was genau tut.

 

[TheManneken]

Ich komme und komme einfach nicht weiter...

Auf dem Server hab ich jetzt bei den Peers das 192.168.178.0/24 aus den AllowedIPs entfernt. Zuvor hatte ich das doppelt bzw. bei mehreren Peers drinstehen, da ich doch eigentlich jedem Peer (sei es die OPNsense oder ein RoadWarrior-Client) Zugriff auf das Subnet ermöglichen will.

Nun hab ich bei aktivem Tunnel aber keine automatische Route mehr in der Routingtabelle des Servers. Damit die Route standardmäßig durch den Tunnel zustandekommt, habe ich sie zu wg0.conf hinzugefügt:
PostUp = ip route add 192.168.178.0/24 dev wg0
PostDown = ip route del 192.168.178.0/24 dev wg0

Funktioniert auch, die Route wird nun hierüber erstellt.
Auszug von "ip route"

Spoiler: ip route

default via 217.154.xxx.1 dev ens6 proto dhcp src 217.154.xxx.xxx metric 100
10.7.0.2 dev wg0 scope link
10.7.0.3 dev wg0 scope link
10.7.0.4 dev wg0 scope link
prohibit 169.254.169.254
192.168.178.0/24 dev wg0 scope link
212.227.123.16 via 217.154.xxx.1 dev ens6 proto dhcp src 217.154.xxx.xxx metric 100
212.227.123.17 via 217.154.xxx.1 dev ens6 proto dhcp src 217.154.xxx.xxx metric 100
217.154.xxx.1 dev ens6 proto dhcp scope link src 217.154.xxx.xxx metric 100

Auf Client-Seite gibt's "Probleme":
Auf einem Roadwarrior-Client kann ich mein Netz problemlos zu den AllowedIPs hinzufügen, bei Tunnelverbindung kommt die Route zustande.
Auf der OPNsense ändere ich dann gar nichts und belasse dort dann 10.7.0.0/24 als einziges erlaubtes Netz über den Tunnel.

Ich kann dann über die OPNsense auch alle verbundenen Clients im Tunnel anpingen. Direkt von meinem per LAN verbunden PC jedoch nur das Wireguard-Interface auf der OPNsense, sprich die 10.7.0.2. Versuche, die anderen Clients anzupingen, schlagen fehl. Laut Firewall-Log gehen die Anfragen jedoch über das Interface wg0 raus. Ich gehe davon aus, darauf bezieht sich:

Auch müssen die Geräte in 192.168.178.0/24 einen Weg ins WG-Netz finden können:
Entweder über eine statische Route für das 10.7.0.0/24-Netz oder in dem man MASQUERADE dafür konfiguriert. Z. zt. machst du das für Traffic der in den WG-Tunnel geht, nicht aber für den aus dem Tunnel. Das würde nicht nochmal überdenken.

Wie gesagt: eine Route existiert auf der OPNsense:

Nun kommen die ICMP Pakete mutmaßlich mit Quell-IP 192.168.178.99 (mein PC) auf dem Server an. Aber da ich von diesem ausgehend keinen Ping umgekehrt ausführen kann, gehe ich davon aus, dass das (Rück-)Routing immer noch nicht sauber funktioniert. Oder benötige ich NAT oder könnte NAT das Problem sein? Anbei meine NAT-Regeln:

P.s.
Iptables ist legacy, nftables ist aktuell.

Mag sein, lässt sich auch einfacher verstehen. Wie stelle ich die Umstellung an? Aber besser erst einen Schritt vor dem anderen.

Aber apropos:

Spoiler: iptables -L -v -n

Chain INPUT (policy ACCEPT 4144 packets, 453K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1403  333K ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:51820

Chain FORWARD (policy ACCEPT 1 packets, 44 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1918  981K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  239 23368 ACCEPT     0    --  *      *       10.7.0.0/24          0.0.0.0/0
    0     0 ACCEPT     0    --  ens6   wg0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  wg0    ens6    0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ergänzung:
Ich hatte jetzt noch einen anderen Lösungsansatz gesehen, bei dem mittels iptables/nftables gar nicht direkt zum Zielgerät geforwardet wird, sondern nur zum Peer und von diesem Peer, sprich der OPNsense, weiter zum Endgerät. Ansich würde mir das ggf. sogar reichen, somit kein Site-2-Site. Vielleicht schaue ich mir das noch mal an.

 

[TheManneken]

Yeah, zumindest die Portweiterleitungen (siehe obige Ergänzung) laufen nun. Super, damit kann ich erst mal arbeiten. Echtes 2S2 wäre jetzt wohl noch die Kirsche auf der Torte. Da ich die iptables langsam begreife, kann ich mir mal ansehen, ob ich das auf nftables umgebaut bekomme.

 

[Harrdy]

Bei einem Site-to-Site-WireGuard-VPN und Portforwarding vom Server ohne SNAT musst du sicherstellen, dass die Antwortpakete ebenfalls durch das VPN fließen. Andernfalls gehen die Pakete über das Standard-Gateway deines lokalen Systems raus, womit das System, von dem der ursprüngliche Request kommt, natürlich nichts anfangen kann. In der OPNsense gibt es dafür in der Firewall eine entsprechende Option.

Unter den Advanced Features nennt sich das "reply-to". Damit lässt sich das Gateway definieren, über das die Antwortpakete geschickt werden sollen.

Zusätzlich musst du im WireGuard-Tunnel natürlich auch Traffic erlauben, der von einer öffentlichen IP kommt. Dafür kannst du problemlos AllowedIPs = 0.0.0.0/0 verwenden. Dann musst du aber auf beiden Seiten das automatische Erzeugen der Routen deaktivieren.

In der OPNsense heißt die Option "Disable Routes", in der WireGuard-Config des Servers Table = off. Danach - wie du es bereits gemacht hast - auf beiden Seiten die static routes konfigurieren bzw. in der WireGuard-Config die Routen beim Interface-Up setzen lassen, und schon läuft die Geschichte.

Ich hatte über ein Jahr ein identisches Setup mit VPS + WireGuard + OPNsense laufen, weil der neue Glasfaseranbieter nur noch CGNAT angeboten hat. Bei mir kam später noch OSPF dazu, aber das geht hier über das Ziel hinaus.