Jan 28, 2024, updated at Jan 29, 2024 (UTC)

1055

Wireguard S2S und C2S Routing Verständnis

Guten Morgen,

einen schönen Sonntag wünsche ich euch.
Trotz vieler Tutorials und Anleitungen, welche ich gelesen und wohl auch verstanden habe, sehe ich den Wald vor lauter Bäumen nicht mehr.

Ausganglange
- 1x Dedicated Server bei Hetzner mit OPNSense
Wireguard Side2Side Tunnel
Die LAN Schnittstelle der OPNSense hält das Netzwerk 10.20.101.0/24
Für das Wireguard VPN kommt als "Transfer Netzwerk" die 10.254.1.0/24 zum Einsatz.
Wobei 10.254.1.1 meine OPNSense zu Hause hält und die 10.254.1.2 meine Remote OPNSense bei Hetzner.

- 2x Virtuelle Server bei Netcup mit Ubuntu 22.04
Wireguard Client2Side Tunnel
Die Maschinen haben jeweils eine eigene ext. IPv4 Adresse vom Anbieter
Für die Wireguard Instance auf der OPNSense kommt das "Transfer Netzwerk" 10.254.2.0/24 zum Einsatz.
10.254.2.1 hält meine OPNSense zu Hause und die Virtuellen Server bei NetCup halten die 10.254.2.2 und 10.254.2.3

- div. Mobile Endgeräte (MacBook, iPhone, iPad, etc)
Wireguard Client2Side Tunnel
Da sich die Geräte oft unterwegs befinden ist entweder eine 5G Verbindung vorhanden oder ein fremdes WLAN.
Für die Wireguard Instance auf der OPNSense kommt das "Transfer Netzwerk" 10.254.3.0/24 zum Einsatz.
10.254.3.1 ist meine OPNSense zu Hause und 10.254.3.2 - 10.254.3.12 sind Mobile Endgeräte.

Probleme
NetCup VM -> Wireguard -> Heimnetzwerk -> Wireguard -> Hetzner Server = Keine Verbindung
NetCup VM -> Wireguard -> Heimnetzwerk -> Wireguard -> Mobiles Endgerät = Keine Verbindung
Mobiles Endgerät -> Wireguard -> Heimnetzwerk -> Netcup VM = Keine Verbindung
NetCup VM -> Wireguard -> Heimnetzwerk = Funktioniert
Heimnetzwerk -> Wireguard -> Netcup VM = Funktioniert
Mit Funktion meine ich z.B PING (ICMP), SSH

Hier mal Beispielhaft die Konfig einer Netcup VM bis zum Heimnetzwerk

Ausgabe Shell #wg

interface: wg0
  public key: <MyPublicKey>
  private key: (hidden)
  listening port: 59397

peer: <MyPeerKey>
  endpoint: 89.XXX.XXX.XX:51822
  allowed ips: 10.20.0.0/16, 10.254.3.0/24, 10.254.2.0/24, 10.254.1.0/24, 192.168.40.0/24, 10.10.101.0/24, 10.10.102.0/24, 10.10.103.0/24, 10.10.104.0/24, 10.10.105.0/24, 10.10.106.0/24, 10.10.107.0/24, 10.10.108.0/24, 10.10.109.0/24
  transfer: 0 B received, 2.55 MiB sent
  persistent keepalive: every 25 seconds

Ausgabe /etc/wireguard/wg0.conf

[Interface]
PrivateKey = <MyPrivateKey>
Address = 10.254.2.2/32

[Peer] ## NetCup Mailserver ##
PublicKey = <MyPublicKey>
AllowedIPs = 10.20.0.0/16, 10.254.3.0/24, 10.254.2.0/24, 10.254.1.0/24, 192.168.40.0/24, 10.10.101.0/24, 10.10.102.0/24, 10.10.103.0/24, 10.10.104.0/24, 10.10.105.0/24, 10.10.106.0/24, 10.10.107.0/24, 10.10.108.0/24, 10.10.109.0/24
Endpoint = myddnshostname.ddns.net:51822
PersistentKeepalive = 25

Traceroute Beispiele

ext-adm-svc-mail@mail:/home/mail tracepath 10.254.2.1
 1?: [LOCALHOST]                      pmtu 1420
 1:  no reply

ext-adm-svc-mail@mail:/home/mail# tracepath 192.168.40.90
 1?: [LOCALHOST]                      pmtu 1420

Ebenfalls ein Weg: Hetzner VM ins Heimnetzwerk

Wireguard Konfgiuration OPNSense "Hetzner"

Wireguard Config on OPNSense

Name: Wireguard S2S
Tunnel Address: 10.254.1.2/24

Peer: myhostname.ddns.net:51820
Allowed IPs: 10.10.0.0/16, 192.168.40.0/24, 10.254.1.0/24, 10.254.2.0/24, 10.254.3.0/24

Traceroute Ergebnisse

ext-adm-proxy@rproxy:~# tracepath 192.168.40.90
 1?: [LOCALHOST]                      pmtu 1500
 1:  OPNSENSE.hetzner                                0.305ms
 1:  OPNSENSE.hetzner                                0.246ms
 2:  OPNSENSE.hetzner                                0.222ms pmtu 1420
 2:  10.254.1.1                                      11.952ms
 3:  192.168.40.90                                   12.638ms reached
     Resume: pmtu 1420 hops 3 back 3

ext-adm-proxy@rproxy:~# tracepath 10.254.2.2
 1?: [LOCALHOST]                      pmtu 1500
 1:  OPNSENSE.hetzner                             0.141ms
 1:  OPNSENSE.hetzner                             0.211ms
 2:  OPNSENSE.hetzner                             0.255ms pmtu 1420
 2:  10.254.1.1                                           12.044ms
 3:  no reply

Und als letzes noch ein Beispiel vom MacBook aus. (WLAN von Unterwegs)

=======================
MacBook - Mobile
=======================
Wireguard Client Config 

[Interface]
PrivateKey = <MyPrivateKey>
Address = 10.254.3.6/32
DNS = 10.10.107.1

[Peer]
PublicKey = <MyPublicKey>
AllowedIPs = 0.0.0.0/0
Endpoint = myddnshostname.ddns.net:51823

Tracepath Exaples:

destination: 10.10.107.1

1	MacBook		192.168.178.55
2	OPNSense	10.254.3.1
3	OPNSense	10.10.107.1


destination: 10.20.101.5 (Reverse Proxy Hetzner)

1	MacBook		192.168.178.55
2	OPNSense	10.254.3.1
3	*		*
4	*		*

Ich weiß, das Thema ist etwas komplexer und umfangreicher, aber vielleicht findet jemand auf Anhieb die Nadel im Heuhaufen. Das Brett vorm Kopp muss auf jeden Fall weg.
Grundsätzlich funktioniert die Wireguard Verbindung ja, aber das Routing scheint nicht zu 100% zu laufen.

Eine Skizze des Netzwerkaufbaus:

grün = Hetzner - Side2Side Wireguard zwischen 2x OPNSense
blau = NetCup - Client2Side Wireguard zwischen Ubuntu Server und OPNSense
rot = Mobile Endgeräte zwischen MacOS/Windows und OPNSense
lila = Heimnetzwerk mit der "OPNSense"

Liebe Grüße und vielen Dank für eure Zeit.

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

Content-Key: 7750026938

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

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

5 Comments

Latest comment

Mi fällt als erstes auf, dass deine Konfigs sich unnötig schwer lesen lassen. Das macht einen schnellen Blick nicht unbedingt schnell und Fehlersuche unnötig aufwändig.

Ich möchte dir raten, wenn deine Probleme zwar auch L3-7 zu vermuten sind, du dennoch mit L2-3 dich mehr vertraut machst.
Stichwort: Net, Mask, Netting, Supernetting, Routing usw...

Als zweiter grober Fehler fällt auf das das interne WG Netz einmal eine 10.254.1.0/24 Adresse und einmal eine 10.254.2.0/24 Adresse als auch eine 10.254.3.0/24 Adresse hat was so niemals klappen kann, denn das bei einem /24er Prefix bekanntlich 3 völlig unterschiedliche IP Netzwerke die die Kommunikation per se scheitern lassen.
Zusätzlich sind die internen WG Adressen in den "AllowedIPs" vollkommen falsch angegeben (Hostmaske erforderlich) so das das WG Krypto Routing nicht sauber funktionieren kann.

Redirect und/oder Split Tunneling Konzept wurde, obwohl im Tutorial detailiert beschrieben, auch nicht durchgängig umgesetzt.

Nur mal nebenbei: Mit einem einfachen und durchgängigen IKEv2 VPN Konzept hätte man sowohl ein deutlich einfacheres S2S Setup als sich auch die überflüssige Frickelei mit fremden VPN Clients auf den mobilen Endgeräten erspart! Aber warum einfach machen...?!

Fazit:
Tutorials entgegen der Behauptung doch nicht gelesen oder nicht verstanden! 🧐
Merkzettel: VPN Installation mit Wireguard
Bzw. WG Praxis Setup als Beispiel:
Wireguard Site2Site mit Roadwarrior

Zitat von @aqui:

Als zweiter grober Fehler fällt auf das das interne WG Netz einmal eine 10.254.1.0/24 Adresse und einmal eine 10.254.2.0/24 Adresse als auch eine 10.254.3.0/24 Adresse hat was so niemals klappen kann, denn das bei einem /24er Prefix bekanntlich 3 völlig unterschiedliche IP Netzwerke die die Kommunikation per se scheitern lassen.

Es geht dabei ja auch theoretisch um "drei Sites", welche ich gerne via IP Subnetz der Übersichthalber und bzgl. der Firewall Regel Trennung abgerenzen wollte.
Für jedes Netz gibt es ja eine "Wireguard Instanz" auf meiner OPNSense zu Hause, mit eigenem UDP Port.

Zusätzlich sind die internen WG Adressen in den "AllowedIPs" vollkommen falsch angegeben (Hostmaske erforderlich) so das das WG Krypto Routing nicht sauber funktionieren kann.

Redirect und/oder Split Tunneling Konzept wurde, obwohl im Tutorial detailiert beschrieben, auch nicht durchgängig umgesetzt.

Die Allowed IP Liste (Clientseitig) sagt doch aus, wo der Client hin kommunizieren kann?
Also eine Art Routing Liste.
Auf jedem Client muss also seine lokale Wireguard Interface Adresse (10.254.1.2 oder 10.254.2.2, etc) als /32 eingetragen sein. Wie sieht es mit dem "Server Peer" aus. Muss hier /24 verwendet werden oder auch /32?

Einfach kann jeder
Die Clients sind nicht "fremd". Es handelt sich dabei um meine eigenen Geräte oder Frau / Kinder.
Geht mir z.B auch darum, wenn ich im Ausland bin, gerne per Wireguard vom iPad aus nen Tunnel nach Hause aufbaue und über meine deutsche IP erreichbar bin.

Ebenfalls verwende ich den Wireguard Tunnel vom Macbook z.B um per SSH auf die Server bei hetzner oder netcup zuzugreifen.

Fazit:
Tutorials entgegen der Behauptung doch nicht gelesen oder nicht verstanden! 🧐
Merkzettel: VPN Installation mit Wireguard
Bzw. WG Praxis Setup als Beispiel:
Wireguard Site2Site mit Roadwarrior

Ich habe eine Knoten der gelöst werden muss...
Würde es denn deiner Meinung nach die Komplexität raus nehmen, wenn ich statt 3 Wireguard Instanzen nur noch eine Betreibe über die alles läuft?
Dann hängen meine Kinder mit Ihrem Gerät aber auch direkt auf Layer2 Ebene in meinem "Fernwartungstunnel".

Nachtrag:

Nach Anpassung der wg0.conf

[Interface]
PrivateKey = <MyPrivateKey>
Address = 10.254.3.6/**32** --> 10.254.3.6/**24**
DNS = 10.10.107.1

und entsprechender Anpassung der Allowed IP's auf der jeweiligen OPNSense läuft die Verbindung nun.

Dankeschön

Zitat von @ITAllrounder:

Nachtrag:

Nach Anpassung der wg0.conf

[Interface]
PrivateKey = <MyPrivateKey>
Address = 10.254.3.6/**32** --> 10.254.3.6/**24**
DNS = 10.10.107.1

und entsprechender Anpassung der Allowed IP's auf der jeweiligen OPNSense läuft die Verbindung nun.

Wenn dann bitte auch korrekterweise 10.254.3.0/24

10.254.3.6/24 ist keine valide Netzadresse

German solved Question Routers, Routing VPN Networking Basics