Dec 09, 2023, updated at 18:08:24 (UTC)

1705

PfSense mit Wireguard: VPNs untereinander kommunizieren lassen?

Guten Abend zusammen.
Ich möchte VPNs untereinander kommunizieren lassen. Ich komm aber nicht weiter, vielleicht kann mir hier einer helfen - wenn mir noch zu helfen ist..

Zum Einsatz kommt eine pfSense, auf die Wireguard-Tunnels auflaufen.
pfSense ist 172.17.x - respektive Tunnel Adresse 10.1.2.1/24.
VPN A 172.18.x - resp. Tunnel Adresse 10.1.2.2/32
VPN B 172.19.x - resp. Tunnel Adresse 10.1.2.3/32
VPN C 172.20.x - resp. Tunnel Adresse 10.1.2.4/32
Client D hat 10.1.2.5/32 - Allowed: 0.0.0.0/0
Client E hat 10.1.2.6/32 - Allowed: 0.0.0.0/0

Wie realisiere ich nun, dass sich A und C oder E und B, also quasi alle gegeneinander erreichbar sind?
Unter Firewall - Regeln habe ich bereits rumexperimentiert und gegenseitige Freigabe eingefügt - ohne Erfolg.
Auch bei den Allowed IPs bei den Peers habe ich jeweils mal die 10.1.2.0/24 eingetragen - dann ging diese Verbindung plötzlich gar nicht mehr.
Zu erwähnen ist auch, dass die Tunnel-IPs dank der Fritzbox eigens kochenden Suppe nicht zum Einsatz kommt, sondern sie selbst, sprich im Beispiel VPN A eben die 172.18.1.1/16.
Zu erwähnen ist außerdem auch, dass jeweils der Serverbereich, also die 172.17.0.0/16 jederzeit erreichbar ist und auf dem Server selbst komm ich überall hin.

Weiß jemand weiter?

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

Content-Key: 32664225681

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

Printed on: April 28, 2024 at 10:04 o'clock

16 Comments

Latest comment

Die Infos sind leider recht oberflächlich und lückenhaft. Laienhafte Netzwerk Angaben wie z.B. "172.17.x" ohne jegliche sinnvolle Angabe des verwendeten Prefixes (Maske) tun da ein Übriges.

Wie sind die VPNs A bis C (vertmutlich, geraten Site to Site VPNs?!) realisiert (HW, Konfig etc.) und wie sieht deren Konfig aus ?
Wer ist hier VPN Responder (Server) und wer ist Initiator (Client)?

Eine Gateway Redirect Konfig auf den Clients ist eher kontraproduktiv. Hier wäre ein Split Tunneling Konzept besser, da performanter.

Auch bei den Allowed IPs bei den Peers habe ich jeweils mal die 10.1.2.0/24 eingetragen

Was Quatsch ist, denn das ist das interne WG Netz und hier haben die Clients immer eine /32er Hostmaske damit das Cryptokey Routing sauber ist.

Hilfreich wären ein paar Screenshots der pfSense WG Einrichtung und Info ob Responder oder Initiator.
Lesenswert zu den WG Grundlagen ist immer das hiesige Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard

Dort wird auch das pfSense OPNsense Setup im Detail erklärt. Insbesondere die Fritzbox WG Kopplung und ihre Besonderheiten.
Wie gesagt für eine zielführende Hilfe braucht es etwas mehr Infos.

Ich würde hier nicht für jedes VLAN einen eigenen Tunnel aufzubauen, wenn das nicht besondere Gründe hat:

VPN A 172.18.x - resp. Tunnel Adresse 10.1.2.2/32
VPN B 172.19.x - resp. Tunnel Adresse 10.1.2.3/32
VPN C 172.20.x - resp. Tunnel Adresse 10.1.2.4/32

Es genügt doch der eine Tunnel

172.17.x - respektive Tunnel Adresse 10.1.2.1/24

und die übrigen Netze bei Allowed IPs einzutragen. Das Routing übernimmt ja dann die Sense und man muss nur an einer Stelle suchen, wenn es hakt. Firewalltechnisch muss das dann natürlich erlaubt sein, zu den anderen Netzen zu kommen.

Viele Grüße, commodity

Vielen Dank erstmal für eure Antworten.
Laienhaft war nur der schnell-schnell verfasste Beitrag nach dem Wringen um Hilfe :D

Folgendes. Es existiert ein Tunnel mit 10.1.2.1/24. Die Clients beginnend mit 10.1.2.2/32 speisen das WG-Netz.
Die Netzwerke, welche ich verbinden möchte, sind alles Fritzboxen.
Die sind leicht überschaubar, denn die haben das entfernte Netz, wo man dann was freigeben könnte.
Aber die Einzelgeräte? Die haben dann die 10.1.2.x? Das ist der Punkt, wo ich nicht mehr wirklich weiter weiß.

Und was das gegenseitige Routen auf sich hat, die Netze sollen erstmal alle erreichbar sein. Firewall-Beschränkungen möchte ich dann im Anschluss machen, denn ich brauche nicht alles, was erreichbar sein soll.

Außerdem habe ich eine Logikfrage.
Wenn ich mich mit einem Einzelgerät verbinde, bin ich doch direkt auf der pfSense. Wieso gelingt es mir trotz Regelerstellung nicht, mich mit diesem Client direkt in ein anderes Netz zu verbinden, bzw. dort was anzupingen?

Vielen Dank.

nur der schnell-schnell verfasste Beitrag nach dem Wringen um Hilfe :D

In einem Administrator Forum wenig zielführend!

Es existiert ein Tunnel mit 10.1.2.1/24. Die Clients beginnend mit 10.1.2.2/32

Schon eine wneig intelligente Adressierung. Besser man gibt dem Server die .254 und legt die LAN-to-LAN Peers darunter mit .253, .252 usw. und fängt bei den reinen Clients mit .1, .2 usw. an. Dann lassen sich alle Beteiligten deutlich einfacher zuordnen und es erleichtert deutlich das Admin Leben.

Auch macht es Sinn sich noch einmal um eine längerfristig wasserdichte VPN IP Adressierung Gedanken zu machen wo du aber schon recht gut bist.

Die sind leicht überschaubar, denn die haben das entfernte Netz, wo man dann was freigeben könnte.

Bahnhof? Ägypten? 🤔

Und was das gegenseitige Routen auf sich hat, die Netze sollen erstmal alle erreichbar sein.

Zumindestens bei den LAN-to-LAN Setups benötigt die pfSense zwingend statische Routen, denn sie macht kein automatisches Cryptokey Routing!! Hast du das beachtet? (Screenshots)

Wenn ich mich mit einem Einzelgerät verbinde, bin ich doch direkt auf der pfSense.

Sofern das "Einzelgerät" ein einfacher Client ist (Initiator) der als Endpoint direkt die pfSense (Responder) kontaktet, dann JA.

Wieso gelingt es mir trotz Regelerstellung nicht

Mal im Ernst: Wie sollen wir dir diese Frage seriös und zielführend beantworten wenn wir deine Konfig nicht kennen? Es liegt ja damit auf der Hand das du einen Konfig Fehler im WG Setup gemacht hast und unsere Kristallkugeln sind übers Wochenende bekanntlich im Wartungsmodus.

Ah, das sind mehrere Geräte, also lokal verschiedene Netze.
How to correctly ask a question
Wenn Die Peers sich zur Sense verbinden, aber untereinander keinen Zugriff haben, kommt in Betracht:
a) kein Routing der hinter dem Tunnelnetz liegenden Netze (Kollege @aqui hat es beschrieben)
b) keine Firewall-Regel, die die Verbindung zwischen den Netzen erlaubt.

Sollen wir jetzt raten? Ich würde sagen: Es fehlt an beidem

Wenn Du schreibst

Firewall-Beschränkungen möchte ich dann im Anschluss machen,

könnte man da reinlesen, Du hast noch gar nichts an der Firewall geregelt. Dann lässt die nichts in ein anderes Netz durch. Ist ja eine Firewall.
Bislang schreibst Du nicht, ob die getunnelten Netze überhaupt erreicht werden, also ob zB Client B connectet und das VPN A erreicht. Wenn das der Fall ist, fehlt nur die Firewall. Wenn das nicht der Fall ist, fehlt es am Routing für diese Netze.
Da ich beschlossen habe, pro Thread nur noch zweimal zu raten, weil sonst solche Threads entstehen, sehen wir uns wieder, wenn Du aussagekräftige Konfigurationen gepostet hast.
Bis dato schaffst Du vielleicht den letzten Schritt selbst:
https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
(Step 5 +6 im Roadwarrior Setup)

Viele Grüße, commodity

Ich beantworte jetzt nur mal die Frage statt mit der Bahn nach Ägypten zu fahren

# Server ==================================

[Interface]
Address = 10.1.2.1/24
PrivateKey = <PRIVATE KEY SERVER>
ListenPort = 55555

[Peer]
AllowedIPs = 10.1.2.2/32,172.18.x.x/24
PublicKey = <PUBKEY PEER A>

[Peer]
AllowedIPs = 10.1.2.3/32,172.19.x.x/24
PublicKey =  <PUBKEY PEER B>

[Peer]
AllowedIPs = 10.1.2.4/32,172.20.x.x/24
PublicKey =  <PUBKEY PEER C>

# Fritzbox PEER A =========================

[Interface]
Address = 172.18.x.1/24
PrivateKey = <PRIVATE KEY PEER A>

[Peer]
AllowedIPs = 10.1.2.0/24,172.17.x.x/24,172.19.x.x/24,172.20.x.x/24
PublicKey = <PUBKEY SERVER>
Endpoint = <server>:55555
PersistentKeepalive = 25

# Fritzbox PEER B =========================

[Interface]
Address = 172.19.x.1/24
PrivateKey =<PRIVATE KEY PEER B>

[Peer]
AllowedIPs = 10.1.2.0/24,172.17.x.x/24,172.18.x.x/24,172.20.x.x/24
PublicKey = <PUBKEY SERVER>
Endpoint = <server>:55555
PersistentKeepalive = 25

# Fritzbox PEER C =========================

[Interface]
Address = 172.20.x.1/24
PrivateKey = <PRIVATE KEY PEER C>

[Peer]
AllowedIPs = 10.1.2.0/24,172.17.x.x/24,172.18.x.x/24,172.19.x.x/24
PublicKey = <PUBKEY SERVER>
Endpoint = <server>:55555
PersistentKeepalive = 25

Die Gateways und Statische Routen zu den jeweiligen Fritzbox Netzen auf der pfSense selbstredend anlegen

Gateways

1.2.2 GW_PEER A
1.2.3 GW_PEER B
1.2.4 GW_PEER C

Statische Routen

NETZ 172.18.x.0/24 Gateway => GW_PEER A
NETZ 172.19.x.0/24 Gateway => GW_PEER B
NETZ 172.20.x.0/24 Gateway => GW_PEER C

Interfaces für die Wireguard Verbindungen anlegen und die FW Regeln auf die Interfaces legen.

Gruß Katrin

Die genauen Schritte für das pfSense Setup (Wireguard Server/Responder) finden man auch hier:
Wireguard VPN pfSense - Fritzbox

Sehr wahrscheinlich hat der TO beim pfSense Wireguard Setup einen oder mehrere dieser Punkte vergessen...

Das Tunnel Interface in die "Assigned Interfaces" zu übernehmen

Eine statisches Gateway und Route für die jeweiligen FB Netze anzulegen

Eine FW Regel (erstmal geht "any any") auf dem WG Tunnelinterface anzulegen und nicht auf dem Wireguard Systeminterface!

Eine FW Regel auf dem WAN Interface einzurichten die UDP 51820 auf "WAN_address" erlaubt.

Fritzbox WG Konfig Datei für den Import

[Interface]
PrivateKey = EGUXFNRx8/gub5afFGm2MQL/QpmcPXekYMMQgCQm01M=
Address = 192.168.188.1/24

[Peer]
PublicKey = RVtVH2XrAUKCzTRIx23uU7Xf0rXARG2T14H/m/g0jwI=
AllowedIPs = 100.64.64.0/24,192.168.1.0/24
Endpoint = <WAN_ip/hostname_pfSense>:51820
PersistentKeepalive = 25 

Die Allowed IPs für die NUR Clients sieht dann so aus:

[Interface]
PrivateKey = 8C1234567mNOvASetoqRXm2+07tM2xuqV5s9AC0rIVs=
Address = 100.64.64.1/24

[Peer]
PublicKey = 758fxIPLzQCVjzdtQ/+Q1Nbg1CmXl0s44vlvrW5UzQY=
AllowedIPs = 100.64.64.254/32, 192.168.1.0/24, 192.168.178.0/24, 192.168.188.0/24, 192.168.189.0/24
Endpoint = <WAN_ip/hostname_pfSense>:51820
PersistentKeepalive = 25 

Annahme (geraten) das die lokalen FB Netze .178.0/24, .188.0/24 und .189.0/24 sind und das lokale LAN an der pfSense die .1.0/24

Works as designed!

Wie bereits gesagt...ohne ein paar Screenshots seines Setups ist das mehr oder minder "Shooting in the dark"!

Danke für eure Geduld.
Die VPN-Netze sind da und man kann vom jeweiligen Netz aus auch das Servernetz erreichen und die Clients mit den allowed 0.0.0.0/0 sind auch im Internet mit der IP-Adresse vom Servernetz - logisch. Was aber nicht geht, ist das gegenseitige Routing. Auch bekomme ich mit einem Client, welcher tatsächlich 0.0.0.0/0 hat, keine 172.20.x.x auf die Reihe. Im Servernetz ist das natürlich erreichbar. Also ich kann gar nicht so weit weg sein.
Die Rules habe ich ausgiebig getestet, from any to any port any... Computer sagt nein.

Bei statische Routen habe ich die Netze eingetragen, die auch via VPN verbunden sind mit dem Interface WG.

Das hier:

AllowedIPs = 10.1.2.0/24,172.17.x.x/24,172.19.x.x/24,172.20.x.x/24

von katrin11 muss ich erst noch ausprobieren. Aber wenns schon nicht mit 0.0.0.0/0 geht...

Wireguard-Status mit der Übersicht der Alloweds serverseitig

Firewall-Regeln auf WG

WG-Config @ Fritzboxen

WG-Config @ Client mit 0.0.0.0/0

Wenn das nicht geht

Was aber nicht geht, ist das gegenseitige Routing.

warum zeigst Du dann statt der Routen die WG-Config? Dass Du allowed IPs auf 0.0.0.0/0 gesetzt hast, glaube ich Dir doch

Und auch bei den Firewall-Rules: Was nützt es, die WG-Rules zu zeigen? Der Traffic (wenn er geroutet wird) geht ja dann in die anderen Interfaces, da braucht es ggf. auch Regeln. Wenn ich mich recht entsinne, filtert auch die PfSense eingehend am Interface. Jupp, steht hier im ersten Absatz.

Viele Grüße, commodity

Sieht ja schon ein Blinder mit Krückstock das da die Hälfte fehlt. Vor allem in den AllowedIPs in den Fritzbüchsen fehlt so gut wie alles.
Du hast das Prinzip der AllowedIPs und das Cryptokey Routing noch nicht verstanden.
Die AllowedIPs regeln von welchen Subnetzen Traffic angenommen, und was über den Tunnel rausgehen kann, alles andere wird verworfen und nicht übertragen.
Wenn du da also nur 172.17.x.x/24 einträgst ist klar das zu dieser Fritzbox nur Traffic aus diesem Netz angenommen wird, weder von deinen anderen Fritzen noch von den DialIn Clients. Deswegen müssen da alle Netze rein von denen du Traffic erwartest!

Mach es so wie oben beschrieben und es wird auf Anhieb laufen!

Bedenke auch das bei Windows Clients die Firewall für ICMP und SMB angepasst werden muss da sie im Standard diesen Traffic nur aus ihrem eigenen Subnetz annehmen.

Happy Networking.

Katrin.

Das mit den Allowed IPs verstehe ich nicht so ganz, da ich immer das Tunnelnetz im Hinterkopf habe. Muss dieses jetzt auch in den alloweds drin stehen oder reichen die Netze, welche anvisiert werden?

Desweiteren mag das in den Fritz-Configs logisch erscheinen, dass es nicht gehen kann, dennoch gehts nicht einmal bei den Clients via 0.0.0.0/0. Wie gesagt, Verkehr geht alles, IP ist dann die vom Servernetz, aber intern geht lediglich die 172.17.0.0. Welche Regel ist nun dafür verantwortlich?

Zitat von @77757:

Das mit den Allowed IPs verstehe ich nicht so ganz, da ich immer das Tunnelnetz im Hinterkopf habe. Muss dieses jetzt auch in den alloweds drin stehen oder reichen die Netze, welche anvisiert werden?

Wenn die einzelnen Clients die Fritzbox Netze erreichen können sollen dann ja, denn die kommen ja mit einer 10.1.2.x als Quelladresse an den Fritzen an und nicht mit einem eigenen Netz wie die Fritzboxen.

Desweiteren mag das in den Fritz-Configs logisch erscheinen, dass es nicht gehen kann, dennoch gehts nicht einmal bei den Clients via 0.0.0.0/0.

Du vergisst beide Seiten Sender und Empfänger, wenn die Fritzbox die Netze nicht zulässt bringt dir ein 0.0.0.0/0 am Client rein gar nichts weil die Fritzboxen den Traffic der anderen Netze dann nicht rein lässt !! Hier wird geroutet nicht geeNATet, also denk dir immer mit welcher Absenderadresse die einzelnen User in das jeweils andere Netz wollen, und diese Adressen/Subnetze müssen dann auch in die AllowedIPs des Gegenüber! Das ist das Basis-Prinzip des Cryptokey-Routings.

Wie gesagt, Verkehr geht alles, IP ist dann die vom Servernetz, aber intern geht lediglich die 172.17.0.0. Welche Regel ist nun dafür verantwortlich?

Schau dir die AllowedIPs von mir oben nochmal ganz genau an dann verstehst du was bei dir falsch ist.

Firewall-Regeln auf WG

Das Regelwerk ist auch unsinnig. Erst erlaubst du etwas Port spezifisch und dann erlaubst du am Schluss so oder so alles. Das ist völlig unlogisch und sinnfrei und solltest du dringenst noch einmal überdenken!!
Beim Regelwerk gelten generell 2 grundsätzliche Regeln:

Regeln wirken nur INBOUND, also immer vom externen Draht in das Interface hinein!
Es gilt immer: "First match wins!" Bedeutet das nach einem ersten positiven Hit im Regelwerk die restlichen, nachfolgenden Regeln NICHT mehr abgearbeitet werden.

Gerade in Bezug auf die letzte Grundregel ist dein o.a. Regelwerk wenig sinnvoll und überarbeitungswürdig. 🧐

Sinnvoll ist es auch hier generell immer strategisch vorzugehen und zuerst mit einer "Scheunentor Regel" (any any) zu starten um das VPN an sich sauber testen zu können OHNE sich weiter Fussfallen zu stellen.
Erst wenn das sichergestellt ist macht man die Schotten mit den Firewall regeln dicht und kann so sicher sein das man keinen Fehler mehr am VPN gemacht hat sondern eine Fehlfunktion einzig und allein nur noch an einem falschen oder fehlerhaften Regelwerk liegt!

Kardinalsfehler ist wie der Kollege @8030021182 oben schon gesagt hat die völlig fehlerhafte Konfig der Fritzboxen bei den AllowedIPs!!

Dort fehlen sowohl das interne WG Netz (was dann logischerweise die Ursache des Scheiterns der Clients ist weil die FB dieses Netz nicht in den Tunnel routet!) als auch die anderen FB IP Netze und das der pfSense. Das damit dann das Cryptokey Routing völlig in die Hose geht ist nicht weiter verwunderlich!

Bei den Fritzboxen sollte da dann sowas stehen:

Fritzbox A = AllowedIPs = 10.1.2.0/24, 172.17.0.0/16, 172.19.0.0/16, 172.20.0.0/16
Fritzbox B = AllowedIPs = 10.1.2.0/24, 172.17.0.0/16, 172.18.0.0/16, 172.20.0.0/16
Fritzbox C = AllowedIPs = 10.1.2.0/24, 172.17.0.0/16, 172.18.0.0/16, 172.19.0.0/16

/16er Masken zu verwenden ist zwar per se nicht falsch aber ziemlich unsinnig, denn soviel Endgeräte kann man physisch in den LANs gar nicht betreiben.
Das 172er Netze in modernen Zeiten von CIDR Routing auch mit sinnvollen Netzmasken betrieben werden können sollte dir hoffentlich klar sein?! 🧐

Einen Preshared Key braucht es übrigens auf den mobilen Clients nicht! Das ist überflüssiger Unsinn bei der Verwendung von Keys und sollte man besser weglassen!
Zudem sind die mobilen Client Peers auf der pfSense ebenso falsch eingerichtet! Dort darf niemals 0.0.0.0/0 in den AllowedIPs stehen sondern die Client IP mit einer /32er Hostmaske uns sonst nix. Siehe als Beispiel auch HIER.

Du hast also noch eine Menge an Baustellen aufzuräumen oben! 😉