Feste IPs zuhause in pfsense via Tunnel
KernelMaker (Level 1) - Jetzt verbinden
26.04.2020, aktualisiert 03.05.2020, 4560 Aufrufe, 12 Kommentare, 6 Danke
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.
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.
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.
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.
Außerdem noch Regeln zum Blockieren von Traffic zu weiteren Interfaces bei euch zuhause.
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
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.
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.
(Hier der zusätzliche Sprung zwischen beiden Adressen auf VPS und pfsense schön zu sehen)
Ausgehend
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.
Hierzu einmal ein Beispiel über PHP und einen Cronjob:
2 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 18.04 LTS
4 vCores, 4 GB vRAM
4 Port Intel Gigabit NIC (PCIe Passthrough)
Konfigurierte Netzwerke:
WAN: PPPoE Verbindung über VLAN 7. Verbunden mit Glasfaser Modem von der Telekom
Tarif: "Magenta Giga" 1000 Down/ 500 Up
LAN: Heimnetz
GUEST: Gastnetz mit einem Captive Portal (VLAN)
IPTV: IGMP Proxy für Entertain (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 Hardware ist überhaupt nicht nötig zum Betrieb eines pfsense Routers, allerdings wollte ich nicht noch extra einen zweiten Server für pfsense hinstellen, wenn sowieso schon ein ESXi Server für den Betrieb von Mailserver, Gameserver(n) und einem Xpenology NAS zum Einsatz kommt.
< Ein Netzplan zur Veranschaulichung ist WIP >
Viel Spaß beim Nachbauen!
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_greapt install iptables iproute2echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -pip addr del 2.2.2.2 dev eth0ip 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 upip route add 172.20.1.2 dev gre1
ip route add 2.2.2.2/32 dev gre1(Bei einigen Hostern nötig, da die Pakete mit fremden Adressen sonst abgewiesen werden)
ip neigh add proxy 2.2.2.2 dev eth0Auf 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.4.5 als VM auf einem ESXi Server (Dual Intel Xeon E5-2630 V4, 128GB RAM)4 vCores, 4 GB vRAM
4 Port Intel Gigabit NIC (PCIe Passthrough)
Konfigurierte Netzwerke:
WAN: PPPoE Verbindung über VLAN 7. Verbunden mit Glasfaser Modem von der Telekom
Tarif: "Magenta Giga" 1000 Down/ 500 Up
LAN: Heimnetz
GUEST: Gastnetz mit einem Captive Portal (VLAN)
IPTV: IGMP Proxy für Entertain (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 Hardware ist überhaupt nicht nötig zum Betrieb eines pfsense Routers, allerdings wollte ich nicht noch extra einen zweiten Server für pfsense hinstellen, wenn sowieso schon ein ESXi Server für den Betrieb von Mailserver, Gameserver(n) und einem Xpenology NAS zum Einsatz kommt.
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.
< Ein Netzplan zur Veranschaulichung ist WIP >
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!
Kommentieren-
6 
- Mehr
Auf Facebook teilen
Auf Twitter teilen12 Kommentare
- LÖSUNG 144095 schreibt am 27.04.2020 um 10:24:48 Uhr
- LÖSUNG KernelMaker schreibt am 27.04.2020 um 20:16:07 Uhr
- LÖSUNG RxyzrYT schreibt am 03.09.2020 um 16:10:05 Uhr
- LÖSUNG KernelMaker schreibt am 05.09.2020 um 16:27:35 Uhr
- LÖSUNG KernelMaker schreibt am 03.05.2020 um 16:56:34 Uhr
- LÖSUNG umount schreibt am 05.06.2020 um 22:32:02 Uhr
- LÖSUNG KernelMaker schreibt am 17.06.2020 um 13:32:23 Uhr
- LÖSUNG umount schreibt am 05.06.2020 um 22:32:02 Uhr
- LÖSUNG dschense schreibt am 18.11.2020 um 12:50:41 Uhr
- LÖSUNG KernelMaker schreibt am 18.11.2020 um 14:18:39 Uhr
- LÖSUNG dschense schreibt am 18.11.2020 um 14:27:44 Uhr
- LÖSUNG KernelMaker schreibt am 18.11.2020 um 14:33:25 Uhr
- LÖSUNG dschense schreibt am 19.11.2020 um 06:44:26 Uhr
- LÖSUNG KernelMaker schreibt am 18.11.2020 um 14:33:25 Uhr
- LÖSUNG dschense schreibt am 18.11.2020 um 14:27:44 Uhr
- LÖSUNG KernelMaker schreibt am 18.11.2020 um 14:18:39 Uhr
LÖSUNG 27.04.2020 um 10:24 Uhr
LÖSUNG 27.04.2020 um 20:16 Uhr
LÖSUNG 03.05.2020 um 16:56 Uhr
LÖSUNG 05.06.2020 um 22:32 Uhr
LÖSUNG 17.06.2020 um 13:32 Uhr
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.
LÖSUNG 03.09.2020 um 16:10 Uhr
LÖSUNG 05.09.2020 um 16:27 Uhr
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.
LÖSUNG 18.11.2020 um 12:50 Uhr
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?
LÖSUNG 18.11.2020 um 14:18 Uhr
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".
LÖSUNG 18.11.2020 um 14:27 Uhr
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)
LÖSUNG 18.11.2020 um 14:33 Uhr
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.
LÖSUNG 19.11.2020 um 06:44 Uhr
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.
