71
Feste IPs zu Hause über WireGuard-Tunnel in pfSense einrichten
Ich habe bereits vor einiger Zeit eine Anleitung zur Einrichtung eines GRE Tunnels erstellt (Feste IPs zu Hause über GRE-Tunnel in pfSense einrichten). Es ist zum Verständnis durchaus hilfreich, auch einen Blick auf die GRE Anleitung zu werfen.
Wie Sie feste öffentliche IP-Adressen für Ihre Serverdienste (Exchange, Webserver, Gameserver etc.) in einer Heimumgebung nutzen können, obwohl Ihr privater Internetanschluss nur über eine dynamische WAN-Adresse verfügt.
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.
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
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
Pfsense Seite
Packages
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.
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).
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.
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
store.servdiscount.com/de/configurate/5456
2 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 20.04 LTS
Heim Router (Selbstbau)
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.
Zusammenfassung
Die monatlichen Gesamtkosten liegen bei 5€ + 1€ für jede öffentliche IP bzw. +8€ für ein /29 Subnetz.
Viel Spaß beim Nachbauen!
Wie Sie feste öffentliche IP-Adressen für Ihre Serverdienste (Exchange, Webserver, Gameserver etc.) in einer Heimumgebung nutzen können, obwohl Ihr privater Internetanschluss nur über eine dynamische WAN-Adresse verfügt.
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
EinleitungDie 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 SeiteFü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. downEinen 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.
RoutingHier 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.
FirewallAußerdem noch Regeln zum Blockieren von Traffic zu weiteren Interfaces bei euch zuhause.
NATDie 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
TestTraceroute TestAusgehend
Performance TestAuch 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 IPBei 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.
HardwaremyLoc VPS2 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 20.04 LTS
Heim Router (Selbstbau)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.
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.
ZusammenfassungWeitere 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!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1124828094
Url: https://administrator.de/tutorial/feste-ips-zu-hause-ueber-wireguard-tunnel-in-pfsense-einrichten-1124828094.html
Ausgedruckt am: 05.07.2025 um 22:07 Uhr
71 Kommentare
Neuester Kommentar
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.
Was mache ich denn falsch?
Wireguard configuration parameters missing.
#!/bin/bash
####################################
# Configuration file for tunnel.sh #
####################################
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="X:X:X:X"
# 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=( "X.X.X.X/32" )
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.
Hey Servus. Hab auf dem vPS Ubuntu 20.04 installiert.
Wollte eben dein Script ausführen und bekomme folgende Meldung zurück:
Was da los?
Beide Dateien: config.sh und tunnel.sh liegen im selben Verzeichnis.
Wollte eben dein Script ausführen und bekomme folgende Meldung zurück:
root@localhost:~# sh tunnel.sh
tunnel.sh: 3: source: not found
tunnel.sh: 8: [[: not found
tunnel.sh: 10: [[: not found
tunnel.sh: 13: [[: not found
tunnel.sh: 21: Syntax error: "(" unexpected Was da los?
Beide Dateien: config.sh und tunnel.sh liegen im selben Verzeichnis.
Der Fehler: Das Script muss erst noch ausführbar gemacht werden.
chmod +x tunnel.shZitat von @Ueba3ba:
Der Fehler: Das Script muss erst noch ausführbar gemacht werden.
Der Fehler: Das Script muss erst noch ausführbar gemacht werden.
chmod +x tunnel.shOder mit bash … ausführen. Das hätte auch geklappt.
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
Es ist aber dann auch möglich in den DMZ Rules nur bestimmte Ports freizugeben oder verstehe ich das falsch?
Eingehende Regel meine ich.
Klar, man kann auch nur DNAT für einzelne Ports zur IP in der DMZ auf dem WG-Interface machen.
Genau das meinte ich. Ich möchte erst mal nur SMTP Verkehr zulassen. Leider hab ich noch keine Erfahrung mit der opnSense, Hab mal kurz reingeschaut, das wars auch schon.
Bei meinem jetzigen Setup mit dem SSL-Tunnel, forwarde ich mit iptables Traffic, der an Port 25 ankommt,
an eine hinter dem Tunnel interne IP.
Das würde ja mit dem WG Tunnel wegfallen.
Auch beim jetzigen Setup habe ich auf der UTM eine Rule die Traffic, der vom Tunnel Interface kommt
und an die Server-Ip gerichtet ist, erlaubt.
Das müsste mit dem WG Tunnel eingerichtet werden.
Wird das in der OpnSense bei: Firewall / Rules / IP_TUNNEL, Firewall / Rules / DMZ oder
bei Firewall / NAT / 1:1 / edit eingerichtet?
Bei meinem jetzigen Setup mit dem SSL-Tunnel, forwarde ich mit iptables Traffic, der an Port 25 ankommt,
an eine hinter dem Tunnel interne IP.
Das würde ja mit dem WG Tunnel wegfallen.
Auch beim jetzigen Setup habe ich auf der UTM eine Rule die Traffic, der vom Tunnel Interface kommt
und an die Server-Ip gerichtet ist, erlaubt.
Das müsste mit dem WG Tunnel eingerichtet werden.
Wird das in der OpnSense bei: Firewall / Rules / IP_TUNNEL, Firewall / Rules / DMZ oder
bei Firewall / NAT / 1:1 / edit eingerichtet?
Nachtrag:
Wireguatd Tunnel steht und funktioniert.
Es ist ein Host am Internal Interface angeschloßen, zum testen.
Was auch funktioniert ist, über die Rules den Traffic über meinen Internet-Anschluß oder über den Tunnel zu schicken.
Wunderbar!
Was ich noch nicht hinbekommen habe ist, meine zweite Puplic IP von außen zu erreichen.
Vom Host, der am Internal Interface hängt, erreiche ich die zweite IP. Dann kommt die GUI der opnSense.
Ich möchte die zweite erst mal nur für SMTP nutzten.
1:1 Nat brauche ich nicht und ist auch nicht konfiguriert.
Eventuell hat ja wer einen Anstoß für mich.
Wireguatd Tunnel steht und funktioniert.
Es ist ein Host am Internal Interface angeschloßen, zum testen.
Was auch funktioniert ist, über die Rules den Traffic über meinen Internet-Anschluß oder über den Tunnel zu schicken.
Wunderbar!
Was ich noch nicht hinbekommen habe ist, meine zweite Puplic IP von außen zu erreichen.
Vom Host, der am Internal Interface hängt, erreiche ich die zweite IP. Dann kommt die GUI der opnSense.
Ich möchte die zweite erst mal nur für SMTP nutzten.
1:1 Nat brauche ich nicht und ist auch nicht konfiguriert.
Eventuell hat ja wer einen Anstoß für mich.
Nachtrag2:
Funktioniert nun alles wie ich es mir vorgestellt habe.
Ich kann das ganze jetzt blind konfigurieren so oft wie ich das am Wochenende immer wieder neu aufgesetzt habe.
Ich mach immer wieder den selben fehler: Ich vergesse immer die Firewall bei meinen vServer Hoster.
Da müssen auch Ports freigegeben werden
Passiert aber jetzt net mehr so schnell.
Noch mal Danke an den Author für das Tut.
Funktioniert nun alles wie ich es mir vorgestellt habe.
Ich kann das ganze jetzt blind konfigurieren so oft wie ich das am Wochenende immer wieder neu aufgesetzt habe.
Ich mach immer wieder den selben fehler: Ich vergesse immer die Firewall bei meinen vServer Hoster.
Da müssen auch Ports freigegeben werden
Passiert aber jetzt net mehr so schnell.
Noch mal Danke an den Author für das Tut.
Hallo zusammen,
erstmal vielen Dank an @KernelMaker, dass du dir die Mühe gemacht hast, die beiden Konfigurationen für "Feste IPs zuhause in pfsense via [GRE|WireGuard] Tunnel" zu dokumentieren und dazu sogar noch zwei Scripte zu verfassen!
Den vielen Postings entnehme ich, dass es prinzipiell damit auch funktioniert.
Deine erste Doku für GRE-Tunnel konnte ich problemlos nachvollziehen und zum Laufen bekommen - und das alles auch ohne die beiden Skripte zu bemühen.
Aber an der zweiten via WireGuard beiße ich mir irgendwie die Zähne aus, wenn ich deiner obigen Beschreibung genau folge. Irgenwie scheinen da noch ein paar Zwischenschritte für Wireguard zu fehlen, bevor man das Skript tunnel.sh erfolgreich ausführen kann.
Klar, ich habe /etc/wireguard angelegt, darin die private und public keys generiert und die Rechte angepasst. In der config.sh habe ich die entsprechenden Einträge geändert und meine IP-Adressen eingesetzt.
Führe ich die tunnel.sh dann aus, erhalte ich nur ein "Wireguard configuration parameters missing.".
Doch was fehlt weiß ich nicht. Also habe ich mal testweise eine wg0.conf mit folgendem Content angelegt:
Aber auch damit erhalte ich nach dem Ausführen von tunnel.sh noch die gleiche Fehlermeldung.
Eigentlich hatte ich gehofft, dass mir das Script die Arbeiten, die ich beim GRE-Tunnel manuell nach der Anleitung von @KernelMaker durchgeführt habe, abnehmen würde. Aber das war wohl nichts.
Also habe ich zwei Fragen an euch:
Vielleicht könnte jemand von euch ja mal seine wg0.conf posten?
Danke für euer Feedback!
Grüße
moosehead
PS Systeme: Debian 12 bookworm und OPNsense 23.1.11
erstmal vielen Dank an @KernelMaker, dass du dir die Mühe gemacht hast, die beiden Konfigurationen für "Feste IPs zuhause in pfsense via [GRE|WireGuard] Tunnel" zu dokumentieren und dazu sogar noch zwei Scripte zu verfassen!
Den vielen Postings entnehme ich, dass es prinzipiell damit auch funktioniert.
Deine erste Doku für GRE-Tunnel konnte ich problemlos nachvollziehen und zum Laufen bekommen - und das alles auch ohne die beiden Skripte zu bemühen.
Aber an der zweiten via WireGuard beiße ich mir irgendwie die Zähne aus, wenn ich deiner obigen Beschreibung genau folge. Irgenwie scheinen da noch ein paar Zwischenschritte für Wireguard zu fehlen, bevor man das Skript tunnel.sh erfolgreich ausführen kann.
Klar, ich habe /etc/wireguard angelegt, darin die private und public keys generiert und die Rechte angepasst. In der config.sh habe ich die entsprechenden Einträge geändert und meine IP-Adressen eingesetzt.
Führe ich die tunnel.sh dann aus, erhalte ich nur ein "Wireguard configuration parameters missing.".
Doch was fehlt weiß ich nicht. Also habe ich mal testweise eine wg0.conf mit folgendem Content angelegt:
//# define the WireGuard service
[Interface]
# contents of file private.key
PrivateKey = <privat halt>
# UDP service port
ListenPort = 41194
//Aber auch damit erhalte ich nach dem Ausführen von tunnel.sh noch die gleiche Fehlermeldung.
Eigentlich hatte ich gehofft, dass mir das Script die Arbeiten, die ich beim GRE-Tunnel manuell nach der Anleitung von @KernelMaker durchgeführt habe, abnehmen würde. Aber das war wohl nichts.
Also habe ich zwei Fragen an euch:
- wie komme ich nun weiter (d.h. welche Vorarbeiten sind erforderlich, damit sich da Script audführen lässt) und
- wozu brauche ich das Script tunnel.sh dann überhaupt, wenn ich doch vorher alles oder vieles "zu Fuss" machen muss?
Vielleicht könnte jemand von euch ja mal seine wg0.conf posten?
Danke für euer Feedback!
Grüße
moosehead
PS Systeme: Debian 12 bookworm und OPNsense 23.1.11
Hi, hast du dir denn das Template wie in der Anleitung beschrieben erstellt?
In Zeile 301 findest du die Prüfung
Eine von den Variablen scheint leer zu sein oder das Skript hat einen Bug ;)
In Zeile 301 findest du die Prüfung
elif [[ "$tun_proto" == "wg" && (-z "$config" || -z "$listenPort" || -z "$privateKey" || -z "$publicKey") ]]; then
echo "${yellow}Wireguard configuration parameters missing.${normal}"
exitEine von den Variablen scheint leer zu sein oder das Skript hat einen Bug ;)
Sorry, aber von einem Template habe ich beiden Anleitungen nichts gefunden/gelesen.
Ich habe die config_sample.sh in config.sh umbenannt und editiert, so wie es auch im Text steht.
Dass das Script einen Bug hat glaube ich nicht, denn sonst hätten die anderen sich ja auch schon gerührt. Aber die scheinen es damit ja hinbekommen zu haben!
Ich habe die config_sample.sh in config.sh umbenannt und editiert, so wie es auch im Text steht.
Dass das Script einen Bug hat glaube ich nicht, denn sonst hätten die anderen sich ja auch schon gerührt. Aber die scheinen es damit ja hinbekommen zu haben!
config_sample.sh = Template
wenn du das bearbeitet hast, passt es.
irgendeine der Variablen muss leer sein. Überprüfe noch einmal deine Config.
Außerdem:
Ist /etc/wireguard vorhanden?
Ist der user root oder hat zumindest permissions für /etc/wireguard und die Software wireguard?
Alternativ schick mir mal deine Config per PN oder poste sie hier (vorher sensible Daten entfernen)
wenn du das bearbeitet hast, passt es.
irgendeine der Variablen muss leer sein. Überprüfe noch einmal deine Config.
Außerdem:
Ist /etc/wireguard vorhanden?
Ist der user root oder hat zumindest permissions für /etc/wireguard und die Software wireguard?
Alternativ schick mir mal deine Config per PN oder poste sie hier (vorher sensible Daten entfernen)
So, bin wieder ein Stück weiter. Also, das Script bricht immer wieder ab, weil sich die OPNsense nicht anpingen lässt.
Daher habe ich jetzt die VPS und die OPNsense mal so konfiguriert, wie hier und hier beschrieben. Ich brauchte einfach mal ein Erfolgserlebnis, denn damit läuft der Tunnel jetzt erstma rudimentär.
Auch habe ich auf der OPNsens ein paar Regeln hinzugefügt. Damit komme ich zumindest schon mal an von der VPS selbst aus an meine Maschinen in der DMZ ran.
Aber der Rückweg funktioniert überhaupt nicht (also von der DMZ in Richtung VPS). Auch wird trotz gesetzter Route auf der VPS die 2nd IP addr nicht durch den Tunnel weitergeleitet. Und Pingen kann ich die VPS selbst von der OPNsene aus auch nicht, aus der DMZ aber schon!
Auch baut die VPS zwar in Richtung OPNsense den Tunnel auf, wenn man ein Paket durchschickt, umgekehrt ist aber trotz KeepAlive von 25s auf der OPNsense nur Funkstille. Aber später kann die VPS den Tunnel ja nicht mehr aufbauen, da die OPNsense dann ja eine dyn IP bekommt.
Ich habe also gleich mehrere Probleme auf einmal.
Daher meine Frage in die Runde: hat jemand das Szenario mit Debian 12 als VPS und OPNsense 23.1(.11) vielleicht schon mal aufgesetzt und kann mir mit eine paar Screenshots behilflich sein? Denn ich habe festgestellt, dass sich die Screenshots weiter oben, die ja eine pfsense zeigen, doch in einigen Punkten von denen der OPNsense unterscheiden.
Auch habe ich gelesen, dass bei einigen von euch das auch nicht sofort auf Anhieb lief. Wie seid ihr denn vorgegangen? Habt ihr vieleicht ein paar Tipps zum Troubleshooting für mich?
Für heute mache ich jetzt erstmal schluss - muss den Kopf lüften
Grüße
moosehead
Daher habe ich jetzt die VPS und die OPNsense mal so konfiguriert, wie hier und hier beschrieben. Ich brauchte einfach mal ein Erfolgserlebnis, denn damit läuft der Tunnel jetzt erstma rudimentär.
Auch habe ich auf der OPNsens ein paar Regeln hinzugefügt. Damit komme ich zumindest schon mal an von der VPS selbst aus an meine Maschinen in der DMZ ran.
Aber der Rückweg funktioniert überhaupt nicht (also von der DMZ in Richtung VPS). Auch wird trotz gesetzter Route auf der VPS die 2nd IP addr nicht durch den Tunnel weitergeleitet. Und Pingen kann ich die VPS selbst von der OPNsene aus auch nicht, aus der DMZ aber schon!
Auch baut die VPS zwar in Richtung OPNsense den Tunnel auf, wenn man ein Paket durchschickt, umgekehrt ist aber trotz KeepAlive von 25s auf der OPNsense nur Funkstille. Aber später kann die VPS den Tunnel ja nicht mehr aufbauen, da die OPNsense dann ja eine dyn IP bekommt.
Ich habe also gleich mehrere Probleme auf einmal.
Daher meine Frage in die Runde: hat jemand das Szenario mit Debian 12 als VPS und OPNsense 23.1(.11) vielleicht schon mal aufgesetzt und kann mir mit eine paar Screenshots behilflich sein? Denn ich habe festgestellt, dass sich die Screenshots weiter oben, die ja eine pfsense zeigen, doch in einigen Punkten von denen der OPNsense unterscheiden.
Auch habe ich gelesen, dass bei einigen von euch das auch nicht sofort auf Anhieb lief. Wie seid ihr denn vorgegangen? Habt ihr vieleicht ein paar Tipps zum Troubleshooting für mich?
Für heute mache ich jetzt erstmal schluss - muss den Kopf lüften
Grüße
moosehead
So, wieder ein Stück weiter:
Das war's aber auch schon. Denn egal, was ich auf der OPNsense an inbound NAT Regeln und Regel für das WG-Interface definiere, mir schlägt stets die "default deny" Regel des WG-Interfaces zu und verwirft mir alle Pakete, die aus dem Internet an die 2. öffentlich IP-Adresse gesendet werden. D.h. sie kommen zwar über den Tunnel auf der OPNsense an, aber von dort bekomme ich sie irgenwie nicht weiter.
Falls jemand von euch einen Tipp hat, wäre ich sehr dankbar dafür!
Viele Grüße
moosehead
- Der Tunnel steht, bleibt dauerhaft offen und wird nach Reboot der VPS oder OPNsense auch automatisch wieder aufgebaut.
- ping und traceroute funktionieren in beide Richtungen, d.h. von der VPS zu Maschinen in der DMZ und umgekehrt (auf die lokale Tunnel-Adresse der VPS).
- curl und wget funktionieren von der VPS aus auf die privaten Adresse der Webserver in der DMZ
- die 2. öffentlich IP-Adresse wird zur OPNsense geroutet und die Pakete kommen dort auch an (habe eine Virtual IP dafür auf der OPNSense angelegt und an das WG-Interface gebunden), das sieht man in Live-Log.
Das war's aber auch schon. Denn egal, was ich auf der OPNsense an inbound NAT Regeln und Regel für das WG-Interface definiere, mir schlägt stets die "default deny" Regel des WG-Interfaces zu und verwirft mir alle Pakete, die aus dem Internet an die 2. öffentlich IP-Adresse gesendet werden. D.h. sie kommen zwar über den Tunnel auf der OPNsense an, aber von dort bekomme ich sie irgenwie nicht weiter.
Falls jemand von euch einen Tipp hat, wäre ich sehr dankbar dafür!
Viele Grüße
moosehead
Und noch ein Stück weiter:
Nur die eingehenden Pakete auf die 2. öffentliche IP-Adresse bekomme ich einfach nicht weiter, trotz NAT-Rule und Interface-Rule. Das Ergebnis im Live-Log ist leider immer das gleiche:
Default deny / state violation rule
Hat keiner 'ne Idee wo es noch klemmen könnte?
Grüße
mossehead
- outbound traffic von der OPNsene mit 2. öffentliche IP-Adresse über die VPS funktioniert nun auch
Nur die eingehenden Pakete auf die 2. öffentliche IP-Adresse bekomme ich einfach nicht weiter, trotz NAT-Rule und Interface-Rule. Das Ergebnis im Live-Log ist leider immer das gleiche:
Default deny / state violation rule
Hat keiner 'ne Idee wo es noch klemmen könnte?
Grüße
mossehead
N'Abend
Schau doch mal hier rein, dort wird es achön beschrieben
Routing zwischen zwei PfSense - Nutzung von public IP
Gruß siddius
Schau doch mal hier rein, dort wird es achön beschrieben
Routing zwischen zwei PfSense - Nutzung von public IP
Gruß siddius
Moosehead schau mal sonst in meinen Fragethread.
Da geht's um 2 pfsense und weiter unten wird genau erklärt warum das nicht klappt.
Das klingt so wie bei Dir
Da geht's um 2 pfsense und weiter unten wird genau erklärt warum das nicht klappt.
Das klingt so wie bei Dir
Danke für euer freundliches und schnelles Feedback, @7907292512 und @fnbalu
Ich habe jetzt beide Optionen ausprobiert, d.h.
aber nichts funktioniert - ich bringen die OPNsense einfach nicht dazu, Pakete, die an die 2te öffentliche IP-Adresse der VPS gerichtet sind und durch den WG-Tunnel zu ihr reinkommen, anzunehmen, zu NATten oder weiterzuleiten.
Falls noch jemand eine Idee hat, gerne. Ich versuch's sonst mal im OPNsene-Forum, vielleicht kann mir da ja jemand helfen oder hat diese Konfiguration mit der OPNsense schon erfolgreich umgesetzt.
Viele Grüße
moosehead
Ich habe jetzt beide Optionen ausprobiert, d.h.
- double nat
- package tagging
aber nichts funktioniert - ich bringen die OPNsense einfach nicht dazu, Pakete, die an die 2te öffentliche IP-Adresse der VPS gerichtet sind und durch den WG-Tunnel zu ihr reinkommen, anzunehmen, zu NATten oder weiterzuleiten.
Falls noch jemand eine Idee hat, gerne. Ich versuch's sonst mal im OPNsene-Forum, vielleicht kann mir da ja jemand helfen oder hat diese Konfiguration mit der OPNsense schon erfolgreich umgesetzt.
Viele Grüße
moosehead
Hi,
leider kann ich hier nicht unterstützen, da ich kein OPNsense nutze. Sorry.
leider kann ich hier nicht unterstützen, da ich kein OPNsense nutze. Sorry.
1Zitat von @moosehead:
Danke für euer freundliches und schnelles Feedback, @7907292512 und @fnbalu
Ich habe jetzt beide Optionen ausprobiert, d.h.
aber nichts funktioniert - ich bringen die OPNsense einfach nicht dazu, Pakete, die an die 2te öffentliche IP-Adresse der VPS gerichtet sind und durch den WG-Tunnel zu ihr reinkommen, anzunehmen, zu NATten oder weiterzuleiten.
Falls noch jemand eine Idee hat, gerne. Ich versuch's sonst mal im OPNsene-Forum,
Wozu NATen wenn es auch ohne geht?? Überflüssiger Overhead. Wenn keine Pakete durchgehen musst du das in der Firewall natürlich erst erlauben, das ist ja Grundvoraussetzung!! Folge den Paketen in Gedanken dann ist das mit jeder Firewall zu machen, egal ob OPNSense oder pfSense ist ja am Ende ähnlicher Unterbau nur ne andere GUI drüber gestülpt.Danke für euer freundliches und schnelles Feedback, @7907292512 und @fnbalu
Ich habe jetzt beide Optionen ausprobiert, d.h.
- double nat
- package tagging
aber nichts funktioniert - ich bringen die OPNsense einfach nicht dazu, Pakete, die an die 2te öffentliche IP-Adresse der VPS gerichtet sind und durch den WG-Tunnel zu ihr reinkommen, anzunehmen, zu NATten oder weiterzuleiten.
Falls noch jemand eine Idee hat, gerne. Ich versuch's sonst mal im OPNsene-Forum,
vielleicht kann mir da ja jemand helfen oder hat diese Konfiguration mit der OPNsense schon erfolgreich umgesetzt.
Selbst schon mehrfach ohne Probleme realisiert, ob pfSense oder OPNSense spielt keine Rolle...Wozu NATen wenn es auch ohne geht?? Überflüssiger Overhead.
1.) weil es in den beiden Artikeln so beschrieben war und ich es einfach mal ausprobieren wollte.
2.) ohne DST NAT für eingehende Pakte und SRC NAT für ausgehende funktioniert es nicht. Wer mag schon gerne mit einer RFC1918 Adresse seine Pakete versenden?
Und die Fw muss die eingehenden Pakete ja irgendwohin routen, damit irgendein Host sie bearbeiten kann. Beim Erstellen einer Port-Forwarding-Rule (fürs NATten) wird automatisch die passend Rule fürs Interface gleich mit angelegt.
Selbst schon mehrfach ohne Probleme realisiert
Das glaub ich dir gern, hilft mir nur in meinem Fall nicht weiter.
Zitat von @moosehead:
2.) ohne DST NAT für eingehende Pakte und SRC NAT für ausgehende funktioniert es nicht. Wer mag schon gerne mit einer RFC1918 Adresse seine Pakete versenden?
Logisch am Ausgang zum Netz klar nur intern braucht es das eben nicht zusätzlich schon gar nicht auf der OPNSense.2.) ohne DST NAT für eingehende Pakte und SRC NAT für ausgehende funktioniert es nicht. Wer mag schon gerne mit einer RFC1918 Adresse seine Pakete versenden?
Und die Fw muss die eingehenden Pakete ja irgendwohin routen, damit irgendein Host sie bearbeiten kann. Beim Erstellen einer Port-Forwarding-Rule (fürs NATten) wird automatisch die passend Rule fürs Interface gleich mit angelegt.
Dann hast du die Allowed-IPs wohl auf der OPNSense nicht angepasst, denn die Pakete kommen ja mit Absenderadresse aus dem Internet, deswegen bruauchst du dort 0.0.0.0/0 in den Allowed-IPs.Steht ja auch in den o.g. Beiträgen du musst sie nur etwas aufmerksamer lesen.
Kann dir das Setup gerne zeigen, habe ich keine Probleme mit:
- Auf dem vServer wie gewohnt eine DNAT Regel auf die interne LAN-IP im Remote-Netz hinter der OPNSense anlegen (sofern man nur eine IP besitzt, bei mehreren kann das DNAT natürlich entfallen und man kann komplett auf die OPNSense durchrouten)
iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 443 -j DNAT --to-destination 192.168.50.20Oder beim durchrouten einer separaten IP die IP auf Durchzug schalten
iptables -I FORWARD 1 -d x.x.x.x -j ACCEPTund die Route auf den Tunnel Endpunkt der OPNSense dann auch nicht vergessen
ip route add x.x.x.x via 10.0.0.5- auf dem vServer eine Route ins LAN-Netz hinter der OPNSense mit der WG-TunnelIP der OPNSense als Gateway
ip route add 192.168.50.0/24 via 10.0.0.5- Auf dem vServer im Wireguard Peer das LAN Netz hinter der OPNSense in die Allowed-IPs des Peers aufnehmen.
- auf der OPNSense ein Gateway-Objekt anlegen mit der Tunnel IP ses vServers als Adresse (z.B. 10.0.0.1) und das Wireguard Interface als Interface
- Auf der OPNSense in der Firewall auf dem Wireguard-Interface eine PASS Regel (IN) erstellen die als reply-to das Wireguard Gateway enthält
- In den Wireguard-Peer-Settings die Allowed-IPs auf 0.0.0.0/0 stellen.
- Fertig
Somit NAT nur am vServer intern entfällt es gänzlich!
Works 100% as designed. Just simple Routing-Basics
2Auf dem vServer wie gewohnt eine DNAT Regel auf die interne LAN-IP im Remote-Netz hinter der OPNSense
Das war's, jetzt geht's!
Danke für deine fortgesetzte, geduldige und sehr ausführliche Unterstützung!
Ich hatte das bereits alles soweit, wie du es beschrieben hast. Nur habe ich die Pakete mit der Original-DST-Adresse (also der 2. public IP des vServers) durch den Tunnel an die OPNsense geforwarded und wollte dort erst das DNAT machen. Dazu hatte ich der OPNsene auch schon eine Virtual IP zugewiesen und für den Outbound traffic klappt das auch ganz prima!
Nur Inboud war halt echt der Graus. Aber mit deiner Lösung geht's nun auf jeden Fall!
Nochmals tausend Dank, @7907292512 und eine schönes Wochenende!
Grüße
moosehead
So, nun funktioniert‘s endlich so, wie ich es haben wollte!
Ich route alle Pakete für die zweite öffentliche IP-Adresse des vServers durch den WG-Tunnel auf die OPNsense, mache auf dem vServer aber kein DNAT (mehr).
Und: die OPNsense nimmt diese Pakete jetzt endlich auch an!
Meine beiden Fehler waren:
1. in der „Virtual IP“-Deklaration hatte ich zunächst kein Gateway angegeben. Das muss da aber unbedingt rein, wenn diese VIP über den Tunnel erreicht werden soll!
2. ich hatte bei den Regeln für das WG-Interface die Adresse bzw. den Alias für die VIP angegeben. Fügt man statt dessen „This Firewall“ ein, nimmt die OPNsense die Pakete auch an und dropped sie nicht mehr mit der „Default deny / state violation rule“.
Nun kann ich alle Regeln, DNAT/SNAT, das Routing, etc. für die zweite public IP des vServers komplett auf der OPNsense konfigurieren, also genauso, wie ich es ursprünglich vorhatte.
Dennoch wollte ich meine beiden Fehler kurz noch mitteilen, falls andere hier das Szenario nachbauen wollen.
Ich danke allen, die mir geholfen haben, ganz herzlich für ihre Unterstützung!
Viele Grüße
moosehead
Ich route alle Pakete für die zweite öffentliche IP-Adresse des vServers durch den WG-Tunnel auf die OPNsense, mache auf dem vServer aber kein DNAT (mehr).
Und: die OPNsense nimmt diese Pakete jetzt endlich auch an!
Meine beiden Fehler waren:
1. in der „Virtual IP“-Deklaration hatte ich zunächst kein Gateway angegeben. Das muss da aber unbedingt rein, wenn diese VIP über den Tunnel erreicht werden soll!
2. ich hatte bei den Regeln für das WG-Interface die Adresse bzw. den Alias für die VIP angegeben. Fügt man statt dessen „This Firewall“ ein, nimmt die OPNsense die Pakete auch an und dropped sie nicht mehr mit der „Default deny / state violation rule“.
Nun kann ich alle Regeln, DNAT/SNAT, das Routing, etc. für die zweite public IP des vServers komplett auf der OPNsense konfigurieren, also genauso, wie ich es ursprünglich vorhatte.
Dennoch wollte ich meine beiden Fehler kurz noch mitteilen, falls andere hier das Szenario nachbauen wollen.
Ich danke allen, die mir geholfen haben, ganz herzlich für ihre Unterstützung!
Viele Grüße
moosehead
Moin,
ich benötige ein wenig Unterstützung.
Die Verbindung des Tunnels wird einfach gar nicht erst aufgebaut.
Der VPS Provider ist die Hetzner Cloud.
Der Provider am DSL ist EWE mit Purer Dynamischer IPv4.
Ich bedanke mich bereits im Voraus.
Mfg
Yannick
ich benötige ein wenig Unterstützung.
Die Verbindung des Tunnels wird einfach gar nicht erst aufgebaut.
Der VPS Provider ist die Hetzner Cloud.
Der Provider am DSL ist EWE mit Purer Dynamischer IPv4.
Ich bedanke mich bereits im Voraus.
Mfg
Yannick
Hi, müssen die zusätzlichen IPs in der Cloudinit oder netplan angelegt sein oder dort nur die Hauptadresse?
Hat jemand von euch das in einer aktuellen Debian oder Ubuntu Version nachgebaut und am laufen?
Hallo
Ich habe leider unter aktuellen Debian 12 das Problem, dass wenn ich versuche das Skript zu starten mit ./tunnel.sh, dass ich folgenden Fehler erhalte.
Ich habe leider unter aktuellen Debian 12 das Problem, dass wenn ich versuche das Skript zu starten mit ./tunnel.sh, dass ich folgenden Fehler erhalte.
./tunnel.sh: Zeile 7: Syntaxfehler beim unerwarteten Symbol »newline«
./tunnel.sh: Zeile 7: `<!DOCTYPE html>'
Da in dem Skript kein HTML Code enthalten ist, würde ich mal behaupten, dass da etwas mit dem Download von Github nicht geklappt hat…
Lassen sich über diese Config mehrere IPv4 Adressen auf mehrere Pfsense verteilen, ich würde gerne die Business DSL Anschlüsse zu 1und1 wechseln und dort bekommt man keine Statische IP direkt auf den Anschluss und ich würde diese dann eben von meinem OVH Dedicated Sever beziehen für jeden Anschluss dort habe ich ein /28 Netz. wenn ich tunnel sh starte wird eben Automtisch nur eine IPv4 bezogen ich habe 3 auf dem interface deswegen frage ich .
Wenn ich die tunnel.sh starte dann bekomme ich folgendes
Home WAN IP: 5.5.5.5 (Dynamic IP: false)
Tunnel endpoint is unreachable via ping
root@storage1:~# nano config.sh
root@storage1:~# ./tunnel.sh
This is Dry-Run/status mode!
Please check all values and run this script again with '-f' option
Primary NIC: enp9s0f0
Tunnel Protocol: wg
Tunnel Interface: wg0
Interface Status:
wg0: Fehler beim Auslesen der Schnittstelleninformation: Gerät nicht gefunden
Tunnel Network: 172.20.1.1/30
Tunnel Endpoint: 172.20.1.2
Public IPs used for home:
51.68.xxx.xx/28
Home WAN IP:
(Dynamic IP: false)
Tunnel endpoint is unreachable via ping
root@storage1:~# nano config.sh
root@storage1:~#
ich habe dann diese 5.5.5.5 Home ip gelöscht und leer gelassen und config.sh erneut gespeichert da oben ja die Info war das keine Statische IP angegeben werden muss.
Das einzige was ich noch habe ist das wg0 interface muss ich das per Hand anlegen in /etc/network/interfaces da dies anscheinend fehlt laut Fehler.
Wenn ich die tunnel.sh starte dann bekomme ich folgendes
Home WAN IP: 5.5.5.5 (Dynamic IP: false)
Tunnel endpoint is unreachable via ping
root@storage1:~# nano config.sh
root@storage1:~# ./tunnel.sh
This is Dry-Run/status mode!
Please check all values and run this script again with '-f' option
Primary NIC: enp9s0f0
Tunnel Protocol: wg
Tunnel Interface: wg0
Interface Status:
wg0: Fehler beim Auslesen der Schnittstelleninformation: Gerät nicht gefunden
Tunnel Network: 172.20.1.1/30
Tunnel Endpoint: 172.20.1.2
Public IPs used for home:
51.68.xxx.xx/28
Home WAN IP:
(Dynamic IP: false)
Tunnel endpoint is unreachable via ping
root@storage1:~# nano config.sh
root@storage1:~#
ich habe dann diese 5.5.5.5 Home ip gelöscht und leer gelassen und config.sh erneut gespeichert da oben ja die Info war das keine Statische IP angegeben werden muss.
Das einzige was ich noch habe ist das wg0 interface muss ich das per Hand anlegen in /etc/network/interfaces da dies anscheinend fehlt laut Fehler.
Du kannst den Ordner einfach kopieren bzw. Git mehrfach klonen, so lassen sich mehrere Verbindungen für verschiedene Geräte erstellen.
Es steht doch alles oben: up bzw. down. Ohne Parameter bekommst du nur eine Statusabfrage.
Vorher musst du die Konfigurationsdatei natürlich noch ausfüllen, vor allem unten die Keys eintragen.
Es steht doch alles oben: up bzw. down. Ohne Parameter bekommst du nur eine Statusabfrage.
Vorher musst du die Konfigurationsdatei natürlich noch ausfüllen, vor allem unten die Keys eintragen.
