pfSense mit OpenVPN und zweitem Routing?

[Bigfoot29]

Hi.

Ich habe gerade für ein privates Projekt ein wenig mit pfSense herumgespielt, um letztlich zwei VMs (aktuell Firewalls auf reiner iptables-Basis) durch eine pfSense-Instanz zu ersetzen. - Am besten, ich pack erstmal das Schaubild hin...

Kabel-Modem
    I
   eth0
IPv4 1.2.3.4
    I
    I--------------------- OpenVPN
    I                    IPv4 5.6.7.8
    I                         I
    I                         I--------------------------- eth3 → DMZ (IPs von außen sichtbar)
    I                         I                    IPv4 5.6.8.17/29
    I                         I                             I
   NAT                       NAT                            I---------------- Server-VM 1
   eth1                      eth2                           I---------------- Server-VM 2
IPv4 192.168.100.0/24    IPv4 192.168.200.0/24              I---------------- Server-VM 3
                                                            I---------------- Server-VM 4
                                                            \---------------- Server-VM 5

eth5 ist für VM-Host-Übergreifende Kommunikation und hier (noch) nicht berücksichtigt.

Der Pfad Kabelmodem -> eth0 -> NAT -> Eth1 ist Kindergarten und funktioniert problemlos. Selbst IPv6 ist auf eth1 kein Thema (läuft sauber). Auch die Einbindung von OpenVPN funktioniert ohne Schwierigkeiten. Wobei ich allerdings kapituliere, ist das DMZ-Netz mit von Außen sichtbaren IPs. Die funktionieren nur, wenn ich allen Traffic via Default Route in pfSense umstelle. Ansonsten kann ich machen, was ich will... ich bekomme kein zweites Routing eingerichtet, um das /29er Subnetz durchzuleiten. Sowohl

• das Aufsetzen eines Tunnels zwischen OpenVPN-"Gerät" und eth3 (scheitert an... keine Ahnung? Funktioniert einfach nicht)
• als auch der Versuch des Anlegens einer statischen Route (scheitert an der Tatsache, dass ich dann eth3 nicht mit dem zugehörigen Subnetz belegen kann)
• als auch das Anlegen eines weiteren Gateways (keine Ahnung, was da wie funktioniert. Die Doku von Netware dazu ist so kurz angebunden, dass man es auch gleich ganz weglassen kann.)

Firewall-Freigaben kann ich setzen, wie ich möchte... Sämtlicher Traffic kommt gemäß Firewall-Regeln zwar raus aus der Firewall (bis zum OpenVPN-Client), aber danach kommt nix mehr zurück. Auch von außen sind die IPs 5.6.7.8 und 5.6.8.17 nur pingbar, wenn ich das Default Gateway direkt auf OpenVPN setze. (Allerdings zerstört das ein wenig die Idee der dualen Nutzung des Anschlusses...)

Was mache ich falsch? Wo denke ich falsch? Hat ggf. jemand von euch einen Tipp oder eine ähnliche Config und/oder kann mal das minimale Regelset anreißen, ohne dass man Sicherheitslücken reißt?

Und bevor jemand fragt: Das Kabelmodem liefert 1000Mbit/s, das OpenVPN maximal 250 mit Limitierung auf 200GB/Monat. Daher tunnele ich nicht einfach allen Traffic durch die OpenVPN-Verbindung...

Danke euch vorab!

Regards, Bigfoot29

 

[Gauss]

Da fehlen mir irgendwie noch ein paar Infos.

Was sind denn die eth0-3 Ports? Sind diese vom Kabelmodem oder von VM Host oder ist die pfSense direkt auf Metall installiert?

Was macht die OpenVPN Instanz im Schaubild? Wird dort von außen drauf zugegriffen?
Warum ist an eth1 und an eth2 das selbe Netzwerk hinterlegt?

Was bedeutet IPs von außen sichtbar? Was ist außen? Für Verbindungen mit dem OpenVPN Server?

Hast du für die OpenVPN Verbindungen an der pfSense neue Interfaces angelegt, um diese auch als Gateway nutzen zu können? Wie sieht die Config der VPN Verbindung aus?

Tut mir leid, ich habe bisher noch keinen Überblick was du da genau tust 😉

 

[Bigfoot29]

Hi @Gauss , Danke für die Nachfragen...

zum Testen ist pfSense direkt auf dem Blech installiert. Erstmal ohne Hypervisor und Co, um mögliche Probleme durch Virtualisierung auszuschließen.

Die "eth"-Ports sind die Netzwerk-Schnittstellen, die bei BSD etwas anders heißen. Es soll letztlich bedeuten, dass es Interfaces zu anderen Umgebungen sind, die ich nur teilweise unter Kontrolle habe.

Eth1 ist die Schnittstelle zum Kabel-Modem (TechniColor). Das gibt sein Internet quasi als Bridge via DHCP an eth0 weiter. (Für Privatkunden gibt es keine festen IPs.)

Die OpenVPN-Verbindung baut einen Tunnel in ein RZ-Netz auf. Das /29er Subnetz wird, genau wie die einzelne IP, "nach draußen" in das freie Internet angezeigt. - Als IPs (und mit Routing) des Rechenzentrums, welches den Tunnel anbietet.

Ja, ich hab für die Openvpn-Verbindung ein neues Interface angelegt. Entsprechendes Gateway ist daher da und ich kann Traffic durchrouten, wenn ich das OVPN-GW als Default-Gateway festlege. (Aber das geht nicht, weil ich damit massiv Bandbreite verliere bzw. leicht das Traffic-Limit knacke. Daher die Frage nach dem "zweiten default Routing".

Eth1/Eth2 war ein Fehler... ist korrigiert. (Mea Culpa...)

Die VPN-Verbindung stellt Portunity zur Verfügung. Layer 3. Config ist gemäß Anbieter eingerichtet (und tut ja auch, wenn ich das Default-GW entsprechend setze).
Der Haken bei "Lade keine Routen" ist raus (Routen werden also geladen und angelegt).
In den "User defined Options" ist dann noch die Option "redirect-gateway" aktiv.

Komplette User Defined Options:

client;
tun-mtu 1440;
fragment 1400;
mssfix;
auth-retry interact;
persist-key;
persist-tun;
ns-cert-type server;
verb 0;
auth-user-pass /conf/portunity.login;
redirect-gateway;

Letztlich will ich - Strang eth0/eth1 - mein Zuhause mit klassischem Internet aus der Kabel-Dose verwenden. Als Sahnehäubchen möchte ich auf der gleichen VM-Büchse aber noch ein paar VMs laufen lassen. (Hab früher im RZ echtes Blech gehostet.) Daher das Subnetz. Die VMs/das Subnetz soll sowas wie eine DMZ sein. Allerdings ohne NAT sondern direkt erreichbar. Da drin läuft eine Nextcloud-Instanz, ein Mail-Server und einiger anderer Kram. Eth2 wird hauptsächlich gebraucht, wenn UnityMedia/KabelBW mal wieder VPN-Verbindungen kappen oder sonst irgend etwas im Eimer ist.

Reichen diese Infos?

Regards, Bigfoot29

 

[Gauss]

Ok, jetzt wird es etwas klarer.

D.h. das Netz an eth1 geht über die pfSense direkt über das Kabelmodem ins Internet. Geräte im eth2-Netz werden über die OpenVPN Verbindung geroutet? Das funktioniert bereits?

Warum die Option redirect-gateway? Ich dachte Du willst nicht pauschal alles darüber routen. Nur eine Anmerkung zu "auth-retry interact": ist das gewollt?

Je nach Gegenseite aktiviere ich ganz gerne "lade keine Routen", um selbst zu bestimmen was in den Tunnel geroutet werden soll und was nicht.

Du kannst in den User Defined Options auch route Befehle verwenden.
Z.B.
route 1.1.1.1 255.255.255.255

Diese Routen würden dann aber auch für das eth1 Netz gelten, was vermutlich nicht beabsichtigt ist.

So wie ich das aktuell verstehe willst Du nicht den gesamten Traffic ins den VPN Tunnel quetschen. D.h. Du willst je nach Quelle unterschiedlich routen.

Das ist dann Policy Routing.

Ich mache das in der Regel dann so, dass ich den Traffic, der durch ein anderes Netzwerk laufen soll mit einem "local tag" in der entsprechenden Firewall-Rule versehe. Z.B. setze ich einen Tag "other_gateway" bei allen Regeln, die über einen anderen Gateway laufen sollen. Diese Regeln dürfen dann aber nicht das Häkchen bei "quick" haben. Am Ende der Tabelle für die Firewall-Regeln kommt dann eine Regel, die nach dem Tag "other_gateway" sucht (match local tag) und dann den Gateway auf das entsprechende Interface umbiegt.

Hab ich das jetzt richtig verstanden?

 

[Raijin]

Ich hab das Setup am Handy noch nicht nachvollziehen können, daher folgendes bitte mit Vorsicht genießen:

Im Gegensatz zu Windows beherrscht Linux Policy Based Routing, kurz PBR. Damit kann man simpel ausgedrückt mehrere Routing-Tabellen erstellen, inkl. eigenem Standardgateway, und diese dann mittel Matching in iptables "auswählen". So kann man zB auf Basis der Quell-IP routen und Gerät X über das VPN ins www schicken, während Gerät Y über den Internetrouter geleitet wird


Ist es das was du mit "zweitem Routing" meinst?

 

[Raijin]

Nachtrag: Wenn man von außen über mehrere IPs erreichbar ist, die alle über ein und dieselbe Schnittstelle laufen, muss man beim NAT noch einige weitere Maßnahmen ergreifen. Ansonsten läuft man Gefahr, dass man eingehend mittels DNAT an Gerät X weiterleitet, die Antwort zur Quelle dann aber auf dem Rückweg mit der falschen Absender-IP versehen wird - zB über eine allgemeine masquerade-Regel, die bei einem Interface mit mehreren IPs einfach nur die erste nimmt.

In so einem Fall braucht man mehrere SNAT-Regeln, die explizit alles was von Gerät X kommt mit IP #3 maskieren und alles was von Y kommt mit #4, etc.
Tut man das nicht, greift wie gesagt die masquerade Regel und dann bekommt der Client außen plötzlich eine Antwort von einer ganz anderen IP. Er fragte also x.y.z.123 und die Antwort kommt dann zB von x.y.z.122 > keine Verbindung.

 

[Gauss]

@Raijin so wie ich das verstehe, ist das Subnetz was er in seiner DMZ hat ein öffentliches Netzwerk. D.h. über die OpenVPN Verbindung aus dem RZ kommen die Anfragen aus dem Internet. Er braucht kein NAT an dieser Stelle. Nur eben Policy Routing, da er nicht alles in den Tunnel schieben will.

 

[Raijin]

Das kann sein. Wie gesagt, am Handy ist das gerade schwierig nachzuvollziehen. Muss ich mir mal am Rechner genau anschauen. Wollte nur ansprechen, dass sowas ein Problem sein kann, je nach Setup.

 

[Bob.Dig]

Vielleicht besser gleich im Netgate-Forum fragen, scheint doch ein recht professionelles Setup zu sein. Das "Schaubild" im ersten Post liest sich für mich als Laien recht schlecht, dazu enthielt es auch noch Fehler, was die Sache nicht gerade verbesserte... 😉

 

[Voltago]

Du könntest deine pfSense als openVPN Client verwenden und dir ein Interface zu dem Tunnel basteln, das du dann über Policy Routes ansprechen und verwenden kannst.

Hast du diesen Ansatz schon verfolgt?