77757
Goto Top

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?

Content-Key: 32664225681

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

Printed on: July 18, 2024 at 08:07 o'clock

Member: aqui
aqui Dec 09, 2023 at 20:23:24 (UTC)
Goto Top
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. face-sad
  • 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.
Member: commodity
commodity Dec 09, 2023 updated at 20:32:23 (UTC)
Goto Top
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
Mitglied: 77757
77757 Dec 09, 2023 at 20:39:49 (UTC)
Goto Top
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.
Member: aqui
aqui Dec 09, 2023 updated at 21:07:15 (UTC)
Goto Top
nur der schnell-schnell verfasste Beitrag nach dem Wringen um Hilfe :D
In einem Administrator Forum wenig zielführend! face-sad
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. face-wink
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. face-wink
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.
Member: commodity
commodity Dec 09, 2023 at 21:33:22 (UTC)
Goto Top
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 face-big-smile
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
Mitglied: 8030021182
8030021182 Dec 10, 2023 updated at 15:17:31 (UTC)
Goto Top
Ich beantworte jetzt nur mal die Frage statt mit der Bahn nach Ägypten zu fahren face-big-smile.
# 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
10.1.2.2 GW_PEER A
10.1.2.3 GW_PEER B
10.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
Member: aqui
aqui Dec 10, 2023 updated at 15:05:58 (UTC)
Goto Top
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...

back-to-topDas Tunnel Interface in die "Assigned Interfaces" zu übernehmen
assig


back-to-topEine statisches Gateway und Route für die jeweiligen FB Netze anzulegen

fbgate
statroufb

back-to-topEine FW Regel (erstmal geht "any any") auf dem WG Tunnelinterface anzulegen und nicht auf dem Wireguard Systeminterface!

tun

back-to-topEine FW Regel auf dem WAN Interface einzurichten die UDP 51820 auf "WAN_address" erlaubt.

wan

back-to-topFritzbox 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

back-to-topWorks as designed!


Wie bereits gesagt...ohne ein paar Screenshots seines Setups ist das mehr oder minder "Shooting in the dark"!
Mitglied: 77757
77757 Dec 10, 2023 updated at 20:23:19 (UTC)
Goto Top
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
screenshot 2023-12-10 202112

Firewall-Regeln auf WG
screenshot 2023-12-10 202257

WG-Config @ Fritzboxen
screenshot 2023-12-10 202344

WG-Config @ Client mit 0.0.0.0/0
screenshot 2023-12-10 202333
Member: commodity
commodity Dec 10, 2023 updated at 20:34:01 (UTC)
Goto Top
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 face-smile

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
Mitglied: 8030021182
8030021182 Dec 10, 2023 updated at 22:15:47 (UTC)
Goto Top
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.
Mitglied: 77757
77757 Dec 10, 2023 at 22:41:52 (UTC)
Goto Top
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?
Mitglied: 8030021182
8030021182 Dec 11, 2023 updated at 07:24:46 (UTC)
Goto Top
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.
Member: aqui
aqui Dec 11, 2023 updated at 10:48:49 (UTC)
Goto Top
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!! face-sad
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! face-sad
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! 😉
Mitglied: 8030021182
8030021182 Dec 11, 2023 updated at 11:16:12 (UTC)
Goto Top

back-to-topWireguard IF und Peers


23fd088d53437343faab451d40d48940

back-to-topInterface Assignment


screenshot

back-to-topGateways


screenshot

back-to-topRoutes


screenshot

back-to-topFirewall Rule


screenshot


back-to-topConfig FB1


screenshot

back-to-topConfig FB2


screenshot

back-to-topTEST


back-to-topPing FB1 Netz zu FB2 Netz erfolgreich


screenshot

back-to-topPing FB2 Netz zu FB1 Netz erfolgreich


screenshot

back-to-topFertig!


Also mehr Silbertablett geht jetzt echt nicht.
Member: aqui
aqui Dec 11, 2023 at 11:11:29 (UTC)
Goto Top
Endlich nun auch einmal mit vernünftigen Masken auf den lokalen LANs! 👍 😉
Member: commodity
commodity Dec 11, 2023 at 13:41:35 (UTC)
Goto Top
Jetzt gebt dem armen TO doch mal die Chance, sich selbst reinzufummeln! Ihr ruiniert ja total den Lernerfolg face-big-smile
Wo bleibt denn da die Didaktik?

Viele Grüße, commodity