39Feste 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-toolsPacket-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 -pMein 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.shWireGuard Keys generieren und in Dateien speichern
wg genkey | tee privatekey | wg pubkey > publickeyMit
cat privatekeyAuf 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. downPfsense 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
EingehendAusgehend
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!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease 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.
Zitat von @148656:
Moin,
die Funktion/Aufgabe einer DMZ ist dir bekannt?
Deine "Sternchenregel" solltest du nochmal überarbeiten.
Gruß
C.C.
Moin,
die Funktion/Aufgabe einer DMZ ist dir bekannt?
Deine "Sternchenregel" solltest du nochmal überarbeiten.
Gruß
C.C.
selbstverständlich ist mir das bekannt.
Um das ganze für die Anleitung einfach zu halten, ist das erstmal völlig ausreichend.
Natürlich macht es Sinn, auch ausgehenden Traffic einzuschränken.
1
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.
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".
Also das, was die Leute sonst schön ins LAN rein konfigurieren.
Man hätte hier das Netzwerk auch anders nennen können. "Netzwerk mit Servern die ein 1:1 NAT oder Portforwarding haben".
Also das, was die Leute sonst schön ins LAN rein konfigurieren.
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
2
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.
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.
1
Die zweite IP würde 1€ kosten, überschaubar.
Und die wird dann einfach mit der ersten zugeordnet?
Geht das denn bei pfSense dann?
Später mal soll der Tunnel selbst wahrscheinlich über v6 laufen, falls abends der CG-Nat überlastet ist
Und die wird dann einfach mit der ersten zugeordnet?
Geht das denn bei pfSense dann?
Später mal soll der Tunnel selbst wahrscheinlich über v6 laufen, falls abends der CG-Nat überlastet ist
Ja genau. Das Funktioniert.
Näheres kann wohl Christian mitteilen, da er ebenfalls pfsense auf dem VPS bei Hetzner einsetzt.
Frag ihn doch mal.
Näheres kann wohl Christian mitteilen, da er ebenfalls pfsense auf dem VPS bei Hetzner einsetzt.
Frag ihn doch mal.
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
Ja das ist richtig.
Die zweite entfernst du dann vom WAN Interface und setzt Proxy ARP für diese Adresse.
Die zweite entfernst du dann vom WAN Interface und setzt Proxy ARP für diese Adresse.
Gut, dann werde ich im nächsten Step erstmal die zweite buchen und dann sehen wie das in pfSense umsetzbar ist und ob überhaupt.
Ging ja erstmal darum nicht unnötig Geld zu verbrennen.
IP kostet Einrichtungsgebühr und jährliche Zahlweise. Ist nicht wie beim VPS
Ging ja erstmal darum nicht unnötig Geld zu verbrennen.
IP kostet Einrichtungsgebühr und jährliche Zahlweise. Ist nicht wie beim VPS
Ach so, das wusste ich nicht.
Bei meinem Hoster zahle ich monatlich 1€ wie für den VPS.
Dann versuch doch erstmal die IPv6-only Sache. Die Haupt-IPv4 bleibt dann frei.
Bei meinem Hoster zahle ich monatlich 1€ wie für den VPS.
Dann versuch doch erstmal die IPv6-only Sache. Die Haupt-IPv4 bleibt dann frei.
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.
1Zitat 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.
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).
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).
Genau genommen sind die Adressen schon lange ausgegangen ;)
Es gibt keine freie IPv4 mehr.
Zumindest bei Myloc ist alles wie immer.
Da kriegt man sogar ganze Subnetze. Natürlich nur mit Vorlage von Gründen, wie immer.
Die Umsetzung mit einer IPv4 gestaltet sich aber mit etwas mehr Konfigurationsaufwand, weil man nicht eine komplette /32 Route für die IP machen kann. Der Port für den WireGuard Server und am besten SSH können nicht weitergeleitet werden. Dann müsste man einzelne Ports bzw. Ranges in den Tunnel weiterleiten.
EDIT:
Will man nur einen einzelnen Port fürs NAS oder den Raspi zuhause haben, reicht sowas natürlich.
Das wäre dann der gleiche Ansatz wie bei feste-ip wo man einzelne Ports zugewiesen bekommt.
Das wollte ich bei meinem Ansatz auf jeden Fall vermeiden, weil dann Regeln auf dem VPS eingestellt werden müssen und dann Traffic VPS != Traffic pfsense ist.
Aber für den Server selbst und WireGuard könnte man ja wie schon gesagt IPv6 nutzen. Und die IPv4 ausschließlich für zuhause routen.
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.2Surfe 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? 
Zitat von @148656:
Von welchen Leuten sprichst du? Meinst du die Personen, die Begriffe wie "Heimnetzwerk" oder "gemonitort" erfunden haben?
Von welchen Leuten sprichst du? Meinst du die Personen, die Begriffe wie "Heimnetzwerk" oder "gemonitort" erfunden haben?
Genau die meine ich ;)
Dort heißt Exposed Host auch = DMZ
Zitat von @dschense:
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 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 ;)
Genau, das geht über Host Overrides
Da trägst du dann jede Domain + Subdomains mit dem passenden Webserver ein.
Und NAT Reflection natürlich am besten global abschalten.
Ich verwerfe jetzt gerade den pfSense Gedanken als VPS. Es ist zwar alles da, aber ich bekomme die Forwards nicht hin.
Ist bei Linux eigentlich egal, wo die config.sh und die tunnel.sh hingeschoben werden???
Ist bei Linux eigentlich egal, wo die config.sh und die tunnel.sh hingeschoben werden???
Ja ist egal. Nur als Root ausführen ist wichtig.
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?
Hi, geht der Aufbau auch mit Opnsense? Kann mir jemand noch guten VPS Anbieter empfehlen, jetzt wollen sie ja schon 2€ pro fester IP?.
Das geht genauso mit opnsense.
Wie schon mehrmals hier geschrieben, eine Empfehlung gibt es da nicht. Du solltest einen guten Anbieter durch Testen herausfinden.
Es sollte eine schnelle Verbindung von deinem Anschluss zuhause bis zum Hoster geben. Und das kann dir niemand beantworten.
Im Raum NRW ist MyLoc in Düsseldorf eine gute Wahl. Vor allem bei Telekom, weil die ein direktes Peering haben.
Im Süden ist Frankfurt die erste Wahl. Dort gibt es quasi unbegrenzte Auswahl an Hostern.
Außerdem gibt es noch Hetzner im Raum Nürnberg bzw. Falkenstein.
Wie schon mehrmals hier geschrieben, eine Empfehlung gibt es da nicht. Du solltest einen guten Anbieter durch Testen herausfinden.
Es sollte eine schnelle Verbindung von deinem Anschluss zuhause bis zum Hoster geben. Und das kann dir niemand beantworten.
Im Raum NRW ist MyLoc in Düsseldorf eine gute Wahl. Vor allem bei Telekom, weil die ein direktes Peering haben.
Im Süden ist Frankfurt die erste Wahl. Dort gibt es quasi unbegrenzte Auswahl an Hostern.
Außerdem gibt es noch Hetzner im Raum Nürnberg bzw. Falkenstein.
Suche erstmal nur was günstiges zum testen, aber zwei feste IPs brauche ich ja auf jedenfall erstmal oder?
Korrekt.
Günstig sind erstmal OVH und Hetzner. Die bieten Stundenabrechnung.
Günstig sind erstmal OVH und Hetzner. Die bieten Stundenabrechnung.
Wie kann ich denn eine feste IP dann auf der pfsense selber nutzen, zum Beispiel für HA Proxy?
Mit HA Proxy habe ich noch nicht gearbeitet.
Aber HA Proxy wird doch auch Virtual IPs können oder?
Daher sollte der Wireguard Tunnel problemlos funktionieren.
Aber HA Proxy wird doch auch Virtual IPs können oder?
Daher sollte der Wireguard Tunnel problemlos funktionieren.
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=( )
Keiner eine Idee?
Hab dir ne PN geschickt. Die Datei oben ist übrigens nicht vollständig kopiert z.B. fehlt unten der Wireguard part. Daher nicht wirklich hilfreich.
Ein kleines Update...
Ich habe mal testweise den gesamten Internet-Traffic über den Tunnel geschickt.
Der ursprüngliche Plan war die Buchung einer zweiten Internet-Leitung für doppelte Bandbreite bei weiterhin einer einzelnen IP im Internet. Also echtes Bonding statt Multi-WAN.
Generell funktioniert das aufgrund der hervorragenden Anbindung des Hosters ziemlich gut. Durch das schlechte Peering im Telekom Backbone gibt es deutliche Unterschiede. Seiten laden deutlich fixer, weil viele URLs, DNS-Anfragen etc. einfach schneller durch laufen.
Hier mal als Beispiel ein Traceroute zu Cloudflare:
Leider habe ich den Aufbau nun trotzdem wieder zurückgeschraubt. Denn viele Anbieter sind mittlerweile richtig gut darin, ein VPN zu erkennen bzw. blacklisten einfach ganze IP-Ranges. So auch in meinem Fall, Beispiele:
Primär treten Probleme über IPv6 auf, weil hier die komplette /28 Route des Hosters als "ein Absender" gilt. Das beinhaltet dann natürlich tausende Server.
Bei IPv4 sind die Netze deutlich kleiner z.B. /22 oder /24.
Das würde unterm Strich bedeuten, dass man weiterhin fleißig mit dem Erstellen von Bypass Regeln beschäftigt ist, damit gewissen Dienste trotzdem nutzbar bleiben.
Daher bleibt hierbei nur ein eigenes Subnetz von der RIPE am besten inkl. AS zu bekommen oder einen so kleinen Hoster zu wählen, dass Anbieter diesen nicht als unerwünscht einstufen.
Schade!
Ich habe mal testweise den gesamten Internet-Traffic über den Tunnel geschickt.
Der ursprüngliche Plan war die Buchung einer zweiten Internet-Leitung für doppelte Bandbreite bei weiterhin einer einzelnen IP im Internet. Also echtes Bonding statt Multi-WAN.
Generell funktioniert das aufgrund der hervorragenden Anbindung des Hosters ziemlich gut. Durch das schlechte Peering im Telekom Backbone gibt es deutliche Unterschiede. Seiten laden deutlich fixer, weil viele URLs, DNS-Anfragen etc. einfach schneller durch laufen.
Hier mal als Beispiel ein Traceroute zu Cloudflare:
1 xxx.dip0.t-ipconnect.de (62.155.xxx.xxx) 1.138 ms 0.975 ms 0.869 ms
2 xxx-i.x.DE.NET.DTAG.DE (62.154.xxx.xxx) 4.515 ms 4.684 ms 4.916 ms
3 xxx-i.x.DE.NET.DTAG.DE (62.154.xx.xxx) 4.080 ms 4.098 ms 4.086 ms
4 4.68.71.113 (4.68.71.113) 12.676 ms 12.579 ms 12.497 ms
5 CLOUDFLARE.edge6.Dusseldorf1.Level3.net (62.67.22.246) 11.835 ms 11.755 ms 11.992 ms
6 one.one.one.one (1.1.1.1) 12.962 ms 12.521 ms 13.433 ms1 172.31.xxx.xxx (172.31.xxx.xxx) 3.885 ms 3.012 ms 3.070 ms
2 xxxx-xxxxx.agr1-dus6-vz.bb.as24961.net (89.163.xxx.xxx) 5.064 ms 4.990 ms 4.958 ms
3 po12.core3-dus1.bb.as24961.net (62.141.47.22) 3.080 ms 3.135 ms 3.679 ms
4 as13335.dusseldorf.megaport.com (194.146.118.139) 4.050 ms 3.769 ms 4.498 ms
5 one.one.one.one (1.1.1.1) 3.238 ms 4.027 ms 3.380 msLeider habe ich den Aufbau nun trotzdem wieder zurückgeschraubt. Denn viele Anbieter sind mittlerweile richtig gut darin, ein VPN zu erkennen bzw. blacklisten einfach ganze IP-Ranges. So auch in meinem Fall, Beispiele:
- Google zeigt selbst bei einer normalen Suche Captchas
- Netflix zeigt nur Eigenproduktionen an (also etwa 5% des Inhalts), weil die IP nicht Deutschland zugeordnet werden kann (und das obwohl die Geolocation eindeutig Düsseldorf zeigt)
Primär treten Probleme über IPv6 auf, weil hier die komplette /28 Route des Hosters als "ein Absender" gilt. Das beinhaltet dann natürlich tausende Server.
Bei IPv4 sind die Netze deutlich kleiner z.B. /22 oder /24.
Das würde unterm Strich bedeuten, dass man weiterhin fleißig mit dem Erstellen von Bypass Regeln beschäftigt ist, damit gewissen Dienste trotzdem nutzbar bleiben.
Daher bleibt hierbei nur ein eigenes Subnetz von der RIPE am besten inkl. AS zu bekommen oder einen so kleinen Hoster zu wählen, dass Anbieter diesen nicht als unerwünscht einstufen.
Schade!
1
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
Eigentlich steht hier alles beschrieben.
Mehr habe ich nicht machen müssen.
Was geht denn nicht?
Mehr habe ich nicht machen müssen.
Was geht denn nicht?
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.
Tolles Tut. Danke dafür. Habe ein ähnliches Setup laufen mit SSL-VPN und einer UTM von Securepoint.
Läuft super. Nur habe ich mittels iptables den Traffic in meinen Tunnel umleiten müssen.
Diesen Hinweis vermisse ich in deinem Tutorial. Oder wird das mit WG anders geregelt??
Läuft super. Nur habe ich mittels iptables den Traffic in meinen Tunnel umleiten müssen.
Diesen Hinweis vermisse ich in deinem Tutorial. Oder wird das mit WG anders geregelt??
Zitat von @Ueba3ba:
Nur habe ich mittels iptables den Traffic in meinen Tunnel umleiten müssen.
Diesen Hinweis vermisse ich in deinem Tutorial. Oder wird das mit WG anders geregelt??
Nur habe ich mittels iptables den Traffic in meinen Tunnel umleiten müssen.
Diesen Hinweis vermisse ich in deinem Tutorial. Oder wird das mit WG anders geregelt??
Wireguard macht das automatisch.
Du kannst auch im GRE-Tutorial gucken. Da sind die Routen beschrieben.
