0815admn
Goto Top

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 face-smile

Content-Key: 665494

Url: https://administrator.de/contentid/665494

Printed on: April 16, 2024 at 13:04 o'clock

Member: conquestador
conquestador Apr 07, 2021 at 13:45:18 (UTC)
Goto Top
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)
Member: 0815admn
0815admn Apr 07, 2021 at 18:55:35 (UTC)
Goto Top
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!
netzwerkplan
Member: aqui
aqui Apr 07, 2021 updated at 19:05:57 (UTC)
Goto Top
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...
Member: 0815admn
0815admn Apr 08, 2021 at 16:06:22 (UTC)
Goto Top
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.
Member: aqui
aqui Apr 08, 2021 at 16:26:32 (UTC)
Goto Top
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: Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Ein Screenshot deiner Port Forwarding Einträge die nicht klappen würde allen hier helfen zum Troubleshooting !
Member: 0815admn
0815admn Apr 09, 2021 updated at 13:59:28 (UTC)
Goto Top
Anbei Screenshots, sollten weitere Screenshots benötigt werden bitte einfach Bescheid geben.

NAT Regel auf GWVM:
123

Nat Regel PFsense auf Esxi Host (anderes RZ, per VPN angebunden)
1234
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)
1

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.
Member: aqui
aqui Apr 11, 2021 updated at 11:28:27 (UTC)
Goto Top
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)

back-to-topWAN Port Regel einrichten die TCP 80 (HTTP) auf die WAN IP erlaubt:

pfw2

back-to-topNAT Menü und dort Port Forwarding für TCP 80 (HTTP) einrichten:

(192.168.1.102 ist ein lokaler Web Server im lokalen LAN)
pfw1
Fertisch !
Works as designed und sollte mit TCP 443 (HTTPS) entsprechend auch klappen !
Member: 0815admn
0815admn Apr 12, 2021 at 13:09:08 (UTC)
Goto Top
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.
Member: aqui
aqui Apr 12, 2021 updated at 15:32:58 (UTC)
Goto Top
...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.... face-wink
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.