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.
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
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.
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_gre
IP-Tools installieren (idR. vorinstalliert)
apt install iptables iproute2
Packet-Forwarding aktivieren
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p
Zweite IP vom physischen Interface entfernen (sofern vom Hoster so konfiguriert, eth0 kann bei dir abweichen)
ip addr del 2.2.2.2 dev eth0
Tunnel 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 up
Route 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 gre1
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)
ip neigh add proxy 2.2.2.2 dev eth0
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.
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
Eingehend(Hier der zusätzliche Sprung zwischen beiden Adressen auf VPS und pfsense schön zu sehen)
Ausgehend
Performance Test
Die Geschwindigkeit ist im Vergleich zu sonstigen Lösungen über ein VPN wirklich überragend.Auch der Sophos Tunnel erreichte nur knapp die Hälfte der Geschwindigkeit (350Mbit).
Die übliche Geschwindigkeit des FTTH Anschlusses ohne Tunnel liegt etwa bei 920 Down/540 Up.
Komplett durchgefallen sind bei mir fertige VPN Lösungen wie von Portunity. Hier waren an guten Tagen 150-200Mbit/s drin.
Probleme mit dynamischer WAN IP
Leider muss bei GRE auf beiden Seiten eine feste Gegenstelle angegeben werden. Das wird problematisch, sobald sich die WAN IP zuhause durch einen Router-Neustart oder eine Zwangstrennung ändert. 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
fi
Hardware
Aufgrund der Nachfrage hier noch eine kleine Info zur verwendeten Hardware:myLoc VPS
https://store.servdiscount.com/de/configurate/54562 vCores, 2 GB vRAM, 1000 Mbit Uplink
Ubuntu Server 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!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 567618
Url: https://administrator.de/tutorial/feste-ips-zuhause-in-pfsense-via-gre-tunnel-567618.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
51 Kommentare
Neuester Kommentar
Sehr schöne und saubere Lösung und obendrein gut erklärt. Kannst du auch näheres zu deinem Router sagen?
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?
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)
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???
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
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.
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 ...
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.
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.
Zitat 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
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 255
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:
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?
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.
Hm... ich stehe auf dem Schlauch.
Viellecht hilft dir dieses_Tutorial noch etwas zum Thema GRE ?!
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."
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?
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?