PFSENSE als komplettes VPN Gateway (NAT, HTTPS, Verknüpfung diverser VMs,.)
Hallo,
dies ist mein erster Beitrag hier, ich habe aber schon oft per Google sehr hilfreiche Anleitungen und Fehlerbehebungen gefunden.
Eventuell kann mir ja jemand helfen, ich stehe auf dem Schlauch^^
Folgendes ist geplant:
1x VM mit PFSENSE als VM mit solidem DDOS Schutz auf Seiten des RZ - soll als genereller "Schutz" des hinterliegenden VPN Gateways/Server liegen - weiterführend genannt: GWVM
1x Host mit VMWARE Esxi in einem anderen RZ (die Kosten sind hier deutlich geringer, leider sehr schlechter Schutz vor DDOS oä.) - Anbindung per PFSENSE VPN an die VM im anderen RZ
Der Host wird grundlegend für folgende Funktionen Gebraucht:
- Webserver
- Bereitstellung von Diensten, die öffentlich per VPN (über GWVM Wan) zugänglich gemacht werden sollen
Folgendes habe ich bereits gemacht:
GMVM erstellt und VPN zum Host hergestellt. Von einer Windows VM auf dem Host komme ich auf die LAN IP der GWVM, also scheint das VPN generell zu funktionieren.
Nun möchte ich folgendes machen:
Alle Anfragen, die von öffentlichen IPs kommen, sollen einschließlich auf der GWVM ankommen. Per NAT soll dann z.B. HTTPS auf die zugehörige VM auf dem Host (angebunden per VPN) ankommen, leider laufen Anfragen immer ins leere.
Was ich bereits zur Fehlersuche getan habe:
- Diverse Einstellungen in PFSENSE durchprobiert (NAT auf "interne" IP der VM)
- per NMAP von einem anderen System aus (komplett extern, anderes RZ) die offenen Ports der GWVM gescannt --> Komischerweise wurde trotz aktivem HTTPS NAT der Port 443 nicht als geöffnet angezeigt. Stelle ich die IP auf die "interne" IP der GWVM um erscheint das Admininterface der GWVM (ist wieder geschlosse, diente nur zu Testzwecken).
Hat jemand von euch eine Idee, woran das Problem liegen könnte? Fehlt mir eine Route oder wird mein Vorhaben so überhaupt nicht unterstützt?
Freue mich auf Ideen und Anregungen
dies ist mein erster Beitrag hier, ich habe aber schon oft per Google sehr hilfreiche Anleitungen und Fehlerbehebungen gefunden.
Eventuell kann mir ja jemand helfen, ich stehe auf dem Schlauch^^
Folgendes ist geplant:
1x VM mit PFSENSE als VM mit solidem DDOS Schutz auf Seiten des RZ - soll als genereller "Schutz" des hinterliegenden VPN Gateways/Server liegen - weiterführend genannt: GWVM
1x Host mit VMWARE Esxi in einem anderen RZ (die Kosten sind hier deutlich geringer, leider sehr schlechter Schutz vor DDOS oä.) - Anbindung per PFSENSE VPN an die VM im anderen RZ
Der Host wird grundlegend für folgende Funktionen Gebraucht:
- Webserver
- Bereitstellung von Diensten, die öffentlich per VPN (über GWVM Wan) zugänglich gemacht werden sollen
Folgendes habe ich bereits gemacht:
GMVM erstellt und VPN zum Host hergestellt. Von einer Windows VM auf dem Host komme ich auf die LAN IP der GWVM, also scheint das VPN generell zu funktionieren.
Nun möchte ich folgendes machen:
Alle Anfragen, die von öffentlichen IPs kommen, sollen einschließlich auf der GWVM ankommen. Per NAT soll dann z.B. HTTPS auf die zugehörige VM auf dem Host (angebunden per VPN) ankommen, leider laufen Anfragen immer ins leere.
Was ich bereits zur Fehlersuche getan habe:
- Diverse Einstellungen in PFSENSE durchprobiert (NAT auf "interne" IP der VM)
- per NMAP von einem anderen System aus (komplett extern, anderes RZ) die offenen Ports der GWVM gescannt --> Komischerweise wurde trotz aktivem HTTPS NAT der Port 443 nicht als geöffnet angezeigt. Stelle ich die IP auf die "interne" IP der GWVM um erscheint das Admininterface der GWVM (ist wieder geschlosse, diente nur zu Testzwecken).
Hat jemand von euch eine Idee, woran das Problem liegen könnte? Fehlt mir eine Route oder wird mein Vorhaben so überhaupt nicht unterstützt?
Freue mich auf Ideen und Anregungen
Antworten-
- Mehr
Auf Facebook teilen
Auf Twitter teilen9 Antworten
- LÖSUNG conquestador schreibt am 07.04.2021 um 15:45:18 Uhr
- LÖSUNG 0815admn schreibt am 07.04.2021 um 20:55:35 Uhr
- LÖSUNG aqui schreibt am 07.04.2021 um 21:04:41 Uhr
- LÖSUNG 0815admn schreibt am 08.04.2021 um 18:06:22 Uhr
- LÖSUNG aqui schreibt am 08.04.2021 um 18:26:32 Uhr
- LÖSUNG 0815admn schreibt am 09.04.2021 um 14:58:40 Uhr
- LÖSUNG aqui schreibt am 11.04.2021 um 13:22:49 Uhr
- LÖSUNG 0815admn schreibt am 12.04.2021 um 15:09:08 Uhr
- LÖSUNG aqui schreibt am 12.04.2021 um 17:28:29 Uhr
- LÖSUNG 0815admn schreibt am 12.04.2021 um 15:09:08 Uhr
- LÖSUNG aqui schreibt am 11.04.2021 um 13:22:49 Uhr
- LÖSUNG 0815admn schreibt am 09.04.2021 um 14:58:40 Uhr
- LÖSUNG aqui schreibt am 08.04.2021 um 18:26:32 Uhr
- LÖSUNG 0815admn schreibt am 08.04.2021 um 18:06:22 Uhr
- LÖSUNG aqui schreibt am 07.04.2021 um 21:04:41 Uhr
- LÖSUNG 0815admn schreibt am 07.04.2021 um 20:55:35 Uhr
LÖSUNG 07.04.2021 um 15:45 Uhr
So richtig versteh ich dein Konstrukt nicht.
in RZ1 steht deine PFSense. OK
in RZ2 steht dein ESX den du per VPN mit der PFSense verbunden hast??
Vielleicht kannst du das ja mal näher beschreiben (mit IPs und vielleicht sogar mit Netzwerkplanskizze)
in RZ1 steht deine PFSense. OK
in RZ2 steht dein ESX den du per VPN mit der PFSense verbunden hast??
Vielleicht kannst du das ja mal näher beschreiben (mit IPs und vielleicht sogar mit Netzwerkplanskizze)
LÖSUNG 07.04.2021 um 20:55 Uhr
Ja genau, die beiden Standorte sind per OpenVPN, laufend auf den beiden PFSense, vernetzt.
Ich habe mal versucht einen Netzwerkplan zu erstellen, eventuell wird es damit klarer.
Der gesamte zugriff per HTTPS soll nur über die GWVM laufen und dann über das bestehende VPN Netzwerk an die WebVM geleitet werden.
Danke für deine Antwort!
Ich habe mal versucht einen Netzwerkplan zu erstellen, eventuell wird es damit klarer.
Der gesamte zugriff per HTTPS soll nur über die GWVM laufen und dann über das bestehende VPN Netzwerk an die WebVM geleitet werden.
Danke für deine Antwort!
LÖSUNG 07.04.2021, aktualisiert um 21:05 Uhr
Hört sich ja irgendwie nach simplem TCP 443 (HTTPS) Port Forwarding an wenn HTTPS Anfragen am WAN Port der GWVM auf einen Host im lokalen LAN geforwardet werden sollen.
Das geht ganz simpel unter Firewall -> Port Forward
Interface WAN, Protokoll TCP 443, Destination WAN dann auf Redirect Target und hier die lokale IP und TCP 443 einstellen, fertisch
Im FW Regelwerk natürlich nicht vergessen TCP 443 Requests von "any" auf die WAN IP zu erlauben !
Das klappt aber immer nur für einen einzigen HTTPS Host. Ansonsten muss man Port Translation nutzen.
Oder...wenn es transparent sein soll einen HTTP Proxy Server über die Package Verwaltung installieren. Der reicht dann je nach Hostnamen auf die internen HTTPS Server durch.
Simpler Klassiker...
Das geht ganz simpel unter Firewall -> Port Forward
Interface WAN, Protokoll TCP 443, Destination WAN dann auf Redirect Target und hier die lokale IP und TCP 443 einstellen, fertisch
Im FW Regelwerk natürlich nicht vergessen TCP 443 Requests von "any" auf die WAN IP zu erlauben !
Das klappt aber immer nur für einen einzigen HTTPS Host. Ansonsten muss man Port Translation nutzen.
Oder...wenn es transparent sein soll einen HTTP Proxy Server über die Package Verwaltung installieren. Der reicht dann je nach Hostnamen auf die internen HTTPS Server durch.
Simpler Klassiker...
LÖSUNG 08.04.2021 um 18:06 Uhr
Danke für deine Rückmeldung.
Das habe ich so ausprobiert, ich glaube das Problem liegt irgendwo an der zweiten Firewall oder an der Route.
Ping von GWVM auf die VMs (interne IPs) funktioniert. Sobald ich aber eine interne IP bei der Portweiterleitung eintrage zeigt NMAP an, dass der Port geschlossen ist. Müssen in der GWVM spezielle Routen eingetragen habe?
Ich hab eine Route per Hand eingetragen um den Traffic ins interne Netz, IPSec mäßig, über das eine GWVM Interface (VPN Interface) zu übertragen. Danach ging immerhin der Ping von der GWVM zu den "normalen" VMs durch.
Ich hab das Gefühl, das ist irgend ein ganz komischer Fehler den ich gerade nicht sehe.
Freue mich weiterhin über Anregungen und Ideen.
Das habe ich so ausprobiert, ich glaube das Problem liegt irgendwo an der zweiten Firewall oder an der Route.
Ping von GWVM auf die VMs (interne IPs) funktioniert. Sobald ich aber eine interne IP bei der Portweiterleitung eintrage zeigt NMAP an, dass der Port geschlossen ist. Müssen in der GWVM spezielle Routen eingetragen habe?
Ich hab eine Route per Hand eingetragen um den Traffic ins interne Netz, IPSec mäßig, über das eine GWVM Interface (VPN Interface) zu übertragen. Danach ging immerhin der Ping von der GWVM zu den "normalen" VMs durch.
Ich hab das Gefühl, das ist irgend ein ganz komischer Fehler den ich gerade nicht sehe.
Freue mich weiterhin über Anregungen und Ideen.
LÖSUNG 08.04.2021 um 18:26 Uhr
ich glaube das Problem liegt irgendwo an der zweiten Firewall oder an der Route.
Kann natürlich sein. In einer Firewall Kaskade muss man natürlich 2mal Port forwarden, logisch. Kaskaden sind aber immer Mist und Zeichen von schlechtem Design. Sollte man vermeiden wenn man kann.Müssen in der GWVM spezielle Routen eingetragen habe?
Nein, denn IP seitig "kennt" die Firewall ja alle IP netze die an sie direkt angeschlossen sind ! Statische Routen musst du nur konfigurieren wenn du IP Netze hast die NICHT direkt an der FW dran sind und über andere Router oder FWs erreichbar sind.Siehe auch hier in den Routimng Grundlagen: https://administrator.de/tutorial/routing-2-ip-netzen-windows-linux-rout ...
Ein Screenshot deiner Port Forwarding Einträge die nicht klappen würde allen hier helfen zum Troubleshooting !
LÖSUNG 09.04.2021, aktualisiert um 15:59 Uhr
Anbei Screenshots, sollten weitere Screenshots benötigt werden bitte einfach Bescheid geben.
NAT Regel auf GWVM:
Nat Regel PFsense auf Esxi Host (anderes RZ, per VPN angebunden)
Diese Regel hatte ich auch zu Testzwecken mal auf "Any" gestellt statt externe WAN IP. Die Externe WAN IP ist da aktuell noch drin, damit der Server aktuell noch über das eigene WAN Interface erreichbar ist.
Regel PFSense Esxi Host für IPSec, die gleiche Regel existiert auch auf der GWVM (ich weiß, ist alles offen, bin ja dabei die Fehlersuche einzugrenzen xD)
Gerade noch in der GWVM IPSEC Rule gefunden:
Sobald ich versuche von extern die VMWEB zu erreichen sehe ich als State:
SYN_SENT:CLOSED
CLOSED:SYN_SENT
Noch ein Nachtrag: Zukünftig muss die VMWEB nicht mehr direkt aus dem WAN erreicht werden.
Von dem ganzen Konstrukt erhoffe ich mir, dass der ESXI Host nicht mehr so das Opfer von DDOS/Flood o.Ä. wird da das RZ der GWVM damit wirbt, solche Sachen auf RZ Seite gut abwehren zu können. Das ist beim RZ vom Host leider nicht der Fall, die RZ Firewall kann man hingegen sehr gut konfigurieren und z.B. alle Ports sperren außer die öffentliche IP der GWVM.
NAT Regel auf GWVM:
Nat Regel PFsense auf Esxi Host (anderes RZ, per VPN angebunden)
Regel PFSense Esxi Host für IPSec, die gleiche Regel existiert auch auf der GWVM (ich weiß, ist alles offen, bin ja dabei die Fehlersuche einzugrenzen xD)
Gerade noch in der GWVM IPSEC Rule gefunden:
Sobald ich versuche von extern die VMWEB zu erreichen sehe ich als State:
SYN_SENT:CLOSED
CLOSED:SYN_SENT
Noch ein Nachtrag: Zukünftig muss die VMWEB nicht mehr direkt aus dem WAN erreicht werden.
Von dem ganzen Konstrukt erhoffe ich mir, dass der ESXI Host nicht mehr so das Opfer von DDOS/Flood o.Ä. wird da das RZ der GWVM damit wirbt, solche Sachen auf RZ Seite gut abwehren zu können. Das ist beim RZ vom Host leider nicht der Fall, die RZ Firewall kann man hingegen sehr gut konfigurieren und z.B. alle Ports sperren außer die öffentliche IP der GWVM.
LÖSUNG 11.04.2021, aktualisiert um 13:28 Uhr
Etwas unverständlich, liegt aber garantiert an deinem völlig falschen und sinnfreiem Regelwerk was du bei dir im Setup konfiguriert hast.
Ein Port Forwarding rennt hier fehlerfrei mit der pfSense (Beispiel TCP 80, HTTP)
Fertisch !
Works as designed und sollte mit TCP 443 (HTTPS) entsprechend auch klappen !
Ein Port Forwarding rennt hier fehlerfrei mit der pfSense (Beispiel TCP 80, HTTP)
WAN Port Regel einrichten die TCP 80 (HTTP) auf die WAN IP erlaubt:
NAT Menü und dort Port Forwarding für TCP 80 (HTTP) einrichten:
(192.168.1.102 ist ein lokaler Web Server im lokalen LAN)Works as designed und sollte mit TCP 443 (HTTPS) entsprechend auch klappen !
LÖSUNG 12.04.2021 um 15:09 Uhr
Hallo,
danke für deine Antwort und die Anfertigung der Screenshots.
Eine einfache Portweiterleitung vom WAN auf die interne IP der PFSense auf dem ESXI Host funktioniert, nur nicht wenn ich die WAN Adresse der GWVM auf die interne IP der VMWEB leiten möchte.
danke für deine Antwort und die Anfertigung der Screenshots.
Eine einfache Portweiterleitung vom WAN auf die interne IP der PFSense auf dem ESXI Host funktioniert, nur nicht wenn ich die WAN Adresse der GWVM auf die interne IP der VMWEB leiten möchte.
LÖSUNG 12.04.2021, aktualisiert um 17:32 Uhr
...das kann technisch ja niemals gehen. WAN Adresse ist und bleibt ja WAN Adresse und Adressen müssen einzigartig sein. Lernt man in der TCP/IP Grundschule.... 
Und außerdem machst du doch genau das !!! Von extern sprichst du die WAN Adresse an und landest auf einem Host im internen LAN. Das ist doch genau das was du willst, oder ?
Oder willst du diese WAN IP Adresse per Port Forwarding auf eine IP Adresse legen die auf der anderen, mit dem VPN Tunnel verbundenen Firewall liegt ?
Auch das ist möglich und funktioniert fehlerfrei.
Dabei muss man dann sicherstellen das diese Ziel IP Adresse auch routingtechnisch erreichbar ist über das VPN. Ist es dann kann die pfSense auch an lokale IPs weiterleiten die sich in einem anderen IP Segment befindet.
Alternativ kannst du mit "Virtual IPs" (unter Firewall) arbeiten. Das geht aber nur wenn du ein Kontingent von weiteren öffentlichen IPs hast. Die kannst du dann dort setzen und diese kann die FW dann auch im Port Forwarding bedienen.
Und außerdem machst du doch genau das !!! Von extern sprichst du die WAN Adresse an und landest auf einem Host im internen LAN. Das ist doch genau das was du willst, oder ?
Oder willst du diese WAN IP Adresse per Port Forwarding auf eine IP Adresse legen die auf der anderen, mit dem VPN Tunnel verbundenen Firewall liegt ?
Auch das ist möglich und funktioniert fehlerfrei.
Dabei muss man dann sicherstellen das diese Ziel IP Adresse auch routingtechnisch erreichbar ist über das VPN. Ist es dann kann die pfSense auch an lokale IPs weiterleiten die sich in einem anderen IP Segment befindet.
Alternativ kannst du mit "Virtual IPs" (unter Firewall) arbeiten. Das geht aber nur wenn du ein Kontingent von weiteren öffentlichen IPs hast. Die kannst du dann dort setzen und diese kann die FW dann auch im Port Forwarding bedienen.
