Feste IPs zuhause in pfsense via WireGuard Tunnel

Feste öffentliche IP-Adressen sollen zuhause am privaten Internetanschluss (mit dynamischer WAN-Adresse) für sämtliche Serverdienste (z.B. Exchange, Webserver, Gameserver etc.) nutzbar sein.
Ich habe bereits vor einiger Zeit eine Anleitung zur Einrichtung eines GRE Tunnels erstellt (Link).
Es ist zum Verständnis durchaus hilfreich, auch einen Blick auf die GRE Anleitung zu werfen.
Heute soll es um einen WireGuard Tunnel gehen. WireGuard ist ein neues VPN Protokoll, welches trotz Verschlüsselung extrem schnell ist.
Außerdem ist es direkt im Linux-Kernel integriert.
Mit dem Release der Version 2.5.2 ist WireGuard nun auch unter pfsense verfügbar.
Die Business Tarife mit einer festen IP-Adresse sind in der Regel unverhältnismäßig teuer und mehr als eine IP oder auch Subnetze gibt es sowieso nicht. So auch in meinem Fall. Ich habe zuhause eine Gigabit FTTH Anbindung von der Telekom. Der Business Tarif wäre monatlich doppelt so teuer und Entertain würde entfallen. Mehrere IP-Adressen und Subnetze sind nur über die unbezahlbare Standleitung (Company Connect, jetzt DeutschlandLAN Connect IP) möglich.
Mit dem GRE Tunnel aus der ersten Anleitung lief dann auch alles zufriedenstellend.
Nun aber zu WireGuard...
Einen Linux VPS bei einem Hoster deiner Wahl anmieten. Am besten in der Nähe deines Wohnorts bzw. einem guten Routing zu deinem Internetprovider.
Wichtig! Es muss eine VM sein. VPS auf Containerbasis funktionieren meist nicht, da die erforderlichen Kernel-Treiber vom Host nicht zur Verfügung gestellt werden.
Danach müssen noch eine oder auch mehrere zusätzliche IPv4-Adresse(n) oder alternativ ein IPv4-Subnetz beim Hoster gebucht werden.
In dieser Anleitung wird das Routing für eine feste IP beschrieben.
IP-Tools installieren (idR. vorinstalliert)
Packet-Forwarding aktivieren
Mein Setup-Skript laden
GitHub Link
Die config_sample.sh umbenennen in config.sh und mit einem Editor deiner Wahl bearbeiten.
Hier ein Ausschnitt der Datei:
Nun kann das Skript mit einmal ausgeführt werden. Es wird dann automatisch WireGuard auf dem Server installiert.
WireGuard Keys generieren und in Dateien speichern
Wir benötigen für die Konfiguration nur den Private-Key des Servers und den Public-Key des Clients.
Mit können wir uns den Private-Key ausgeben lassen und in die config.sh einfügen.
Auf der VPS Seite sind wir nun erstmal fertig.
Später muss dann noch der Public-Key des Clients nachgetragen werden. Weiter geht es zuhause unter pfsense.
Ausführen und Stoppen geht dann später über
Wireguard installieren
Einen neuen WireGuard Tunnel anlegen und ein Key-Pair generieren. Den Public-Key kopieren wir uns, um ihn in der config.sh des VPS einzutragen.
Außerdem müssen wir noch den VPS als Peer hinzufügen.
Wir geben hier 0.0.0.0/0 als Netzwerk an, damit sämtlicher Traffic durch den Tunnel gehen kann. Was dann letztlich durch den Tunnel geht, hängt von den pfsense Rules ab. Es wird also nicht automatisch eine Default Route wie bei "Redirect Gateway" unter OpenVPN erstellt!
Der WireGuard Tunnel kann nun einem neuem Interface zugeordnet werden.
Dieses Interface wird mit dem privaten Tunnel-Netzwerk 172.20.1.2/30 konfiguriert und es wird ein neues Gateway 172.20.1.1 erstellt.
Damit das Keep-Alive auf dem Tunnel funktioniert, muss noch eine ICMP Regel auf dem Tunnel Interface angelegt werden.
Ein Ping zwischen pfsense und dem VPS sollte nun funktionieren.
Ein weiteres Interface für das DMZ Netzwerk anlegen.
Hier werden die Server angeschlossen, die öffentliche IPs bekommen sollen, welche dann z.B. per 1:1 NAT zugewiesen werden.
Hierbei könnte es sich z.B. um eine physische Netzwerkkarte oder auch um ein VLAN Interface handeln.
Die Public IP für pfsense wird als VIP/IP-Alias auf dem WireGuard Interface angelegt.
Hier zeigt sich ein großer Vorteil gegenüber GRE und IPsec. Das WireGuard wird als normales Ethernet Interface behandelt und kann deshalb auch genauso konfiguriert werden. Floating rules sind hierbei dann nicht nötig.
Auf dem DMZ Interface muss nun folgende Regel mit der Tunnelgegenstelle als Gateway angelegt werden.
Außerdem noch Regeln zum Blockieren von Traffic zu weiteren Interfaces bei euch zuhause.
Hier konfiguriert pfsense von Haus aus falsche Einträge. Daher muss das Outbound NAT auf 'Manual' gestellt werden und ein manueller Eintrag erfolgen.
Die falsch erstellten Einträge müssen entfernt werden, damit sich nichts doppelt.
Außerdem muss natürlich noch das DNAT zum jeweiligen Server eingerichtet werden. Hier als Beispiel mit einem 1:1 NAT. Damit wären sämtliche Ports der öffentlichen IP am Server erreichbar
Eingehend
(Hier der zusätzliche Sprung zwischen beiden Adressen auf VPS und pfsense schön zu sehen)
Ausgehend
Die Geschwindigkeit ist im Vergleich zu sonstigen Lösungen über ein VPN wirklich überragend.
Auch der Sophos Tunnel erreichte nur knapp die Hälfte der Geschwindigkeit (350Mbit).
Die übliche Geschwindigkeit des FTTH Anschlusses ohne Tunnel liegt etwa bei 920 Down/540 Up.
Komplett durchgefallen sind bei mir fertige VPN Lösungen wie von Portunity. Hier waren an guten Tagen 150-200Mbit/s drin.
Leider muss bei GRE auf beiden Seiten eine feste Gegenstelle angegeben werden. Das wird problematisch, sobald sich die WAN IP zuhause durch einen Router-Neustart oder eine Zwangstrennung ändert.
Bei WireGuard ist das nicht notwendig, weil es seine Pakete via UDP verschickt bzw. seinen Peer nicht zwangsläufig kennen muss.
Deshalb reicht eine Seite mit fester Adresse (in dem Fall der VPS). Ein Peer kann daher dynamisch bleiben.
Theoretisch könnte man sogar DynDNS Adressen einsetzten, was bei GRE ebenfalls nicht möglich ist.
Aufgrund der Nachfrage hier noch eine kleine Info zur verwendeten Hardware:
https://store.servdiscount.com/de/configurate/5456
2 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 20.04 LTS
pfsense 2.5.2
Intel Core i7 4770, 32GB RAM
Mellanox ConnectX-3 10 Gigabit Adapter
4 Port Intel Gigabit Adapter
Konfigurierte Netzwerke:
WAN: PPPoE Verbindung über VLAN 7. Verbunden mit Huawei MA5671A GPON SFP Modem.
Tarif: "Magenta Giga" 1000 Down/ 500 Up
LAN: Heimnetz
GUEST: Freifunk mit einem VPN Uplink (VLAN)
DMZ: Alle Server für öffentliche feste Adressen (zugewiesen per 1:1 NAT)
Auf dem Router laufen sämtliche interne Dienste wie DHCP, DNS, pfblockerNG (Adblocker etc.), Suricata als IPS bzw. DPI und noch ein OpenVPN Server zur Einwahl von unterwegs.
Die monatlichen Gesamtkosten liegen bei 5€ + 1€ für jede öffentliche IP bzw. +8€ für ein /29 Subnetz.
Viel Spaß beim Nachbauen!
Ich habe bereits vor einiger Zeit eine Anleitung zur Einrichtung eines GRE Tunnels erstellt (Link).
Es ist zum Verständnis durchaus hilfreich, auch einen Blick auf die GRE Anleitung zu werfen.
Heute soll es um einen WireGuard Tunnel gehen. WireGuard ist ein neues VPN Protokoll, welches trotz Verschlüsselung extrem schnell ist.
Außerdem ist es direkt im Linux-Kernel integriert.
Mit dem Release der Version 2.5.2 ist WireGuard nun auch unter pfsense verfügbar.
Inhaltsverzeichnis
Einleitung
Die Business Tarife mit einer festen IP-Adresse sind in der Regel unverhältnismäßig teuer und mehr als eine IP oder auch Subnetze gibt es sowieso nicht. So auch in meinem Fall. Ich habe zuhause eine Gigabit FTTH Anbindung von der Telekom. Der Business Tarif wäre monatlich doppelt so teuer und Entertain würde entfallen. Mehrere IP-Adressen und Subnetze sind nur über die unbezahlbare Standleitung (Company Connect, jetzt DeutschlandLAN Connect IP) möglich.
Mit dem GRE Tunnel aus der ersten Anleitung lief dann auch alles zufriedenstellend.
Nun aber zu WireGuard...
Umsetzung (Einzel IPs via NAT)
Einen Linux VPS bei einem Hoster deiner Wahl anmieten. Am besten in der Nähe deines Wohnorts bzw. einem guten Routing zu deinem Internetprovider.Wichtig! Es muss eine VM sein. VPS auf Containerbasis funktionieren meist nicht, da die erforderlichen Kernel-Treiber vom Host nicht zur Verfügung gestellt werden.
Danach müssen noch eine oder auch mehrere zusätzliche IPv4-Adresse(n) oder alternativ ein IPv4-Subnetz beim Hoster gebucht werden.
In dieser Anleitung wird das Routing für eine feste IP beschrieben.
Konfiguration VPS Seite
Für ein besseres Verständnis werden folgende Adressen von nun an verwendet
Haupt IP VPS: 1.1.1.1/32
Zweite IP VPS: 2.2.2.2/32 (Das wird später die feste IP für pfsense)
WAN IP zuhause: 5.5.5.5 (Unwichtig, da die WAN IP nicht irgendwo fest eingetragen werden muss)
Haupt IP VPS: 1.1.1.1/32
Zweite IP VPS: 2.2.2.2/32 (Das wird später die feste IP für pfsense)
WAN IP zuhause: 5.5.5.5 (Unwichtig, da die WAN IP nicht irgendwo fest eingetragen werden muss)
IP-Tools installieren (idR. vorinstalliert)
apt install iptables iproute2 net-tools
Packet-Forwarding aktivieren
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
Wenn IPv6 genutzt werden soll:
echo 'net.ipv6.conf.all.forwarding=1' >> /etc/sysctl.conf
echo 'net.ipv6.conf.all.proxy_ndp=1' >> /etc/sysctl.conf
sysctl -p
Mein Setup-Skript laden
GitHub Link
Die config_sample.sh umbenennen in config.sh und mit einem Editor deiner Wahl bearbeiten.
Hier ein Ausschnitt der Datei:
tun_proto="wg"
##############
# Interfaces #
##############
nic="eth0"
tun_if="wg0"
##############
# Addresses #
##############
# Public IP used for tunnel. Should be the main IP of your VPS
local_ip="1.1.1.1"
# Tunnel IP + network
tun_local_addr="172.20.1.1/30"
# Tunnel IP of your home router
tun_remote_addr="172.20.1.2"
#################
# IPv6 settings #
#################
ipv6="false"
local_ip6=""
tun_local_addr6=""
tun_remote_addr6=""
###############
# MTU setting #
###############
# GRE: Should be 1476 for normal ethernet WAN and 1468 for PPPoE connections
# WG: 1420 is default for Wireguard
tun_mtu="1420"
################
# Public IP(s) #
################
# Define your public IPs that will be routed to your home router
# Use an array ( "IP1/CIDR" "IP2 "IP3" ... )
public_ip=( "2.2.2.2/32" )
public_ip6=( )
Nun kann das Skript mit
./tunnel.sh
WireGuard Keys generieren und in Dateien speichern
wg genkey | tee privatekey | wg pubkey > publickey
Mit
cat privatekey
Auf der VPS Seite sind wir nun erstmal fertig.
Später muss dann noch der Public-Key des Clients nachgetragen werden. Weiter geht es zuhause unter pfsense.
Ausführen und Stoppen geht dann später über
./tunnel.sh up bzw. down
Pfsense Seite
Packages
Wireguard installierenEinen neuen WireGuard Tunnel anlegen und ein Key-Pair generieren. Den Public-Key kopieren wir uns, um ihn in der config.sh des VPS einzutragen.
Außerdem müssen wir noch den VPS als Peer hinzufügen.
Wir geben hier 0.0.0.0/0 als Netzwerk an, damit sämtlicher Traffic durch den Tunnel gehen kann. Was dann letztlich durch den Tunnel geht, hängt von den pfsense Rules ab. Es wird also nicht automatisch eine Default Route wie bei "Redirect Gateway" unter OpenVPN erstellt!
Der WireGuard Tunnel kann nun einem neuem Interface zugeordnet werden.
Dieses Interface wird mit dem privaten Tunnel-Netzwerk 172.20.1.2/30 konfiguriert und es wird ein neues Gateway 172.20.1.1 erstellt.
Damit das Keep-Alive auf dem Tunnel funktioniert, muss noch eine ICMP Regel auf dem Tunnel Interface angelegt werden.
MTU
Je nach Internetanschluss muss die MTU angepasst werden. Bei meinem Anschluss wird PPPoE für die Einwahl verwendet. Daher liegt die maximal mögliche Einheit bei (1500 Byte -8 Byte PPPoE -20 Byte IPv4 -8 Byte UDP - 40 Bytes WireGuard) 1424 Byte. WireGuard verwendet standardmäßig eine MTU 1420, weshalb das sowohl mit einem Ethernet WAN als auch mit PPPoE funktioniert.
Einen Rechner gibt es hier: Link
Je nach Internetanschluss muss die MTU angepasst werden. Bei meinem Anschluss wird PPPoE für die Einwahl verwendet. Daher liegt die maximal mögliche Einheit bei (1500 Byte -8 Byte PPPoE -20 Byte IPv4 -8 Byte UDP - 40 Bytes WireGuard) 1424 Byte. WireGuard verwendet standardmäßig eine MTU 1420, weshalb das sowohl mit einem Ethernet WAN als auch mit PPPoE funktioniert.
Einen Rechner gibt es hier: Link
Ein Ping zwischen pfsense und dem VPS sollte nun funktionieren.
Ein weiteres Interface für das DMZ Netzwerk anlegen.
Hier werden die Server angeschlossen, die öffentliche IPs bekommen sollen, welche dann z.B. per 1:1 NAT zugewiesen werden.
Hierbei könnte es sich z.B. um eine physische Netzwerkkarte oder auch um ein VLAN Interface handeln.
Routing
Die Public IP für pfsense wird als VIP/IP-Alias auf dem WireGuard Interface angelegt.Hier zeigt sich ein großer Vorteil gegenüber GRE und IPsec. Das WireGuard wird als normales Ethernet Interface behandelt und kann deshalb auch genauso konfiguriert werden. Floating rules sind hierbei dann nicht nötig.
Firewall
Auf dem DMZ Interface muss nun folgende Regel mit der Tunnelgegenstelle als Gateway angelegt werden.Außerdem noch Regeln zum Blockieren von Traffic zu weiteren Interfaces bei euch zuhause.
NAT
Hier konfiguriert pfsense von Haus aus falsche Einträge. Daher muss das Outbound NAT auf 'Manual' gestellt werden und ein manueller Eintrag erfolgen.Die falsch erstellten Einträge müssen entfernt werden, damit sich nichts doppelt.
Außerdem muss natürlich noch das DNAT zum jeweiligen Server eingerichtet werden. Hier als Beispiel mit einem 1:1 NAT. Damit wären sämtliche Ports der öffentlichen IP am Server erreichbar
Test
Traceroute Test
Eingehend(Hier der zusätzliche Sprung zwischen beiden Adressen auf VPS und pfsense schön zu sehen)
Ausgehend
Performance Test
Die Geschwindigkeit ist im Vergleich zu sonstigen Lösungen über ein VPN wirklich überragend.Auch der Sophos Tunnel erreichte nur knapp die Hälfte der Geschwindigkeit (350Mbit).

Komplett durchgefallen sind bei mir fertige VPN Lösungen wie von Portunity. Hier waren an guten Tagen 150-200Mbit/s drin.
Probleme mit dynamischer WAN IP
Leider muss bei GRE auf beiden Seiten eine feste Gegenstelle angegeben werden. Das wird problematisch, sobald sich die WAN IP zuhause durch einen Router-Neustart oder eine Zwangstrennung ändert.Bei WireGuard ist das nicht notwendig, weil es seine Pakete via UDP verschickt bzw. seinen Peer nicht zwangsläufig kennen muss.
Deshalb reicht eine Seite mit fester Adresse (in dem Fall der VPS). Ein Peer kann daher dynamisch bleiben.
Theoretisch könnte man sogar DynDNS Adressen einsetzten, was bei GRE ebenfalls nicht möglich ist.
Hardware
Aufgrund der Nachfrage hier noch eine kleine Info zur verwendeten Hardware:
myLoc VPS
https://store.servdiscount.com/de/configurate/54562 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 20.04 LTS
Heim Router (Selbstbau)
pfsense 2.5.2Intel Core i7 4770, 32GB RAM
Mellanox ConnectX-3 10 Gigabit Adapter
4 Port Intel Gigabit Adapter
Konfigurierte Netzwerke:
WAN: PPPoE Verbindung über VLAN 7. Verbunden mit Huawei MA5671A GPON SFP Modem.
Tarif: "Magenta Giga" 1000 Down/ 500 Up
LAN: Heimnetz
GUEST: Freifunk mit einem VPN Uplink (VLAN)
DMZ: Alle Server für öffentliche feste Adressen (zugewiesen per 1:1 NAT)
Auf dem Router laufen sämtliche interne Dienste wie DHCP, DNS, pfblockerNG (Adblocker etc.), Suricata als IPS bzw. DPI und noch ein OpenVPN Server zur Einwahl von unterwegs.
Gigabit über PPPoE
Bzgl. der Hardware-Anforderungen ist dieses Thema zumindest nicht unwichtig. Bei der Deutschen Telekom kommt auch im FTTH Netz für Privatkunden (realisiert über passive Splitter im Haus, siehe GPON) leider immer noch PPPoE bei der Einwahl zum Einsatz. Daher läuft sämtlicher Traffic auf der WAN Schnittstelle über nur einen CPU Core. Normalerweise haben Netzwerkkarten heutzutage mehrere sogenannte 'Queues', die dann auch Multithreading ermöglichen. Das ist über PPPoE zumindest in pfsense aktuell nicht möglich. Außerdem gibt es einen Bug im FreeBSD Treiber einiger Intel Netzwerkkarten, weshalb einige nicht die volle Performance erreichen.
Eigentlich wäre für den Betrieb als Server eine gute Multicore-Performance wichtig, in diesem Fall ist aber auch eine gute Single-Core Performance nicht unerheblich. Für einen dedizierten pfsense Router würde ich also eher eine Desktop CPU mit hohem Takt und wenig Kernen bevorzugen.
Bzgl. der Hardware-Anforderungen ist dieses Thema zumindest nicht unwichtig. Bei der Deutschen Telekom kommt auch im FTTH Netz für Privatkunden (realisiert über passive Splitter im Haus, siehe GPON) leider immer noch PPPoE bei der Einwahl zum Einsatz. Daher läuft sämtlicher Traffic auf der WAN Schnittstelle über nur einen CPU Core. Normalerweise haben Netzwerkkarten heutzutage mehrere sogenannte 'Queues', die dann auch Multithreading ermöglichen. Das ist über PPPoE zumindest in pfsense aktuell nicht möglich. Außerdem gibt es einen Bug im FreeBSD Treiber einiger Intel Netzwerkkarten, weshalb einige nicht die volle Performance erreichen.
Eigentlich wäre für den Betrieb als Server eine gute Multicore-Performance wichtig, in diesem Fall ist aber auch eine gute Single-Core Performance nicht unerheblich. Für einen dedizierten pfsense Router würde ich also eher eine Desktop CPU mit hohem Takt und wenig Kernen bevorzugen.
Zusammenfassung
Die monatlichen Gesamtkosten liegen bei 5€ + 1€ für jede öffentliche IP bzw. +8€ für ein /29 Subnetz.Weitere Vorteile
In Zeiten von Internetanschlüssen ohne eigene IPv4 Adresse (z.B. Vodafone Kabel mit CG-NAT) ist so ein Tunnel ebenfalls sehr interessant. Hierzu kann der Tunnel über die IPv6 Verbindung erfolgen, da diese Adressen bei den meisten Providern wie üblich nutzbar und nicht mit anderen geteilt sind.
Auch um schlechtes oder überlastetes Peering der Provider zu umgehen, kann dieser Tunnel genutzt werden. Das ist sehr häufig im Netz der Deutschen Telekom der Fall (Stichwort: Paid Traffic und kein DE-CIX Peering)
In Zeiten von Internetanschlüssen ohne eigene IPv4 Adresse (z.B. Vodafone Kabel mit CG-NAT) ist so ein Tunnel ebenfalls sehr interessant. Hierzu kann der Tunnel über die IPv6 Verbindung erfolgen, da diese Adressen bei den meisten Providern wie üblich nutzbar und nicht mit anderen geteilt sind.
Auch um schlechtes oder überlastetes Peering der Provider zu umgehen, kann dieser Tunnel genutzt werden. Das ist sehr häufig im Netz der Deutschen Telekom der Fall (Stichwort: Paid Traffic und kein DE-CIX Peering)
Viel Spaß beim Nachbauen!
Please also mark the comments that contributed to the solution of the article
Content-Key: 1124828094
Url: https://administrator.de/contentid/1124828094
Printed on: February 1, 2023 at 03:02 o'clock
39 Comments
Latest comment

Moin,
die Funktion/Aufgabe einer DMZ ist dir bekannt?
Deine "Sternchenregel" solltest du nochmal überarbeiten.
Gruß
C.C.
die Funktion/Aufgabe einer DMZ ist dir bekannt?
Deine "Sternchenregel" solltest du nochmal überarbeiten.
Gruß
C.C.

Die einen bezeichnen es als einfach, andere nennen es Q&D.
Den einfach wird es erst, wenn man es verstanden hat.
Und es macht nicht nur Sinn, es ist die primäre Aufgaben einer DMZ.
Den einfach wird es erst, wenn man es verstanden hat.
Und es macht nicht nur Sinn, es ist die primäre Aufgaben einer DMZ.
Danke für die Anleitung. Vor allen das mit der Geschwindigkeit ist sehr interessant 
Da werde ich mir WireGuard doch mal genauer anschauen.
@aqui hatt dazu auch schon mal was geschrieben Merkzettel: VPN Installation mit Wireguard
Da werde ich mir WireGuard doch mal genauer anschauen.
@aqui hatt dazu auch schon mal was geschrieben Merkzettel: VPN Installation mit Wireguard
Da GRE für mich nicht in Frage kam, habe ich mich auch an Wireguard versucht.
Der Tunnel steht seit einigen Tagen und ich kann jeweils pingen, auch in das Netz dahinter.
Ich habe jedoch auf dem VPS auch eine pfSense installiert.
Diese hat jedoch nach wie vor nur eine IPv4 und 6 halt.
Ich stelle mir schon die Frage, wie ich dort am VPS eine zweite Netzwerkkarte erstelle und dieser IPv6 zuweise.
Wichtig für mich wäre halt nur, ob man zwingend 2 Interfaces auf den VPS benötigt (und den Tunnel)
Theoretisch müsste es dann ja gehen ohne extra eine weitere teure IPv4 zu ordern.
Der Tunnel steht seit einigen Tagen und ich kann jeweils pingen, auch in das Netz dahinter.
Ich habe jedoch auf dem VPS auch eine pfSense installiert.
Diese hat jedoch nach wie vor nur eine IPv4 und 6 halt.
Ich stelle mir schon die Frage, wie ich dort am VPS eine zweite Netzwerkkarte erstelle und dieser IPv6 zuweise.
Wichtig für mich wäre halt nur, ob man zwingend 2 Interfaces auf den VPS benötigt (und den Tunnel)
Theoretisch müsste es dann ja gehen ohne extra eine weitere teure IPv4 zu ordern.
Ich habe auch etwas gegoogelt.
Ich kann über virtuelle IPs der WAN eine zweite IP zuweisen.
Das ist auch richtig, dass die einzige Schnittstelle WAN ist und diese dann die 2 IPs zugewiesen bekommt, ja?
Dann würde ich da mal was bestellen.
Bei IPv6 hat man ja mehrere, das müsste dann ja von Haus aus gehen
Ich kann über virtuelle IPs der WAN eine zweite IP zuweisen.
Das ist auch richtig, dass die einzige Schnittstelle WAN ist und diese dann die 2 IPs zugewiesen bekommt, ja?
Dann würde ich da mal was bestellen.
Bei IPv6 hat man ja mehrere, das müsste dann ja von Haus aus gehen

Buch' doch einfach die zweite IPv4. So ist es hier beschrieben worden. Das kostet dich 1-2€.
Ist nicht die Welt...
Ist nicht die Welt...
Naja, man sollte berücksichtigen, dass derzeit die großen Provider die Preise für IPv4-Adressen (insbesondere von IPv4-Subnetzen) massiv erhöhen aufgrund dessen, weil IPv4 Adressen ausgehen. Das hat beispielsweiße erst Hetzner vor kurzem gemacht. Die kleineren werden mit Sicherheit ebenfalls die Preise irgendwann erhöhen müssen.
Man kann das ganze auch mit nur einer öffentlichen IPv4 Adresse realisieren (das ganze auch ohne IPv6 Adresse, auch wenn ich der Meinung bin, dass man bei neuen Projekten definitiv auf IPv6 setzen sollte - zumindest als Dual Stack).
Ansonsten ein schönes Tutorial. Vielen Dank.
Dual Stack ist natürlich sauberer, ich für meinen Teil benötige theoretisch nur verschiedene Ports zur Weiterleitung. Wie man es bei der Telekom früher halt direkt machen konnte.
Der Tunnel selbst soll so oder so dann über IPv6 laufen, eben weil der CG-Nat Router überlastet sein kann.
Thema IPv4. Die kostet bei mir auch nur 1€.
Jedoch wird das jährlich abgerechnet. Man kann also nicht wie bei einem VPS stündlich kündigen.
Das hieße 5€ Einrichtungsgebühr, und 12x1€
Die wäre ich jederzeit bereit zu zahlen, wenn es Sinn macht oder besser ist. Aber 17€ zahlen um es vielleicht überstürzt gekauft zu haben fände ich doof
Der Tunnel selbst soll so oder so dann über IPv6 laufen, eben weil der CG-Nat Router überlastet sein kann.
Thema IPv4. Die kostet bei mir auch nur 1€.
Jedoch wird das jährlich abgerechnet. Man kann also nicht wie bei einem VPS stündlich kündigen.
Das hieße 5€ Einrichtungsgebühr, und 12x1€
Die wäre ich jederzeit bereit zu zahlen, wenn es Sinn macht oder besser ist. Aber 17€ zahlen um es vielleicht überstürzt gekauft zu haben fände ich doof
Zitat von @148848:
Naja, man sollte berücksichtigen, dass derzeit die großen Provider die Preise für IPv4-Adressen (insbesondere von IPv4-Subnetzen) massiv erhöhen aufgrund dessen, weil IPv4 Adressen ausgehen. Das hat beispielsweiße erst Hetzner vor kurzem gemacht. Die kleineren werden mit Sicherheit ebenfalls die Preise irgendwann erhöhen müssen.
Naja, man sollte berücksichtigen, dass derzeit die großen Provider die Preise für IPv4-Adressen (insbesondere von IPv4-Subnetzen) massiv erhöhen aufgrund dessen, weil IPv4 Adressen ausgehen. Das hat beispielsweiße erst Hetzner vor kurzem gemacht. Die kleineren werden mit Sicherheit ebenfalls die Preise irgendwann erhöhen müssen.
Das habe ich gerade gesehen. Das zieht ja richtig an.
Alle vor dem 02.08. haben die alten Preise und behalten die auch, bis man selbst das Paket ändert. Das sollte man also tunlichst lassen.
Also muss ich nachher wirklich dringend aufstocken, noch haben die bei mir 1€
Vielen Dank an der stelle für die wieder sehr umfangreiche Anleitung. Funktioniert wirklich hervorragend und sehr viel weniger hackelig als mit dem GRE Tunnel.
Ich habe nur leider noch immer das Problem mit dem DNS_Probe.
Surfe ich vom Smartphone (ohne wlan) auf example.com wird der webserver angesteuert.
Surfe ich vom LAN auf example.com wird die DNS nicht aufgelöst (würde ja im Kreis gehen)
Die IP 192.168.4.101 ist aber vom LAN aus pingbar und über http://192.168.4.101:80 lässt sich auch der Webserver aufrufen.
Jetzt hast du ja vorgeschlagen ein Split-DNS zu nutzen. So wie ich das verstanden habe, reicht es wenn ich im DNS-Resolver auf der Pfsense einen Domain Override anlege und die domain example.com auf die webserver IP 192.168.4.101 verweisen lasse.
Leider macht das bei mir keinen Unterschied.. über DNS kann ich den Webserver vom LAN aus nach wie vor nicht erreichen.
Habe ich an der stelle etwas falsch verstanden, etwas vergessen, oder geht das so einfach nicht.
NAT Reflection würde ich, wie von dir ja bereits geraten, gerne vermeiden.
EDIT:
Ich glaube ich habe den Fehler gefunden..
Ich habe versucht die DNS via Domain Overrides im DNS Resolver anzusprechen..
Als ich das ganze via Host Overrides versucht habe, scheint es zu funktionieren...
Der vorherige Weg schien mir zwar irgendwie logischer,.. wenn es jetzt aber funktioniert freut es mich trotzdem ;)
Ich habe nur leider noch immer das Problem mit dem DNS_Probe.
DMZ: 192.168.4.0/24
Webserver: 192.168.4.101/24 Port 80 -- Public IP 2.2.2.2/32
LAN: 192.168.1.0/24
A-Record example.com : 2.2.2.2
Surfe ich vom Smartphone (ohne wlan) auf example.com wird der webserver angesteuert.
Surfe ich vom LAN auf example.com wird die DNS nicht aufgelöst (würde ja im Kreis gehen)
Die IP 192.168.4.101 ist aber vom LAN aus pingbar und über http://192.168.4.101:80 lässt sich auch der Webserver aufrufen.
Jetzt hast du ja vorgeschlagen ein Split-DNS zu nutzen. So wie ich das verstanden habe, reicht es wenn ich im DNS-Resolver auf der Pfsense einen Domain Override anlege und die domain example.com auf die webserver IP 192.168.4.101 verweisen lasse.
Leider macht das bei mir keinen Unterschied.. über DNS kann ich den Webserver vom LAN aus nach wie vor nicht erreichen.
Habe ich an der stelle etwas falsch verstanden, etwas vergessen, oder geht das so einfach nicht.
NAT Reflection würde ich, wie von dir ja bereits geraten, gerne vermeiden.
EDIT:
Ich glaube ich habe den Fehler gefunden..
Ich habe versucht die DNS via Domain Overrides im DNS Resolver anzusprechen..
Als ich das ganze via Host Overrides versucht habe, scheint es zu funktionieren...
Der vorherige Weg schien mir zwar irgendwie logischer,.. wenn es jetzt aber funktioniert freut es mich trotzdem ;)

Zitat von @KernelMaker:
Eine richtige DMZ hat zwei Router/Firewalls im besten Falle von unterschiedlichen Herstellern, was zuhause ebenfalls nicht gegeben ist.
Nicht ganz richtig. Eine DMZ ist erstmal ein eigenes Netzwerksegment. Wie du dies bewerkstelligst, ist dann wieder eine Designentscheidung.Eine richtige DMZ hat zwei Router/Firewalls im besten Falle von unterschiedlichen Herstellern, was zuhause ebenfalls nicht gegeben ist.
Man hätte hier das Netzwerk auch anders nennen können. "Netzwerk mit Servern die ein 1:1 NAT oder Portforwarding haben".
Server sollten immer von den Clients abgetrennt sein. Also ist das Terminieren, des Client-VPN-Tunnels in ein Servernetzwerk ein absolutes Unding. Also das, was die Leute sonst schön ins LAN rein konfigurieren.
Von welchen Leuten sprichst du? Meinst du die Personen, die Begriffe wie "Heimnetzwerk" oder "gemonitort" erfunden haben?
Sorry wenn ich meine Frage quasi wiederhole.
Wenn ich kein 1:1 Nat mache, was ja bedeute sämtliche Ports gehen an einen Client, sondern quasi die 2.2.2.2 der pfSense zuweise, so könnte ich doch NAT an einzelne Clients machen im Endeffekt wie ich es vorher auch hatte.
Higher Port auf Gerät forwarden, wie einem einzelnen Shelly etc
Edit: wg0: error fetching interface information: Device not found
Das sollte auch nicht kommen, oder?
Wenn ich kein 1:1 Nat mache, was ja bedeute sämtliche Ports gehen an einen Client, sondern quasi die 2.2.2.2 der pfSense zuweise, so könnte ich doch NAT an einzelne Clients machen im Endeffekt wie ich es vorher auch hatte.
Higher Port auf Gerät forwarden, wie einem einzelnen Shelly etc
Edit: wg0: error fetching interface information: Device not found
Das sollte auch nicht kommen, oder?
Habe das Skript jetzt mit meinen Daten angepasst, aber es kommt dann immer folgender Fehler beim starten:
Was mache ich denn falsch?
Wireguard configuration parameters missing.
#!/bin/bash
tun_if="wg0"
local_ip6=""
tun_local_addr6=""
tun_remote_addr6=""
public_ip6=( )
Was mache ich denn falsch?
Wireguard configuration parameters missing.
#!/bin/bash
- Configuration file for tunnel.sh #
- Interfaces #
tun_if="wg0"
- Addresses #
- Public IP used for tunnel. Should be the main IP of your VPS
- Tunnel IP + network
- Tunnel IP of your home router
- IPv6 settings #
local_ip6=""
tun_local_addr6=""
tun_remote_addr6=""
- MTU setting #
- GRE: Should be 1476 for normal ethernet WAN and 1468 for PPPoE connections
- WG: 1420 is default for Wireguard
- Public IP(s) #
- Define your public IPs that will be routed to your home router
- Use an array ( "IP1/CIDR" "IP2 "IP3" ... )
public_ip6=( )
Zitat von @KernelMaker:
Wichtig für mich wäre halt nur, ob man zwingend 2 Interfaces auf den VPS benötigt (und den Tunnel)
Braucht man nicht! Wo hast du das denn gelesen? Selbst wenn du 100 IPs buchst, werden die alle als Alias der vorhandenen NIC zugeordnet.
Theoretisch müsste es dann ja gehen ohne extra eine weitere teure IPv4 zu ordern.
Buch' doch einfach die zweite IPv4. So ist es hier beschrieben worden. Das kostet dich 1-2€.
Ist nicht die Welt...
Wie schon gesagt, wird das ohne NAT auf der VPS Seite nicht funktionieren, wenn die Haupt-IPv4 für den VPS selbst in Verwendung ist.
Eine Lösung wäre die Verwendung von IPv6-only auf dem VPS. Dann kannst du die erste/einzige IPv4 durch den Tunnel routen.
Beachte aber, dass damit der VPS nur noch über IPv6 erreichbar ist, was für Fehleranalysen oder für SSH Zugriffe von IPv6-unfähigen Geräten/Anschlüssen schwierig wird.
Müsstest du mal ausprobieren, ob das so in pfsense funktioniert. Ich bin mir nämlich nicht sicher, ob man Proxy ARP oder einen IP Alias ohne konfiguriertes IPv4 ans Laufen kriegt.
Unter Ubuntu geht das. Das habe ich gerade mal ausprobiert.
Zitat von @fnbalu:
Ich stelle mir schon die Frage, wie ich dort am VPS eine zweite Netzwerkkarte erstelle und dieser IPv6 zuweise.
Wieso eine zweite? Du konfigurierst einfach für die einzige Netzwerkkarte IPv4 und IPv6. Das geht alles auf dem selben Screen in pfsense. Wie das korrekt gemacht wird, vor allem in Bezug auf Gateway und evtl. Routen, erfährst du beim Provider. Das steht alles in den FAQ/Wiki Pages.Ich stelle mir schon die Frage, wie ich dort am VPS eine zweite Netzwerkkarte erstelle und dieser IPv6 zuweise.
Wichtig für mich wäre halt nur, ob man zwingend 2 Interfaces auf den VPS benötigt (und den Tunnel)
Theoretisch müsste es dann ja gehen ohne extra eine weitere teure IPv4 zu ordern.
Ist nicht die Welt...
Wie schon gesagt, wird das ohne NAT auf der VPS Seite nicht funktionieren, wenn die Haupt-IPv4 für den VPS selbst in Verwendung ist.
Eine Lösung wäre die Verwendung von IPv6-only auf dem VPS. Dann kannst du die erste/einzige IPv4 durch den Tunnel routen.
Beachte aber, dass damit der VPS nur noch über IPv6 erreichbar ist, was für Fehleranalysen oder für SSH Zugriffe von IPv6-unfähigen Geräten/Anschlüssen schwierig wird.
Müsstest du mal ausprobieren, ob das so in pfsense funktioniert. Ich bin mir nämlich nicht sicher, ob man Proxy ARP oder einen IP Alias ohne konfiguriertes IPv4 ans Laufen kriegt.
Unter Ubuntu geht das. Das habe ich gerade mal ausprobiert.
Zunächst vielen Dank für die Anleitung!
Mich würde sehr interessieren was du unter Ubuntu noch gebraucht hast um den das zu ermöglichen. Ich habe exakt den gleichen Case. 1x IPv6 Public IP und eine 1x IPv4 IP die ich dann als öffentliche IP nutzen möchte. Mein Tunnel via Wireguard steht schon über IPv6, mir fehlt aber noch 1 oder 2 Puzzelteile damit meine IPv4 durch den Tunnel gejagt wird
Zitat von @KernelMaker:
Eigentlich steht hier alles beschrieben.
Mehr habe ich nicht machen müssen.
Was geht denn nicht?
Eigentlich steht hier alles beschrieben.
Mehr habe ich nicht machen müssen.
Was geht denn nicht?
Ich habe eine IPv6 Adresse über die ich mich via WireGuard zu meinen Server verbinde. Auf diesem ist meine Public V4 Adresse nicht konfiguriert da ich diese nutzen möchte. Was mir nun unklar ist, ich sage in der WireGuard Config welche Public IP zu binden ist. Wie kommt jetzt aber das Routing zustande? Woher weiss mein Server das diese IPv4 Adresse von aussen erreichbar sein soll und durch den Tunnel zu mir nach Hause soll?
Zitat von @KernelMaker:
Eine Lösung wäre die Verwendung von IPv6-only auf dem VPS. Dann kannst du die erste/einzige IPv4 durch den Tunnel routen.
Eine Lösung wäre die Verwendung von IPv6-only auf dem VPS. Dann kannst du die erste/einzige IPv4 durch den Tunnel routen.
Das war im übrigen der konkrete Satz auf den ich mich beziehen wollte
Ich hoffe es ist etwas klarer geworden was ich meine. Ich habe irgendwie erwartet das du auf Ubuntu noch manuell eine Route hinzugefügt hast, damit der WireGuard Tunnel weiss wie die IP zu routen ist und auch welches Gateway genutzt werden soll, bei dem IPv6 only VPS + Single IPv4 Address Szenario.