51
Feste IPs zuhause in pfsense via GRE 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.
Da dieses Szenario nirgends wirklich gut und komplett erklärt ist, habe ich mich dazu entschlossen, meine Erfahrungen in Form einer Anleitung hier zu teilen.
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.
Ich habe sehr lange nach einer vernünftigen Umsetzung gesucht und viel ausprobiert.
Bis vor kurzem nutzte ich eine virtuelle Sophos UTM Instanz zuhause und eine Instanz auf einem Root Server im Rechenzentrum. Hier bietet das Sophos-eigene RED Tunnelprotokoll eine einfache und bequeme Möglichkeit so einen IP-Tunnel umzusetzen (Quelle). Leider ist für ein eigenes OS bei den meisten Hostern ein Dedicated Server mit IPMI Interface nötig, da ein eigenes ISO File genutzt werden muss. Diese Server sind als Neubestellung recht teuer (etwa 30-50€/Monat). Ich hatte in der Serverbörse bei MyLoc in Düsseldorf einen gebrauchten Server mit IPMI für 23€ genommen. Dazu kommen noch 8€/Monat für ein /29 Subnetz.
Auf Dauer war mir das aber zu teuer, weshalb ich nach alternativen Lösungen geschaut habe. Im besten Falle sollte der Tunnel auch direkt in pfsense laufen, weil pfsense bei mir als Router läuft.
Ich habe mich nun für einen GRE Tunnel entschieden. Eine Verschlüsselung kommt hier nicht zum Einsatz, was aber auch nicht weiter schlimm ist, da die Pakete normalerweise ohnehin unverschlüsselt im Internet landen und geroutet werden.
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.
GRE Kerneltreiber laden
IP-Tools installieren (idR. vorinstalliert)
Packet-Forwarding aktivieren
Zweite IP vom physischen Interface entfernen (sofern vom Hoster so konfiguriert, eth0 kann bei dir abweichen)
Tunnel konfigurieren (Der Name gre1 kann frei gewählt werden, ebenso das private Tunnelnetzwerk)
Route für die Tunnelgegenstelle und die zweite öffentliche IP
ARP Proxy für die zweite öffentliche IP auf dem physischen Interface. So werden die Pakete mit der MAC-Adresse des VPS zum nächsten Gateway geschickt.
(Bei einigen Hostern nötig, da die Pakete mit fremden Adressen sonst abgewiesen werden)
Die gennannten Schritte können in einem Bash Script via Cronjob automatisch beim Start ausgeführt werden.
Auf der VPS Seite sind wir nun fertig. Weiter geht es zuhause unter pfsense.
Einen neuen GRE Tunnel anlegen
Danach ein neues Interface erstellen und den soeben erstellen Tunnel zuordnen
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.
Zwei neue Floating Rules für In- und Out-Traffic anlegen.
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.
Das ist leider das spannendste Thema... Hier konfiguriert pfsense von Haus aus falsche Einträge. Daher muss das Outbound NAT auf 'Manual' gestellt werden und ein manueller Eintrag erfolgen.
Die übrig gebliebenen 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
Die Umsetzung auf der VPS Seite ist für das Subnetz identisch zu der oben genannten für eine Einzel IP. Anstatt der Einzel IP wird das Subnetz verwendet. Proxy ARP sollte hierbei nicht erforderlich sein, da die Subnetze bei fast allen Hostern auf die Haupt IP des Servers geroutet werden.
GRE Tunnel identisch zu Einzel IP anlegen
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.
Hierbei könnte es sich z.B. um eine physische Netzwerkkarte oder auch um ein VLAN Interface handeln.
Dem DMZ Interface wird die erste nutzbare IP des Subnetzes gegeben. Diese wird dann das Gateway für alle angeschlossenen Server.
Bei einem Subnetz werden kein Floating Rules benötigt. Hier reicht eine Firewall Regel, die Traffic mit dem Subnetz als Ziel erlaubt.
Um nur bestimmte Ports durchzulassen, kann hierbei natürlich auch eine Regel pro Subnetz-IP angelegt werden:
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.
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. Hierzu habe ich auf dem VPS noch einen Nginx + PHP installiert, der immer die aktuelle WAN IP empfängt.
Hierzu einmal ein Beispiel über PHP und einen Cronjob:
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 18.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!
Info
In dieser Anleitung wird die Einrichtung eines GRE Tunnels beschrieben.
WireGuard für pfsense 2.5.2 ist nun ebenfalls verfügbar.
Daher habe ich eine zweite Anleitung zur Einrichtung eines WireGuard-Tunnels erstellt. Schaut gern mal rein
Feste IPs zuhause in pfsense via WireGuard Tunnel
Ein paar Dinge sind mit WireGuard tatsächlich einfacher:
- Dynamische IPs von Haus aus möglich
- WG-Interfaces werden wie normale Ethernet-Interfaces behandelt. Daher sind z.B. Virtual IPs möglich.
In dieser Anleitung wird die Einrichtung eines GRE Tunnels beschrieben.
WireGuard für pfsense 2.5.2 ist nun ebenfalls verfügbar.
Daher habe ich eine zweite Anleitung zur Einrichtung eines WireGuard-Tunnels erstellt. Schaut gern mal rein
Feste IPs zuhause in pfsense via WireGuard Tunnel
Ein paar Dinge sind mit WireGuard tatsächlich einfacher:
- Dynamische IPs von Haus aus möglich
- WG-Interfaces werden wie normale Ethernet-Interfaces behandelt. Daher sind z.B. Virtual IPs möglich.
Inhaltsverzeichnis
Einleitung
Da dieses Szenario nirgends wirklich gut und komplett erklärt ist, habe ich mich dazu entschlossen, meine Erfahrungen in Form einer Anleitung hier zu teilen.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.
Ich habe sehr lange nach einer vernünftigen Umsetzung gesucht und viel ausprobiert.
Bis vor kurzem nutzte ich eine virtuelle Sophos UTM Instanz zuhause und eine Instanz auf einem Root Server im Rechenzentrum. Hier bietet das Sophos-eigene RED Tunnelprotokoll eine einfache und bequeme Möglichkeit so einen IP-Tunnel umzusetzen (Quelle). Leider ist für ein eigenes OS bei den meisten Hostern ein Dedicated Server mit IPMI Interface nötig, da ein eigenes ISO File genutzt werden muss. Diese Server sind als Neubestellung recht teuer (etwa 30-50€/Monat). Ich hatte in der Serverbörse bei MyLoc in Düsseldorf einen gebrauchten Server mit IPMI für 23€ genommen. Dazu kommen noch 8€/Monat für ein /29 Subnetz.
Auf Dauer war mir das aber zu teuer, weshalb ich nach alternativen Lösungen geschaut habe. Im besten Falle sollte der Tunnel auch direkt in pfsense laufen, weil pfsense bei mir als Router läuft.
Ich habe mich nun für einen GRE Tunnel entschieden. Eine Verschlüsselung kommt hier nicht zum Einsatz, was aber auch nicht weiter schlimm ist, da die Pakete normalerweise ohnehin unverschlüsselt im Internet landen und geroutet werden.
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
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
GRE Kerneltreiber laden
modprobe ip_gre
lsmod | grep gre
Die Ausgabe sollte in etwa so aussehen:
ip_gre ##### 0
gre ##### 1 ip_greIP-Tools installieren (idR. vorinstalliert)
apt install iptables iproute2Packet-Forwarding aktivieren
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -pZweite IP vom physischen Interface entfernen (sofern vom Hoster so konfiguriert, eth0 kann bei dir abweichen)
ip addr del 2.2.2.2 dev eth0Tunnel konfigurieren (Der Name gre1 kann frei gewählt werden, ebenso das private Tunnelnetzwerk)
ip tunnel add gre1 mode gre local 1.1.1.1 remote 5.5.5.5 ttl 255
ip addr add 172.20.1.1/30 dev gre1
ip link set gre1 upRoute für die Tunnelgegenstelle und die zweite öffentliche IP
ip route add 172.20.1.2 dev gre1
ip route add 2.2.2.2/32 dev gre1ARP Proxy für die zweite öffentliche IP auf dem physischen Interface. So werden die Pakete mit der MAC-Adresse des VPS zum nächsten Gateway geschickt.
(Bei einigen Hostern nötig, da die Pakete mit fremden Adressen sonst abgewiesen werden)
ip neigh add proxy 2.2.2.2 dev eth0Die gennannten Schritte können in einem Bash Script via Cronjob automatisch beim Start ausgeführt werden.
Auf der VPS Seite sind wir nun fertig. Weiter geht es zuhause unter pfsense.
Pfsense Seite
Interfaces
Einen neuen GRE Tunnel anlegenDanach ein neues Interface erstellen und den soeben erstellen Tunnel zuordnen
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 -4 Byte GRE) 1468 Byte. Bei einem normalen Ethernet WAN wäre die MTU 1476 für den GRE Tunnel.
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 -4 Byte GRE) 1468 Byte. Bei einem normalen Ethernet WAN wäre die MTU 1476 für den GRE Tunnel.
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
Zwei neue Floating Rules für In- und Out-Traffic anlegen.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
Das ist leider das spannendste Thema... Hier konfiguriert pfsense von Haus aus falsche Einträge. Daher muss das Outbound NAT auf 'Manual' gestellt werden und ein manueller Eintrag erfolgen.Die übrig gebliebenen 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
Umsetzung (/29 Subnetz ohne NAT)
VPS Seite
Die Umsetzung auf der VPS Seite ist für das Subnetz identisch zu der oben genannten für eine Einzel IP. Anstatt der Einzel IP wird das Subnetz verwendet. Proxy ARP sollte hierbei nicht erforderlich sein, da die Subnetze bei fast allen Hostern auf die Haupt IP des Servers geroutet werden.Pfsense Seite
Interfaces
GRE Tunnel identisch zu Einzel IP anlegenEin 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.
Hierbei könnte es sich z.B. um eine physische Netzwerkkarte oder auch um ein VLAN Interface handeln.
Dem DMZ Interface wird die erste nutzbare IP des Subnetzes gegeben. Diese wird dann das Gateway für alle angeschlossenen Server.
Firewall
Bei einem Subnetz werden kein Floating Rules benötigt. Hier reicht eine Firewall Regel, die Traffic mit dem Subnetz als Ziel erlaubt.Um nur bestimmte Ports durchzulassen, kann hierbei natürlich auch eine Regel pro Subnetz-IP angelegt werden:
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.
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. Hierzu habe ich auf dem VPS noch einen Nginx + PHP installiert, der immer die aktuelle WAN IP empfängt.Hierzu einmal ein Beispiel über PHP und einen Cronjob:
<?php
$ip = $_GET["ip"];
if (preg_match("/^(?:(?:^|\.)(?:2(?:5[0-5]|[0-4]\d)|1?\d?\d)){4}$/", $ip)) {
if (file_get_contents('ip.txt') != $ip) {
file_put_contents('ip.txt', $ip);
}
if (file_get_contents('ip.txt') == $ip) {
echo "success";
}
}
?>#!/bin/bash
current_remote_ip=`ip tunnel show | grep gre1 | awk '/remote/ {split ($4,A," "); print A[1]}'`
remote_ip=`cat ip.txt`
if [[ ! "$current_remote_ip" == "$remote_ip" ]]; then
ip tunnel change gre1 mode gre remote $remote_ip local 1.1.1.1 ttl 255
fiHardware
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 18.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: 567618
Url: https://administrator.de/contentid/567618
Printed on: April 19, 2024 at 15:04 o'clock
51 Comments
Latest comment
Sehr schöne und saubere Lösung und obendrein gut erklärt. Kannst du auch näheres zu deinem Router sagen?
1
Danke für dein Feedback
Die Infos zur Hardware habe ich soeben oben ergänzt.
Die Infos zur Hardware habe ich soeben oben ergänzt.
Anleitung um Nutzung eines Subnetzes anstatt Einzel IPs erweitert.
Kann das ganze auch mit einer Sophos UTM 9 umgesetzt werden?
Das funktioniert damit auch. Ich bin mir nicht sicher, ob GRE Tunnel bereits in der GUI funktionieren, aber über das CLI funktioniert es.
Wobei es bei Sophos mit dem eigenen RED Tunnel deutlich einfacher ist. Allerdings brauchst du dann auf beiden Seiten eine Sophos Instanz als VM oder HW. Die Anleitung zum RED Tunnel ist oben verlinkt.
Eine Alternative wäre eine kleine VM mit Ubuntu o.ä. worin dann der Tunnel läuft. Dahinter kannst du dann alle Geräte mit öffentlicher Adresse verbinden.
Wobei es bei Sophos mit dem eigenen RED Tunnel deutlich einfacher ist. Allerdings brauchst du dann auf beiden Seiten eine Sophos Instanz als VM oder HW. Die Anleitung zum RED Tunnel ist oben verlinkt.
Eine Alternative wäre eine kleine VM mit Ubuntu o.ä. worin dann der Tunnel läuft. Dahinter kannst du dann alle Geräte mit öffentlicher Adresse verbinden.
Hi, ich habe das mit IPv6 versucht, nur scheitere ich schon am Internen IPv4 Subnetz, es lassen sich beide seiten nicht anpingen. Was muss ich bei einer IPv6 Konfiguration beachten? Ich habe in Linux einen normalen IPv6 GRE Tunnel erstellt.
Hi, also das Setup sollte eigentlich ziemlich identisch sein. Du erstellst einen IP6GRE Tunnel in Linux und in pfsense gibst du die IPv6 Adresse des VPS ein. pfsense erstellt dann automatisch einen IP6GRE Tunnel aufgrund der eingegebenen IPv6.
Hast du einmal geprüft, ob der GRE Tunnel überhaupt funktioniert? Vielleicht blockiert etwas zwischen beiden Endpunkten.
Hast du die Regeln korrekt angelegt? Ein Ping geht ohne die richtigen Firewall Regeln nicht.
Hast du einmal geprüft, ob der GRE Tunnel überhaupt funktioniert? Vielleicht blockiert etwas zwischen beiden Endpunkten.
Hast du die Regeln korrekt angelegt? Ein Ping geht ohne die richtigen Firewall Regeln nicht.
Danke erstmal für das sehr umfassende Tutorial.
Ich dachte ich versuche mich nun auch mal daran - als kleiner Test.
Leider scheitere ich bereits am Pingen (Der Tunnel sollte bereits stehen)
Die Settings auf dem VPS habe ich nach der Anleitung gemacht.
Die Settings auf der PFsense ebenfalls.
Meine Pfsense hängt im WAN noch an ner Fritte, ist aber als exposed Host freigegeben.
Zudem habe ich (um auf Nummer Sicher zu gehen GRE als Freigabe zusätzlich an die PFsense freigegeben)
Es scheint auch, dass die Verbindung kurz zustande kommt.
Das GW wird allerdings als offline angezeigt, RTT = 20.0ms RTTsd 0ms und Loss ist anfangs auf ca. 50% und geht schnell auf 90% und kurz drauf auf 100%
wenn ich vom vps die pfsense auf dem tunnel netzwerk pingen will, geht das auch genau einmal mit einer ttl von ca 17.0ms danach kommt nichts mehr durch.
Anderst rum genau das selbe Spiel.
Vielleicht muss ich noch sagen dass ich mein Netz von Vodafone via Kabel (1Gbs. Leitung) auf die Fritte und wie schon gesagt als Exposed host auf die Pfsense bekomme.
Weiß vielleicht jemand Rat?
Ich dachte ich versuche mich nun auch mal daran - als kleiner Test.
Leider scheitere ich bereits am Pingen (Der Tunnel sollte bereits stehen)
Die Settings auf dem VPS habe ich nach der Anleitung gemacht.
Die Settings auf der PFsense ebenfalls.
Meine Pfsense hängt im WAN noch an ner Fritte, ist aber als exposed Host freigegeben.
Zudem habe ich (um auf Nummer Sicher zu gehen GRE als Freigabe zusätzlich an die PFsense freigegeben)
Es scheint auch, dass die Verbindung kurz zustande kommt.
Das GW wird allerdings als offline angezeigt, RTT = 20.0ms RTTsd 0ms und Loss ist anfangs auf ca. 50% und geht schnell auf 90% und kurz drauf auf 100%
wenn ich vom vps die pfsense auf dem tunnel netzwerk pingen will, geht das auch genau einmal mit einer ttl von ca 17.0ms danach kommt nichts mehr durch.
Anderst rum genau das selbe Spiel.
Vielleicht muss ich noch sagen dass ich mein Netz von Vodafone via Kabel (1Gbs. Leitung) auf die Fritte und wie schon gesagt als Exposed host auf die Pfsense bekomme.
Weiß vielleicht jemand Rat?
1. Generell solltest du einen GRE Tunnel ohne weitere Hops, NAT etc. betreiben. Dazu muss die öffentliche WAN IP auf dem pfsense Router sein. Ich hatte im Bekanntenkreis auch schon ähnliche Probleme in Verbindung mit Fritzboxen. Wenn du mit Port Forwarding arbeitest, sind wahrscheinlich andere Tunnel-Protokolle interessanter (z.B. IPsec).
2. Hast du echtes Dual Stack bei Vodafone (also eine eigene öffentliche IPv4 ohne CG-NAT/Dual Stack Lite Geraffel) angemeldet? Wenn nicht, hast du den Tunnel über IPv6 eingerichtet?
Ich kann dir wärmstens ans Herz legen, die Fritzbox durch ein Kabelmodem zu ersetzen, wenn du sowieso eine pfsense Instanz dahinter betreibst.
Du kaufst dir einfach ein TC4400 und hängst daran dann pfsense. Das läuft dann im Gegensatz zur Fritzbox auch "Rockstable".
2. Hast du echtes Dual Stack bei Vodafone (also eine eigene öffentliche IPv4 ohne CG-NAT/Dual Stack Lite Geraffel) angemeldet? Wenn nicht, hast du den Tunnel über IPv6 eingerichtet?
Ich kann dir wärmstens ans Herz legen, die Fritzbox durch ein Kabelmodem zu ersetzen, wenn du sowieso eine pfsense Instanz dahinter betreibst.
Du kaufst dir einfach ein TC4400 und hängst daran dann pfsense. Das läuft dann im Gegensatz zur Fritzbox auch "Rockstable".
danke für deine schnelle Antwort.
wenn ich die Fritte in den Bridge Modus setze sollte das doch auch funktionieren, oder?
zumindest bekomme ich dann keine lokale sondern eine echte externe IP an der pfsense.
ist zwar irgendwie komisch die Fritte so zu verkrüppeln, dass sie eigentlich nur noch ein Modem ist.. aber meinem Verständnis nach komme ich auf das selbe Ergebnis, oder liege ich damit falsch?
(ich spreche nicht von exposed host in dem Fall, sondern von echtem Bridge)
wenn ich die Fritte in den Bridge Modus setze sollte das doch auch funktionieren, oder?
zumindest bekomme ich dann keine lokale sondern eine echte externe IP an der pfsense.
ist zwar irgendwie komisch die Fritte so zu verkrüppeln, dass sie eigentlich nur noch ein Modem ist.. aber meinem Verständnis nach komme ich auf das selbe Ergebnis, oder liege ich damit falsch?
(ich spreche nicht von exposed host in dem Fall, sondern von echtem Bridge)
Das wäre natürlich auch möglich sofern das die Fritzbox unterstützt. Allerdings ist das dann ein teurer Briefbeschwerer ;)
Verkauf die doch lieber oder kündige die monatliche Gebühr falls möglich. Wenn du gewisse Funktionen der Fritzbox brauchst (z.B. WLAN, Telefonanlage oder DECT) kannst du sie als IP Client im Netz von pfsense nutzen und als Modem dann das TC4400. Diese Sachen verlierst du übrigens auch, wenn der Bridge Mode aktiv ist.
Verkauf die doch lieber oder kündige die monatliche Gebühr falls möglich. Wenn du gewisse Funktionen der Fritzbox brauchst (z.B. WLAN, Telefonanlage oder DECT) kannst du sie als IP Client im Netz von pfsense nutzen und als Modem dann das TC4400. Diese Sachen verlierst du übrigens auch, wenn der Bridge Mode aktiv ist.
Ich habe das jetzt vorab mal so gelöst und siehe da... es geht ;) Es lag tatsächlich daran, dass die Fritte zuvor das GRE protokoll nicht durchgelassen hat. Auf Bridge geht es wunderbar.
Eine kleine Frage an der Stelle hätte ich allerdings noch:
Du machst das NAT deiner IP auf der Pfsense ja direkt auf eine interne IP. Wäre es in diesem Fall nicht ganz gut das HAProxy Packet der PFsense zu nutzen?
Man kann das NAT doch auf die GRE IP - in dem Fall 172.20.1.2 setzen, und die IP dann im HAProxy als "listen Interface setzten".
So könnte man schönes Offloading mit Zertifikaten aus dem acme machen und man kann einfach sauber verteilen.
In meinen Tests funktioniert das auch. Bin mir nur nicht ganz sicher, ob das ein sauberer Weg ist.
Da ich mit Floating Rules noch nicht wirklich was gemacht habe, meine Frage an der Stelle noch:
Beeinflussen die den eigentlichen Datenfluss im GRE interface?
Ports gebe ich noch immer im Firewall-Tab GRE frei, oder?
Habe mir selbst bash scripte erstellt - ohne nginx und php. Vielleicht kann die ja noch jemand anderes brauchen:
create-tunnel.sh https://pastebin.com/raw/3CGw6F5a
update-tunnel.sh https://pastebin.com/raw/ViZyBS5t
die als crontab -e eintragen
@reboot ~/create-tunnel.sh
@reboot sleep 60 && ~/update-tunnel.sh
vielleicht hilft das ja noch jemandem.
Eine kleine Frage an der Stelle hätte ich allerdings noch:
Du machst das NAT deiner IP auf der Pfsense ja direkt auf eine interne IP. Wäre es in diesem Fall nicht ganz gut das HAProxy Packet der PFsense zu nutzen?
Man kann das NAT doch auf die GRE IP - in dem Fall 172.20.1.2 setzen, und die IP dann im HAProxy als "listen Interface setzten".
So könnte man schönes Offloading mit Zertifikaten aus dem acme machen und man kann einfach sauber verteilen.
In meinen Tests funktioniert das auch. Bin mir nur nicht ganz sicher, ob das ein sauberer Weg ist.
Da ich mit Floating Rules noch nicht wirklich was gemacht habe, meine Frage an der Stelle noch:
Beeinflussen die den eigentlichen Datenfluss im GRE interface?
Ports gebe ich noch immer im Firewall-Tab GRE frei, oder?
Habe mir selbst bash scripte erstellt - ohne nginx und php. Vielleicht kann die ja noch jemand anderes brauchen:
create-tunnel.sh https://pastebin.com/raw/3CGw6F5a
update-tunnel.sh https://pastebin.com/raw/ViZyBS5t
die als crontab -e eintragen
@reboot ~/create-tunnel.sh
@reboot sleep 60 && ~/update-tunnel.sh
vielleicht hilft das ja noch jemandem.
Wie verhält es sich bei der Lösung mit dem eigenen internen Traffic?
Läuft der auch über den Tunnel? Sprich wenn man normal surft etc?
Im Endeffekt wird die IPv4 des vServers genommen und die Beiden IPv6er (die eigene und die des RZ) sind mittels GRE Tunnel miteinander verbunden?
Ist die Lösung besser als EDV-Kossmann etc? Welches RZ wäre für Deutsche Glasfaser vom Peering her gut? Würde da Hetzner gehen???
Läuft der auch über den Tunnel? Sprich wenn man normal surft etc?
Im Endeffekt wird die IPv4 des vServers genommen und die Beiden IPv6er (die eigene und die des RZ) sind mittels GRE Tunnel miteinander verbunden?
Ist die Lösung besser als EDV-Kossmann etc? Welches RZ wäre für Deutsche Glasfaser vom Peering her gut? Würde da Hetzner gehen???
Das kannst du dir aussuchen.
Dein Traffic nimmt das konfigurierte Gateway.
Du kannst auch LAN Traffic über den Tunnel schicken:
Und natürlich eine Outgoing NAT rule (GRE Interface, LAN Subnetz -> GRE Adresse) nicht vergessen.
So mache ich das auch für Dienste, die über die Telekom zeitweise nicht nutzbar sind z.B. AWS.
Welches Peering gut ist, musst du ausprobieren. Dazu reichen ja Pings zu IPs deines Wunschproviders und natürlich Pings von einem dortigen Server zu betroffenen Diensten.
Hetzner ist erstmal eine gute Wahl.
Dein Traffic nimmt das konfigurierte Gateway.
Du kannst auch LAN Traffic über den Tunnel schicken:
So mache ich das auch für Dienste, die über die Telekom zeitweise nicht nutzbar sind z.B. AWS.
Welches Peering gut ist, musst du ausprobieren. Dazu reichen ja Pings zu IPs deines Wunschproviders und natürlich Pings von einem dortigen Server zu betroffenen Diensten.
Hetzner ist erstmal eine gute Wahl.
Hallo,
vielen Dank für die Anleitung klappt bei mir mit ein bisschen probieren hervorragend.
Allerdings nutze ich als vServer und auch als lokale Firewall OPNsense.
Bei Hetzner lässt sich sowohl OPNsense als auch PFsense als ISO einbinden und die Installation durchführen (https://www.hetzner.com/de/cloud).
Der Vorteil ist, man kann schon am vServer unerwünschten Traffic komfortabel rausfiltern, wenn man möchte (einfach FW auf den relevanten Ports dicht machen).
Ein Problem gibt es noch, die dynamische IP zu Hause.
Da schaue ich, ob ich da was brauchbares finde, Google gibt bei "GRE dynamic ip address" zumindesten ein paar Treffer aus
Grüße
Christian
vielen Dank für die Anleitung
klappt bei mir mit ein bisschen probieren hervorragend.Allerdings nutze ich als vServer und auch als lokale Firewall OPNsense.
Bei Hetzner lässt sich sowohl OPNsense als auch PFsense als ISO einbinden und die Installation durchführen (https://www.hetzner.com/de/cloud).
Der Vorteil ist, man kann schon am vServer unerwünschten Traffic komfortabel rausfiltern, wenn man möchte (einfach FW auf den relevanten Ports dicht machen).
Ein Problem gibt es noch, die dynamische IP zu Hause.
Da schaue ich, ob ich da was brauchbares finde, Google gibt bei "GRE dynamic ip address" zumindesten ein paar Treffer aus
Grüße
Christian
ach, ein weiteres Problem habe ich aber dennoch.
Könnt ihr aus eurem Lokalen LAN auf die
zugreifen?
bei mir passt da irgendwas nicht.
Von außerhalb geht es super, aber von intern von meinem LAN leider nicht
Könnt ihr aus eurem Lokalen LAN auf die
Zweite IP VPS: 2.2.2.2/32bei mir passt da irgendwas nicht.
Von außerhalb geht es super, aber von intern von meinem LAN leider nicht
Danke für die Info!
Mittlerweile geht das wohl. Zu meiner Zeit ging es leider nicht. Da hat man bei Hetzner nur Dedicated Server per KVM/IPMI mit einem eigenen OS ausstatten können.
Könntest du noch ein paar Bilder der Konfiguration auf der vServer Seite posten?
Bei OPNsense könntest du die integrierte API nutzen um die Adresse zu aktualisieren. Diese gibt es bei pfsense nicht.
Ansonsten halt ein Shell Skript per Cronjob, das den GRE Tunnel anhand einer DynDNS IP ändert.
Die externen Adressen kannst du intern nicht aufrufen. Stichwort: NAT Reflection.
Die meisten Router betreiben dazu einen NAT Proxy, der entsprechenden Traffic umbiegt. Zu empfehlen ist das aber nicht.
Richte dir ein Split DNS ein und rufe die Server direkt über die lokale IP auf.
Mittlerweile geht das wohl. Zu meiner Zeit ging es leider nicht. Da hat man bei Hetzner nur Dedicated Server per KVM/IPMI mit einem eigenen OS ausstatten können.
Könntest du noch ein paar Bilder der Konfiguration auf der vServer Seite posten?
Bei OPNsense könntest du die integrierte API nutzen um die Adresse zu aktualisieren. Diese gibt es bei pfsense nicht.
Ansonsten halt ein Shell Skript per Cronjob, das den GRE Tunnel anhand einer DynDNS IP ändert.
Die externen Adressen kannst du intern nicht aufrufen. Stichwort: NAT Reflection.
Die meisten Router betreiben dazu einen NAT Proxy, der entsprechenden Traffic umbiegt. Zu empfehlen ist das aber nicht.
Richte dir ein Split DNS ein und rufe die Server direkt über die lokale IP auf.
Geht da nicht ddns?
Ich kann bei All-inkl.com DDNS für IPv6 machen oder für IPv4
Aktuell bei T-Online filtert auch meine pfSense.
Doppelt filtern kann Fluch und Segen sein nehme ich an
Ich kann bei All-inkl.com DDNS für IPv6 machen oder für IPv4
Aktuell bei T-Online filtert auch meine pfSense.
Doppelt filtern kann Fluch und Segen sein nehme ich an
ne, GRE kann nur mit IP und nicht mit Hostnamen.
Das müsste OPNsense dazu bauen.
Filter: ja sicher, aber wenn irgendwer den vServer mit unnützen Anfragen zuballert, kann man sich seine Leitung zu Hause auch freihalten, indem man das rausfiltert, Port 123 und 23 z.B. da kommen tausende Anfragen zu rein.
Das müsste OPNsense dazu bauen.
Filter: ja sicher, aber wenn irgendwer den vServer mit unnützen Anfragen zuballert, kann man sich seine Leitung zu Hause auch freihalten, indem man das rausfiltert, Port 123 und 23 z.B. da kommen tausende Anfragen zu rein.
Christian, welcher Provider ist das?
Bei der deutschen Glasfaser hat man wohl ein eigenes kleines Subnet. Also statisch?
Bei der deutschen Glasfaser hat man wohl ein eigenes kleines Subnet. Also statisch?
Noch Telekom DSL 50, aber die Telekom ist gerade am ausbauen.
Nur noch Inhouse fehlt.
Aber der ipv6 Prefix ist ja nicht statisch sondern dynamisch denke ich, auch bei DG.
https://www.glasfaserforum.de/forum/thread/605-deutsche-glasfaser-wie-st ...
Nur noch Inhouse fehlt.
Aber der ipv6 Prefix ist ja nicht statisch sondern dynamisch denke ich, auch bei DG.
https://www.glasfaserforum.de/forum/thread/605-deutsche-glasfaser-wie-st ...
Du bekommst eigentlich bei fast keinem Provider wirklich statische IPs. Das ist Business Verträgen vorbehalten.
Ist aber ja auch nicht nötig, weil du per Skript die Adresse aktualisieren kannst. Ein paar Ideen hatte ich dazu auch oben niedergeschrieben.
Dazu kommt, dass du bei DG den Tunnel auf jeden Fall über IPv6 umsetzen musst, weil DS-Lite/CG-NAT zum Einsatz kommt. Darüber ist kein GRE möglich. Deine öffentliche IPv4 ist weitestgehend statisch aber mit anderen geteilt. Sie ändert sich erst, wenn du den Router 1-2 Stunden vom Netz nimmst.
Ist aber ja auch nicht nötig, weil du per Skript die Adresse aktualisieren kannst. Ein paar Ideen hatte ich dazu auch oben niedergeschrieben.
Dazu kommt, dass du bei DG den Tunnel auf jeden Fall über IPv6 umsetzen musst, weil DS-Lite/CG-NAT zum Einsatz kommt. Darüber ist kein GRE möglich. Deine öffentliche IPv4 ist weitestgehend statisch aber mit anderen geteilt. Sie ändert sich erst, wenn du den Router 1-2 Stunden vom Netz nimmst.
Dann ist die Lösung ja gar nichts für mich.
Ich wurde hier drauf verwiesen.
Schade
Dann könnte man, vielleicht mit pfsense Site2Site was machen.
Ich wurde hier drauf verwiesen.
Schade
Dann könnte man, vielleicht mit pfsense Site2Site was machen.
Das verstehe ich nicht. Natürlich geht das.
Du musst halt nur von der Anleitung etwas abweichen und IPv6 Adressen für den GRE Tunnel nutzen. Was dann letztlich im Tunnel abläuft ist doch egal.
Also 1.1.1.1 und 5.5.5.5 müssen durch IPv6 ersetzt werden.
Du musst halt nur von der Anleitung etwas abweichen und IPv6 Adressen für den GRE Tunnel nutzen. Was dann letztlich im Tunnel abläuft ist doch egal.
Also 1.1.1.1 und 5.5.5.5 müssen durch IPv6 ersetzt werden.
Sorry, da habe ich den Post von Dir falsch verstanden. Ich las nur es geht nicht.
Klar, IPv4 geht nicht, deshalb würde ich solch Klimmzüge machen. Hoffentlich steht die Leitung im Sommer.
Natürlich schaut man vorher schon wie es gehen könnte.
Durch die fehlende v4 möchte ich eine Alternative schaffen das trotzdem alles bei mir ankommt.
Es soll von jedem Handy oder Hotspot wie früher oder aktuell der Zugriff nach hause möglich sein mittels DDNS
Das könnte auch mit einer pfsense im RZ sein, jedoch sollte man da schon schauen dass kein doppeltes Firewalling stattfindet.
Wie gesagt einerseits gut, andererseits schlecht in der Fehlersuche.
Klar, IPv4 geht nicht, deshalb würde ich solch Klimmzüge machen. Hoffentlich steht die Leitung im Sommer.
Natürlich schaut man vorher schon wie es gehen könnte.
Durch die fehlende v4 möchte ich eine Alternative schaffen das trotzdem alles bei mir ankommt.
Es soll von jedem Handy oder Hotspot wie früher oder aktuell der Zugriff nach hause möglich sein mittels DDNS
Das könnte auch mit einer pfsense im RZ sein, jedoch sollte man da schon schauen dass kein doppeltes Firewalling stattfindet.
Wie gesagt einerseits gut, andererseits schlecht in der Fehlersuche.
Eine weitere pfsense Instanz brauchst du wie gesagt nicht zwingend. Einfach eine Linux VM und fertig. Die hast du in 10 Sekunden beim Hoster erstellt und hochgefahren. Ist aber halt Shell only. pfsense oder OPNsense auf dem vServer wäre ebenfalls GUI.
Da man aber zwangsläufig Dinge per Skript steuern muss, sehe ich in einer GUI keinen Vorteil.
Doppelte Firewall habe ich auch nicht gemacht. Bei mir geht alles an Traffic für die zuhause genutzten IPs direkt durch den Tunnel. Ich sehe darin auch keinen wirklichen Vorteil. Wenn man einen Business Tarif mit mehreren öffentlichen Adressen bucht, kommen die Pakete auch direkt am Router zuhause an. Außer man bucht beim ISP noch zusätzliche Services wie Hardware Firewall, Managed Firewall etc.
Wenn überhaupt macht das bei einer lahmen Leitung Sinn z.B. DSL 16, damit der unerwünschte Traffic gar nicht erst über die Leitung nach Hause kommt und somit Bandbreite frisst. Aber bei Glasfaser und Bandbreiten auf RZ Niveau stört das nicht.
EDIT:
Das erreichen von Diensten zuhause ist über diese Lösung von überall möglich. Trotz DS-Lite! Genau das ist der Sinn meiner Anleitung.
Eine DynDNS brauchst du dann gar nicht unbedingt, weil sich die gebuchte IP beim Hoster nicht ändern wird. Es reicht auch ein normaler DNS Eintrag in deiner Domain sofern du eine hast.
Da man aber zwangsläufig Dinge per Skript steuern muss, sehe ich in einer GUI keinen Vorteil.
Doppelte Firewall habe ich auch nicht gemacht. Bei mir geht alles an Traffic für die zuhause genutzten IPs direkt durch den Tunnel. Ich sehe darin auch keinen wirklichen Vorteil. Wenn man einen Business Tarif mit mehreren öffentlichen Adressen bucht, kommen die Pakete auch direkt am Router zuhause an. Außer man bucht beim ISP noch zusätzliche Services wie Hardware Firewall, Managed Firewall etc.
Wenn überhaupt macht das bei einer lahmen Leitung Sinn z.B. DSL 16, damit der unerwünschte Traffic gar nicht erst über die Leitung nach Hause kommt und somit Bandbreite frisst. Aber bei Glasfaser und Bandbreiten auf RZ Niveau stört das nicht.
EDIT:
Das erreichen von Diensten zuhause ist über diese Lösung von überall möglich. Trotz DS-Lite! Genau das ist der Sinn meiner Anleitung.
Eine DynDNS brauchst du dann gar nicht unbedingt, weil sich die gebuchte IP beim Hoster nicht ändern wird. Es reicht auch ein normaler DNS Eintrag in deiner Domain sofern du eine hast.
Zitat von @KernelMaker:
Könntest du noch ein paar Bilder der Konfiguration auf der vServer Seite posten?
Könntest du noch ein paar Bilder der Konfiguration auf der vServer Seite posten?
ich teste noch ein paar Dinge bis ich Bilder poste, also noch ein wenig Geduld bitte.
Aber eine Frage in die Runde, wenn ich jetzt ipv4 und ipv6 von meinem vServer für meine Dienste zu Hause nutzen möchte, muss ich dann ein zweites GRE Interface einrichten oder schleuse ich ipv4 auch über den ipv4 GRE Tunnel?
Würde beide Tunnel gehen oder ein GRE Tunnel und beide (ipv4 und ipv6 dadrüber)?
Wenn es mit zweien geht, was ist die bessere Lösung?
Sollte beides gehen tendiere ich dazu ipv4 und ipv6 je mit einem eigenen Interface abzuhandeln.
Das geht beides. Du kannst IPv4 und IPv6 über einen Tunnel schicken oder auch zwei Tunnel erstellen.
Das Unterschied besteht eigentlich nur in ip route gre1 bzw. gre2.
Also folgende Möglichkeiten:
1. GRE über vServer IPv4, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
2. GRE über vServer IPv6, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
3. GRE über vServer IPv4, Route enthält zusätzliche IPv4
GRE über vServer IPv6, Route enthält zusätzliche IPv6 als /80 Subnetz
Wenn du einen zweiten GRE Tunnel machen möchtest, muss dieser natürlich über andere öffentliche Adressen gehen (bei Privat mit einer öffentlichen IPv4 müsste der dann zwangsläufig über IPv6 laufen), da man es sonst nicht unterscheiden kann. Da bin ich mir jetzt nicht sicher, müsstest du mal ausprobieren.
Ich würde einfach ein Tunnel machen und darüber IPv4 und IPv6 routen. Von Hetzner bekommt man ja wahrscheinlich ein /64 Subnetz. Wird das komplett auf den Server geroutet? Bei meinem Hoster muss man leider von seinem Subnetz die IPs einzeln im Webinterface anlegen, sodass sie einem als ganzes Subnetz nichts bringen.
Das Unterschied besteht eigentlich nur in ip route gre1 bzw. gre2.
Also folgende Möglichkeiten:
1. GRE über vServer IPv4, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
2. GRE über vServer IPv6, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
3. GRE über vServer IPv4, Route enthält zusätzliche IPv4
GRE über vServer IPv6, Route enthält zusätzliche IPv6 als /80 Subnetz
Wenn du einen zweiten GRE Tunnel machen möchtest, muss dieser natürlich über andere öffentliche Adressen gehen (bei Privat mit einer öffentlichen IPv4 müsste der dann zwangsläufig über IPv6 laufen), da man es sonst nicht unterscheiden kann. Da bin ich mir jetzt nicht sicher, müsstest du mal ausprobieren.
Ich würde einfach ein Tunnel machen und darüber IPv4 und IPv6 routen. Von Hetzner bekommt man ja wahrscheinlich ein /64 Subnetz. Wird das komplett auf den Server geroutet? Bei meinem Hoster muss man leider von seinem Subnetz die IPs einzeln im Webinterface anlegen, sodass sie einem als ganzes Subnetz nichts bringen.
1Zitat von @KernelMaker:
Das geht beides. Du kannst IPv4 und IPv6 über einen Tunnel schicken oder auch zwei Tunnel erstellen.
Das Unterschied besteht eigentlich nur in ip route gre1 bzw. gre2.
Also folgende Möglichkeiten:
1. GRE über vServer IPv4, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
2. GRE über vServer IPv6, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
3. GRE über vServer IPv4, Route enthält zusätzliche IPv4
GRE über vServer IPv6, Route enthält zusätzliche IPv6 als /80 Subnetz
Wenn du einen zweiten GRE Tunnel machen möchtest, muss dieser natürlich über andere öffentliche Adressen gehen (bei Privat mit einer öffentlichen IPv4 müsste der dann zwangsläufig über IPv6 laufen), da man es sonst nicht unterscheiden kann. Da bin ich mir jetzt nicht sicher, müsstest du mal ausprobieren.
Ich würde einfach ein Tunnel machen und darüber IPv4 und IPv6 routen. Von Hetzner bekommt man ja wahrscheinlich ein /64 Subnetz. Wird das komplett auf den Server geroutet? Bei meinem Hoster muss man leider von seinem Subnetz die IPs einzeln im Webinterface anlegen, sodass sie einem als ganzes Subnetz nichts bringen.
Das geht beides. Du kannst IPv4 und IPv6 über einen Tunnel schicken oder auch zwei Tunnel erstellen.
Das Unterschied besteht eigentlich nur in ip route gre1 bzw. gre2.
Also folgende Möglichkeiten:
1. GRE über vServer IPv4, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
2. GRE über vServer IPv6, Route enthält zusätzliche IPv4 und IPv6 als /80 Subnetz
3. GRE über vServer IPv4, Route enthält zusätzliche IPv4
GRE über vServer IPv6, Route enthält zusätzliche IPv6 als /80 Subnetz
Wenn du einen zweiten GRE Tunnel machen möchtest, muss dieser natürlich über andere öffentliche Adressen gehen (bei Privat mit einer öffentlichen IPv4 müsste der dann zwangsläufig über IPv6 laufen), da man es sonst nicht unterscheiden kann. Da bin ich mir jetzt nicht sicher, müsstest du mal ausprobieren.
Ich würde einfach ein Tunnel machen und darüber IPv4 und IPv6 routen. Von Hetzner bekommt man ja wahrscheinlich ein /64 Subnetz. Wird das komplett auf den Server geroutet? Bei meinem Hoster muss man leider von seinem Subnetz die IPs einzeln im Webinterface anlegen, sodass sie einem als ganzes Subnetz nichts bringen.
Danke schon mal für den Input, bin momentan zu Busy um das alles mal durchzutesten.
Ich melde mich mit Ergebnissen, wenn ich dazu gekommen bin.
In ca. 1-2 Wochen
Wichtige Info:
Wenn ihr meine o.g. Lösung nutzt, solltet ihr nicht auf die gestern neu erschienene pfsense Version 2.5.1 CE aktualisieren, weil es einen Bug gibt.
Bei Multi-WAN Setups (dazu zählt eben auch der GRE Tunnel) funktioniert auf den Interfaces mit Non-Default Gateway kein 1:1 NAT und auch kein Port Forwarding mehr. Daher sind Server über den GRE nicht mehr von außen erreichbar.
Die vorherigen Versionen 2.4.5 und 2.5.0 und auch die neuste dev-2.6.0 funktionieren einwandfrei.
Weitere Infos hier:
https://redmine.pfsense.org/issues/11805
Wenn ihr meine o.g. Lösung nutzt, solltet ihr nicht auf die gestern neu erschienene pfsense Version 2.5.1 CE aktualisieren, weil es einen Bug gibt.
Bei Multi-WAN Setups (dazu zählt eben auch der GRE Tunnel) funktioniert auf den Interfaces mit Non-Default Gateway kein 1:1 NAT und auch kein Port Forwarding mehr. Daher sind Server über den GRE nicht mehr von außen erreichbar.
Die vorherigen Versionen 2.4.5 und 2.5.0 und auch die neuste dev-2.6.0 funktionieren einwandfrei.
Weitere Infos hier:
https://redmine.pfsense.org/issues/11805
Mein Deutsch Glasfaser Anschluss ist seit letztem Mittwoch geschaltet.
Aktuell noch auf der neuen pfSense Hardware zu Hause und nur für einen Rechner. Noch nicht produktiv für alle.
Ich muss das auch noch umbauen.
Nun schaue ich gerade welchen vServer ich nehme.
Ich werde voraussichtlich nicht den Megatraffic über den Tunnel schieben, dennoch sollte es schnell sein.
Ich habe daheim einen Mailserver, der nur intern verteilt. Abholen tut er mittels Pop usw.
Ich selbst nutze mein OpenVPN bisher über IPv4
Es gibt wie oben schon erwähnt wenige IPv4 Forwards
Die müssen jetzt natürlich irgendwie über einen vServer damit wieder alles so ist wie früher.
Ich verstehe das weiter oben immer noch nicht mit dem Gateway.
ich möchte doch nicht alles über das RZ laufen lassen, wenn ich eine Seite aufrufe wie ebay etc
Es soll einfach nur von außen subdomain.domain.de auf meine IP umgeleitet werden, was bisher mittels DDNS geschieht, ich kann aber auch auf eine IP umleiten, das ist ja Jacke wie Hose.
Hetzner bietet beim CX11 für 2,96€ mtl 20TB Traffic, das sollte langen, Notfalls CPX11 für 4,15€ mit 40TB (die muss man erstmal schaufeln)
NetCup bietet mit dem VPS 200 G8 40TB für 2,69€mtl
1Blu unbegrenzten Traffic für 4,99 mtl beim VPS R8
CPUs wären bei 1Blu am Meisten und auch SSD Speicher, jedoch braucht es für das Vorhaben wohl fast gar nichts.
Wenn stumpf geforwardet wird, würde ja fast ein 486er reichen.
Es bieten auch fast alle das Einbinden eines Isos an, somit könnte man selbs im Rechenzentrum eine pfSense laufen lassen.
Es könnte ja eine Site2Site Verbindung geben.
Ich stehe da aktuell nur noch auf dem Schlauch wie ich dann die Anfrage IPv4:Port21 beispielsweise durch den Tunnel wieder einem Client auf Port21 zuordne in meiner pfSense. Das muss ich mir noch aneignen, beruflich mache ich das nicht.
Natürlich wird es nicht Port21 sein, da ich keine Standardports verwende, das wird intern umgetriggert, das kann ich sogar
Welchen Hoster sollte man wählen, gibts da Tipps, welche gar nicht?
In einem Test kam 1blu sogar recht gut weg, was man darauf geben kann ist auch immer eine Sache.
Aktuell noch auf der neuen pfSense Hardware zu Hause und nur für einen Rechner. Noch nicht produktiv für alle.
Ich muss das auch noch umbauen.
Nun schaue ich gerade welchen vServer ich nehme.
Ich werde voraussichtlich nicht den Megatraffic über den Tunnel schieben, dennoch sollte es schnell sein.
Ich habe daheim einen Mailserver, der nur intern verteilt. Abholen tut er mittels Pop usw.
Ich selbst nutze mein OpenVPN bisher über IPv4
Es gibt wie oben schon erwähnt wenige IPv4 Forwards
Die müssen jetzt natürlich irgendwie über einen vServer damit wieder alles so ist wie früher.
Ich verstehe das weiter oben immer noch nicht mit dem Gateway.
ich möchte doch nicht alles über das RZ laufen lassen, wenn ich eine Seite aufrufe wie ebay etc
Es soll einfach nur von außen subdomain.domain.de auf meine IP umgeleitet werden, was bisher mittels DDNS geschieht, ich kann aber auch auf eine IP umleiten, das ist ja Jacke wie Hose.
Hetzner bietet beim CX11 für 2,96€ mtl 20TB Traffic, das sollte langen, Notfalls CPX11 für 4,15€ mit 40TB (die muss man erstmal schaufeln)
NetCup bietet mit dem VPS 200 G8 40TB für 2,69€mtl
1Blu unbegrenzten Traffic für 4,99 mtl beim VPS R8
CPUs wären bei 1Blu am Meisten und auch SSD Speicher, jedoch braucht es für das Vorhaben wohl fast gar nichts.
Wenn stumpf geforwardet wird, würde ja fast ein 486er reichen.
Es bieten auch fast alle das Einbinden eines Isos an, somit könnte man selbs im Rechenzentrum eine pfSense laufen lassen.
Es könnte ja eine Site2Site Verbindung geben.
Ich stehe da aktuell nur noch auf dem Schlauch wie ich dann die Anfrage IPv4:Port21 beispielsweise durch den Tunnel wieder einem Client auf Port21 zuordne in meiner pfSense. Das muss ich mir noch aneignen, beruflich mache ich das nicht.
Natürlich wird es nicht Port21 sein, da ich keine Standardports verwende, das wird intern umgetriggert, das kann ich sogar
Welchen Hoster sollte man wählen, gibts da Tipps, welche gar nicht?
In einem Test kam 1blu sogar recht gut weg, was man darauf geben kann ist auch immer eine Sache.
Hm... ich stehe auf dem Schlauch. Mir fehlt aber auch das Fachwissen ehrlicherweise.
Da ich CG-Nat habe, möchte ich über die vServer ipV4 mittels Tunnel zu meiner pfSense, welche nur IPv6 hat.
Da es oben hieß ich solle 1.1.1.1 und 5.5.5.5 mit meinen IPv6 ersetzen, habe ich es wie folgt versucht:
Das frisst er nicht, weil er die IPv6 nicht will. So einfach IPs ersetzen ist da auch nicht oder bin ich zu blöde?
ip tunnel add gre1 mode gre local 1.1.1.1 remote 5.5.5.5 ttl 255Da ich CG-Nat habe, möchte ich über die vServer ipV4 mittels Tunnel zu meiner pfSense, welche nur IPv6 hat.
Da es oben hieß ich solle 1.1.1.1 und 5.5.5.5 mit meinen IPv6 ersetzen, habe ich es wie folgt versucht:
ip tunnel add gre1 mode gre local "IPv4 des vServers" remote "IPv6 meiner Lan1 verbindung der pfSense" ttl 255 Das frisst er nicht, weil er die IPv6 nicht will. So einfach IPs ersetzen ist da auch nicht oder bin ich zu blöde?
Das kann nicht funktionieren, weil das Protokoll nicht "gre" sondern "ip6gre" ist.
Lies dich dazu einmal ein, wie GRE mit IPv6 genutzt wird.
EDIT: Außerdem musst du auch die IPv6 des Server eingeben. Tunnel gehen immer nur mit dem gleichen Medium.
Lies dich dazu einmal ein, wie GRE mit IPv6 genutzt wird.
EDIT: Außerdem musst du auch die IPv6 des Server eingeben. Tunnel gehen immer nur mit dem gleichen Medium.
Oh weia 
Die Anleitung ist auch nur für IPv4.
Es klang so einfach mit "Die zwei IPs in v6 tauschen"
Die Anleitung ist auch nur für IPv4.
Es klang so einfach mit "Die zwei IPs in v6 tauschen"
So einfach ist es auch. Allerdings musst du eben das richtige Protokoll nutzen. Der Rest bleibt gleich.
Die WAN IPv6 siehst du bei den Interface Infos.
Die WAN IPv6 siehst du bei den Interface Infos.
Nur zum Verständnis.
Muss man eine zweite NIc erstellen auf dem vServer?
Bei mir läuft Debian
Mit ifconfig sehe ich die Schnittstelle und derer IPs.
Sind das die 2 die ich nutzen muss?
Muss man eine zweite NIc erstellen auf dem vServer?
Bei mir läuft Debian
Mit ifconfig sehe ich die Schnittstelle und derer IPs.
Sind das die 2 die ich nutzen muss?
Eine zweite Schnittstelle brauchst du nicht. Einfach auf der gleichen das IPv6 einstellen. Dazu gibt es meist Anleitungen von deinem Hoster.
https://docs.hetzner.com/de/cloud/servers/static-configuration/
https://docs.hetzner.com/de/cloud/servers/static-configuration/
So. Nachdem ich die letzten Tage einen Schritt vor dem Abgrund stand, bin ikch nun zwei Schritte weiter.
Ich habe nun endlich die IPv6 IP am WAN anliegen.
Ich möchte nach wie vor keinen Traffic über den Tunnel schicken, sondern lediglich die IPv4 des VServers zu mir umleiten.
Momentan ist es noch die neue pfSense und da diese noch nicht aktiv genutzt wird, kann ich keine geforwardeten Clients erreichen.
Drum versuche ich jetzt erst einmal das WebGui der pfSense selbst über den Tunnel zhu erreichen.
Geht das, so kann man analog dazu den Rest anlegen.
Ich kann nun von der pfSense die IP 172.20.1.2 pingen.
Oben geht es dann in der Anleitung mit 2.2.2.2 weiter und ich weiß absolut nichts was das sein soll.
Ich habe nur eine IPv4 und ich möchte keine DMZ etc haben die permament das als Gateway nutzt.
Ich dachte da würde jetzt eine Regel reichen vom GRE-Tunnel Interface in meinem Fall auf die pfSense selbst.
Da ich triggere von Port 1234 (Platzhalter) auf 443 127.0.0.1
Somit wäre mein Gedanke, dass ich mittels https://IPv4desvServer:1234 die GUI erreiche.
Was ist da noch falsch??
Diese NAT Geschichte ist auch nicht eingetragen.
Ich habe nun endlich die IPv6 IP am WAN anliegen.
Ich möchte nach wie vor keinen Traffic über den Tunnel schicken, sondern lediglich die IPv4 des VServers zu mir umleiten.
Momentan ist es noch die neue pfSense und da diese noch nicht aktiv genutzt wird, kann ich keine geforwardeten Clients erreichen.
Drum versuche ich jetzt erst einmal das WebGui der pfSense selbst über den Tunnel zhu erreichen.
Geht das, so kann man analog dazu den Rest anlegen.
ip tunnel add gre1 mode gre local 1.1.1.1 remote 5.5.5.5 ttl 255
habe ich ersetzt durch
ip link add name gre1 type ip6gre local 2a03:4000:28:948:a8b6:9fff:XXXXXXXXX remote 2a00:6020:1000:XXXX::XXXX Ich kann nun von der pfSense die IP 172.20.1.2 pingen.
Oben geht es dann in der Anleitung mit 2.2.2.2 weiter und ich weiß absolut nichts was das sein soll.
Ich habe nur eine IPv4 und ich möchte keine DMZ etc haben die permament das als Gateway nutzt.
Ich dachte da würde jetzt eine Regel reichen vom GRE-Tunnel Interface in meinem Fall auf die pfSense selbst.
Da ich triggere von Port 1234 (Platzhalter) auf 443 127.0.0.1
Somit wäre mein Gedanke, dass ich mittels https://IPv4desvServer:1234 die GUI erreiche.
Was ist da noch falsch??
Diese NAT Geschichte ist auch nicht eingetragen.
Wie in der Anleitung beschrieben brauchst du eine zweite IPv4 am vServer. Diese wird dann durch den Tunnel geroutet.
Eine DMZ brauchst du nicht. pfsense ist doch egal, ob ein ganzes Netzwerk ein abweichendes Gateway oder nur einzelne Hosts das nutzen.
Du machst dann einfach Portforwarding GRE zu NAS oder Wetterstation etc. im LAN Netzwerk statt 1:1 NAT.
Eine DMZ brauchst du nicht. pfsense ist doch egal, ob ein ganzes Netzwerk ein abweichendes Gateway oder nur einzelne Hosts das nutzen.
Du machst dann einfach Portforwarding GRE zu NAS oder Wetterstation etc. im LAN Netzwerk statt 1:1 NAT.
Hm... ich stehe auf dem Schlauch.
Viellecht hilft dir dieses_Tutorial noch etwas zum Thema GRE ?!1
Hat jemand schon eine Möglichkeit gefunden dieses Setup unter 2.5.2 wieder zum Laufen zu bekommen?
Ich scheitere hier wohl weiterhin beim NAT. (im speziellen beim 1:1, da ich die Regel überhaupt nicht erstellen kann.. Er sagt mir, dass die IPs die ich eintragen will nicht in der IP Familie des Interfaces liegen.
"The interface does not have an address from the specified address family."
Ich scheitere hier wohl weiterhin beim NAT. (im speziellen beim 1:1, da ich die Regel überhaupt nicht erstellen kann.. Er sagt mir, dass die IPs die ich eintragen will nicht in der IP Familie des Interfaces liegen.
"The interface does not have an address from the specified address family."
Also unter 2.5.2 läuft alles wieder ohne Probleme.
Das NAT Problem bei Multi WAN/Gateways ist ja gefixt worden.
Wo genau kommt die Meldung? Schick mal einen Screenshot.
Das NAT Problem bei Multi WAN/Gateways ist ja gefixt worden.
Wo genau kommt die Meldung? Schick mal einen Screenshot.
ich bin leider im Moment unterwegs und kann keinen Screenshot machen.
Aber die Meldung kommt bei mir, wenn ich das 1:1 Nat erstellen möchte.
Interface: GRE (wie im Tut erstellt)
External Subnet IP: die 2. IP des VPS
Internal IP: local IP vom Server im localen Netz
und genau da bekomme ich dann die Meldung sobald ich das 1:1 Nat auf dem GRE Interface aktivieren möchte.
EDIT:
Okay, ich habe eine Lösung gefunden.. Keine Ahnung was da bei mir schief geht.. Ich konnte das 1:1 NAT ums verrecken nicht anlegen, da der Pfsense die Überlappenden IPs nicht gepasst haben.
Mein Lösung: (Quelle: forum.netgate.com/topic/162443/1-1-nat-to-openvpn-2-5-0/2 )
Ich habe jetzt einfach kurzweilig ein 1:1 NAT für ein anderes Interface mit funktionierenden IPs erstellt. Dann über Backup/Restore die NAT settings in ein File gesichert. Das .xml file bearbeitet und an mein Interface angepasst
Das File dann speichern und als NAT Settings restoren.
Damit hat er die Settings gefressen. Will ich die Rule dann aber ändern, bekomme ich den selben Fehler.
EDIT2:
Was mir jetzt noch aufgefallen ist:
Jeglicher Traffic der bei der VPS IP aufschlägt läuft jetzt ja über den GRE Tunnel und wird dann durch das 1:1 NAT auf die IP im DMZ terminiert. So natürlich auch zurück. Ebenfalls läuft der komplette Traffic der auf der DMZ IP nach außen geht über das GRE Gateway und wird so maskiert als würde das DMZ Gerät mit der VPS IP surfen.. soweit so gut.
Versuche ich jetzt aber die VPS IP, die über den GRE nach DMZ durchgereicht wird von einem anderen Subnetz anzupingen, laufe ich ins Leere. Irgendwie ja klar, da der Traffic so ja irgendwie im Kreis geschickt wird. Habe ich da etwas übersehen, oder geht das so gar nicht? An sich passt sonst alles jeglicher Traffic geht über die VPS IP ins DMZ durch, wenn ich das nicht vom Heimnetz aus Teste, sondern beispielsweise über das Internet meines Smartphones (ohne WLAN).
Und wo reguliere ich am Besten die Regeln für eingehenden und ausgehenden Traffic? Auf dem GRE Interface oder auf dem DMZ interface? Also z.b. offene Ports für http, https, ssh, etc?
Aber die Meldung kommt bei mir, wenn ich das 1:1 Nat erstellen möchte.
Interface: GRE (wie im Tut erstellt)
External Subnet IP: die 2. IP des VPS
Internal IP: local IP vom Server im localen Netz
und genau da bekomme ich dann die Meldung sobald ich das 1:1 Nat auf dem GRE Interface aktivieren möchte.
EDIT:
Okay, ich habe eine Lösung gefunden.. Keine Ahnung was da bei mir schief geht.. Ich konnte das 1:1 NAT ums verrecken nicht anlegen, da der Pfsense die Überlappenden IPs nicht gepasst haben.
Mein Lösung: (Quelle: forum.netgate.com/topic/162443/1-1-nat-to-openvpn-2-5-0/2 )
Ich habe jetzt einfach kurzweilig ein 1:1 NAT für ein anderes Interface mit funktionierenden IPs erstellt. Dann über Backup/Restore die NAT settings in ein File gesichert. Das .xml file bearbeitet und an mein Interface angepasst
<onetoone>
<external>###IP VOM VPS###</external>
<descr><![CDATA[JUMP]]></descr>
<interface>###DAS INTERFACE zb opt6###</interface>
<ipprotocol>inet</ipprotocol>
<source>
<address>###INTERNE IP###</address>
</source>
<destination>
<any></any>
</destination>
</onetoone>Das File dann speichern und als NAT Settings restoren.
Damit hat er die Settings gefressen. Will ich die Rule dann aber ändern, bekomme ich den selben Fehler.
EDIT2:
Was mir jetzt noch aufgefallen ist:
Jeglicher Traffic der bei der VPS IP aufschlägt läuft jetzt ja über den GRE Tunnel und wird dann durch das 1:1 NAT auf die IP im DMZ terminiert. So natürlich auch zurück. Ebenfalls läuft der komplette Traffic der auf der DMZ IP nach außen geht über das GRE Gateway und wird so maskiert als würde das DMZ Gerät mit der VPS IP surfen.. soweit so gut.
Versuche ich jetzt aber die VPS IP, die über den GRE nach DMZ durchgereicht wird von einem anderen Subnetz anzupingen, laufe ich ins Leere. Irgendwie ja klar, da der Traffic so ja irgendwie im Kreis geschickt wird. Habe ich da etwas übersehen, oder geht das so gar nicht? An sich passt sonst alles jeglicher Traffic geht über die VPS IP ins DMZ durch, wenn ich das nicht vom Heimnetz aus Teste, sondern beispielsweise über das Internet meines Smartphones (ohne WLAN).
Und wo reguliere ich am Besten die Regeln für eingehenden und ausgehenden Traffic? Auf dem GRE Interface oder auf dem DMZ interface? Also z.b. offene Ports für http, https, ssh, etc?
Das ist ja spannend. Scheint dann wohl ein Bug zu sein
Aber gut, dass du es lösen konntest.
Zu EDIT2:
Das Stichwort heißt "NAT Reflection".
Theoretisch ist es nicht möglich, einen Server mit der öffentlichen IP von innen heraus zu erreichen. Die Consumer Router betreiben dazu Proxies, die den Traffic korrekt umbiegen. Pfsense kann sowas auch. Das kann man machen, führt dann aber gern an anderen Stellen wieder zu Problemen, die man sich evtl. nicht erklären kann. Daher würde ich NAT Reflection nicht einsetzen.
Schau dir das mal an:
https://docs.netgate.com/pfsense/en/latest/nat/reflection.html
Am besten löst du das Problem mit einem Split-DNS. So wird von allen internen Netzwerken die lokale IP des Servers statt der 1:1 IP zurückgegeben. Für alle externen Clients bleibt es natürlich wie zuvor.
Aber gut, dass du es lösen konntest.
Zu EDIT2:
Das Stichwort heißt "NAT Reflection".
Theoretisch ist es nicht möglich, einen Server mit der öffentlichen IP von innen heraus zu erreichen. Die Consumer Router betreiben dazu Proxies, die den Traffic korrekt umbiegen. Pfsense kann sowas auch. Das kann man machen, führt dann aber gern an anderen Stellen wieder zu Problemen, die man sich evtl. nicht erklären kann. Daher würde ich NAT Reflection nicht einsetzen.
Schau dir das mal an:
https://docs.netgate.com/pfsense/en/latest/nat/reflection.html
Am besten löst du das Problem mit einem Split-DNS. So wird von allen internen Netzwerken die lokale IP des Servers statt der 1:1 IP zurückgegeben. Für alle externen Clients bleibt es natürlich wie zuvor.
Info an alle
WireGuard für pfsense 2.5.2 ist nun ebenfalls verfügbar.
Daher habe ich eine zweite Anleitung zur Einrichtung eines WireGuard-Tunnels erstellt. Schaut gern mal rein
Feste IPs zuhause in pfsense via WireGuard Tunnel
Ein paar Dinge sind mit WireGuard tatsächlich einfacher:
- Dynamische IPs von Haus aus möglich
- WG-Interfaces werden wie normale Ethernet-Interfaces behandelt. Daher sind z.B. Virtual IPs möglich.
WireGuard für pfsense 2.5.2 ist nun ebenfalls verfügbar.
Daher habe ich eine zweite Anleitung zur Einrichtung eines WireGuard-Tunnels erstellt. Schaut gern mal rein
Feste IPs zuhause in pfsense via WireGuard Tunnel
Ein paar Dinge sind mit WireGuard tatsächlich einfacher:
- Dynamische IPs von Haus aus möglich
- WG-Interfaces werden wie normale Ethernet-Interfaces behandelt. Daher sind z.B. Virtual IPs möglich.
1
Danke für die schöne und saubere Anleitung.
Ich habe alles wie beschrieben eingerichtet.
Soweit funktioniert der GRE Tunnel. Jedoch habe ich eine Verständnisfrage.
Wenn ich vom ServerABC der die GRE IP (2.2.2.2) erhält einen Ping nach 8.8.8.8, sieht das gleich aus wie bei deinem Bild in deiner Anleitung.
Ich habe noch einen weiteren vServer in einem anderen Rechenzentrum der nichts mit dem GRE Tunnel zu tun hat (sagen wir IP 3.3.3.3).
Zum besseren erklären nenn ich den Server der hinter der DMZ die GRE IP 2.2.2.2 bekommen soll, ServerABC
Wenn ich nun vom diesem exterenen Server (3.3.3.3) einen Traceroute an die Zweite IP VPS: 2.2.2.2/32 mache, geht der Traceroute nicht weiter bis zu Haupt IP VPS: 1.1.1.1/32
In der Firewall sehe ich, dass dieser traceroute geblockt wird.
Schnittstelle GRE mit quelle 3.3.3.3 ---- > Ziel Server ABC / Port UDP (Drop)
Wenn ich eine Regel in der GRE Schnittstelle mache,
Schnittstelle GRE --> IPV4 --ausgehend Quelle alle / Port alle ---> Ziel Server ABC
sind alle Ports von aussen zum ServerABC offen. Das möchte ich aber so nicht.
Habe ich ein Konfigurationsfehler oder fehlt noch etwas an meiner Konfiguration?
Ich habe alles wie beschrieben eingerichtet.
Soweit funktioniert der GRE Tunnel. Jedoch habe ich eine Verständnisfrage.
Wenn ich vom ServerABC der die GRE IP (2.2.2.2) erhält einen Ping nach 8.8.8.8, sieht das gleich aus wie bei deinem Bild in deiner Anleitung.
Ich habe noch einen weiteren vServer in einem anderen Rechenzentrum der nichts mit dem GRE Tunnel zu tun hat (sagen wir IP 3.3.3.3).
Zum besseren erklären nenn ich den Server der hinter der DMZ die GRE IP 2.2.2.2 bekommen soll, ServerABC
Wenn ich nun vom diesem exterenen Server (3.3.3.3) einen Traceroute an die Zweite IP VPS: 2.2.2.2/32 mache, geht der Traceroute nicht weiter bis zu Haupt IP VPS: 1.1.1.1/32
traceroute -w 2 -n -m '30' '2.2.2.2'
traceroute to 2.2.2.2 (2.2.2.2), 30 hops max, 60 byte packets
1 45.xxx.2xx.2x 0.493 ms 0.495 ms 0.487 ms
2 1xx.208.2xx.xx 0.587 ms 0.590 ms 0.585 ms
3 1xx.2xx.2xx.1xx 9.538 ms 9.544 ms 9.540 ms
4 1xx.2xx.2xx.1xx 11.954 ms 11.976 ms 12.171 ms
5 1xx.2xx.2xx.1xx 9.364 ms 9.365 ms 9.362 ms
6 1xx.2xx.2xx.1xx 8.995 ms 8.997 ms 8.971 ms
7 9x.2xx.xx.1xx 9.882 ms 9.820 ms 9.807 ms
8 1.1.1.1 10.077 ms 9.994 ms 9.833 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *In der Firewall sehe ich, dass dieser traceroute geblockt wird.
Schnittstelle GRE mit quelle 3.3.3.3 ---- > Ziel Server ABC / Port UDP (Drop)
Wenn ich eine Regel in der GRE Schnittstelle mache,
Schnittstelle GRE --> IPV4 --ausgehend Quelle alle / Port alle ---> Ziel Server ABC
sind alle Ports von aussen zum ServerABC offen. Das möchte ich aber so nicht.
Habe ich ein Konfigurationsfehler oder fehlt noch etwas an meiner Konfiguration?
Geht denn ein normaler Ping?
Ein traceroute kann als UDP sowie ICMP versendet werden.
Probiere mal einen ICMP traceroute
Ein traceroute kann als UDP sowie ICMP versendet werden.
Probiere mal einen ICMP traceroute
Wenn ich dementsprechend eine ICMP Regel in der GRE Schnittstelle mache, ist die letzte Adresse im Traceroute die 2.2.2.2.
Ohne diese Regel in der GRE Schnittstelle wird auch ein Traceroute mittels ICMP geblockt und der Traceroute geht nur bis 1.1.1.1
Ohne diese Regel in der GRE Schnittstelle wird auch ein Traceroute mittels ICMP geblockt und der Traceroute geht nur bis 1.1.1.1
Genau, das ist dann so gewollt ;)
Also kein Konfigurationsfehler!
Also kein Konfigurationsfehler!
1
Danke dir für die Infos und vor allem die super schnelle Reaktion
Bei der zweiten (IN) Floating Rules.
Muss man hier das Gateway mitgeben?
Auf dem Bild in der Anleitung sieht man dies nicht.
Bei der zweiten (IN) Floating Rules.
Muss man hier das Gateway mitgeben?
Auf dem Bild in der Anleitung sieht man dies nicht.
Nein, nur ausgehend muss ein Gateway angegeben werden, damit die Daten auch durch den Tunnel gehen.
Eingehend ist es nicht nötig. Hier reicht die Ziel IP + 1:1 NAT bzw. Port Forwarding.
Eingehend ist es nicht nötig. Hier reicht die Ziel IP + 1:1 NAT bzw. Port Forwarding.
