[gelöst] Entscheidungshilfe: Eingebauter oder dedizierter OpenVPN-Server

[desert_fox]

Hallo zusammen,

ich bin gerade dabei, das vorhandene Netzwerk zu modernisieren und in diesem Zuge u.a. von einem einzelnen großen Subnet in mehrere VLANs zu segmentieren. Dabei kommt OPNsense die Funktion eines Routers und einer Firewall zu.

Bisher verwende ich OpenVPN im Roadwarrior-Setup für den Admin-Zugriff. Dazu habe ich einen dedizierten OpenVPN-Server (auf Ubuntu-Basis) im Netz am Laufen. Die Road Warrior sollen dabei Zugriff auf mehrere VLANs bekommen; ob dazu ein genaues Ruleset nötig ist (auf welche Hosts/Ports darf der Road Warrior zugreifen), ist noch nicht entschieden.

Meine Frage wäre: was spricht dafür oder dagegen, den bisherigen, etablierten OpenVPN-Server weiter zu verwenden? Und was dafür, doch besser auf den OPNsense-eigenen OpenVPN-Server zu migrieren? Ich habe leider noch nicht genug Erfahrungen mit OPNsense, um das gut einschätzen zu können.

Was aus meiner Sicht für einen dedizierten OpenVPN-Server spricht:

• Aufgabenteilung. Die Firewall ist eine Firewall und soll das machen, was sie am Besten kann. One Job - One Tool.
• Sicherheit. Der bisherige OpenVPN-Server ist in das vorhandene Client Management-System eingebunden (Cfengine) und wird vollständig von diesem verwaltet. Zusätzlich wird der Server von Zabbix überwacht. Zertifikate werden über die lokale self-signed PKI verwaltet. Alles etabliert und robust.
• Flexibilität. Ein fully-fledged OpenVPN-Server, bei dem ich Zugriff auf alle Config-Dateien habe, kann eventuell mehr, als wenn ich auf die Verwaltung über die OPNsense-GUI angewiesen bin.
• Volle Kontrolle über die Software. Möglicherweise schnellere Updates und im Notfall kann ich den OpenVPN-Server selbst kompilieren.

Was spricht für den in OPNsense eingebauten OpenVPN-Server:

• Zugriff der Road-Warrior auf die einzelnen VLANs kann feiner kontrolliert werden (ist zumindest meine Annahme?)
• Einfacheres Netzwerk-Layout
• Der OpenVPN-Server ist dort, wo er hingehört - am Zugangspunkt zum Netzwerk.

Was ist eure Meinung dazu?

Das Ganze ist noch in der Planungsphase, also ist noch nichts in Stein gemeisselt und ich habe noch alle Möglichkeiten offen.

[micneu]

meine persönliche meinung, wenn du schon einen OpenVPN server der sich etabliert hat im einsatz hast, dann nimm den doch weiter, so kannst du für OPNsense eine etwas schwächere hardware einsetzen.

[desert_fox]

Okay, ich habe mal alles soweit für den dedizierten OpenVPN-Server vorbereitet. Vorläufiges Test-Setup:

Code: [Select]

    .-------+------.
    |  Roadwarrior |  (OpenVPN-Client)
    '-------+------'
            : 192.168.240.6
            :
      WAN / Internet
            :
            : 192.168.240.1
   .--------+--------.
   |  OpenVPN-Server | (Läuft auf einer VM in VLAN1)
   '--------+--------'
            | 192.168.0.126
            |
          VLAN1 
    (192.168.0.0/24)
            |
            | 192.168.0.254
      .-----:-------.
      |  OPN:sense  +-------. 10.42.0.254
      '-----:-------'       |
10.31.0.254 |               |
            |               |
          VLAN31         VLAN42
     (10.31.0.0/24)   (10.42.0.0/24)
            |               |
10.31.0.10  |               |10.42.0.20
      .-----+------.  .-----+------.
      |   Server1  |  |   Server2  |
      '------------'  '------------'
=> Ziel: Der Roadwarrior soll sowohl auf Server1 (in VLAN31) als auch auf Server2 (in VLAN42) zugreifen können.

Im OpenVPN-Server sind die Routen in die Subnetze hinterlegt:

Code: [Select]

push "route 10.31.0.0 255.255.255.0"
push "route 10.42.0.0 255.255.255.0"
Und in der OPNsense ist der OpenVPN-Server als Gateway hinterlegt:

Code: [Select]

Name: OpenVPN1
Schnittstelle: vlan1
Adressfamilie: IPv4
IP-Adresse: 192.168.0.126
Upstream Gateway: deaktiviert
Ferner Gateway: deaktiviert
Priorität: 255
Sowie eine statische Route:

Code: [Select]

Netzwerk: 192.168.240.0/24
Gateway: OpenVPN1 - 192.168.0.126
=> Stimmt das soweit? Habe ich was vergessen?

=> Welche Firewall-Regeln brauche ich jetzt genau? Ich vermute, wenn der Roadwarrior auf Server im VLAN31 und VLAN42 zugreifen soll, dann brauche ich im VLAN1 (wo der OpenVPN-Server steht) Regeln, um vom OpenVPN-Server aus in die VLANs 31 und 42 zu kommen. Also sowas wie das hier:

VLAN       Protokoll  Quelle            Port  Ziel                        Port  Gateway   Zeitplan  Beschreibung
VLAN1:     IPv4 *     192.168.240.0/24  *     10.0.0.0/8, 192.168.0.0/16  *     *         *         Allow access from VPN-Clients to local subnets

So korrekt?

[desert_fox]

Ich habs mal so implementiert, wie oben beschrieben.

Ich habe dabei eine grundlegenden Verständnisfrage: Warum funktioniert der Zugriff Roadwarrior -> Server1, wenn ich folgende Floating rule angebe:

Code: [Select]

pass in quick inet from 192.168.240.0/24 to any
aber er funktioniert nicht, wenn ich dieselbe Regel stattdessen in VLAN 1 und VLAN 31 erstelle?

Ich habe mich hier im Forum schon eingelesen, habe aber das Gefühl, den Wald vor lauter Bäumen nicht mehr zu sehen.

[liceo]

To "any" sollte für alles gelten. Kannst du eventuell mal nochmals alle IP Konfigurationen auf allen opensense interfaces checken? Insbesondere, ob die Subnet Mask stimmt.

Die Rule erstellst du auf dem Interface bei dem der Traffic "reinkommt" (also auf dem IF mit VLAN1). Den Gateway musst du nicht angeben.

[desert_fox]

Ich habe alles gecheckt, insbesondere die Subnets und die Firewall-Regeln. Leider erfolglos. Nach langem rumprobiere gebe ich es auf und integriere den OpenVPN-Server dort, wo er netzwerktechnisch zugegebenerweise tatsächlich am meisten Sinn macht: direkt auf der OPNsense.

Damit will ich vor allem ein asymmetrisches Routing vermeiden. In den docs zur pfsense steht dazu [1]:

If filtering of traffic between statically routed subnets is required, it must be done on the router and not the firewall since the firewall is not in a position on the network where it can effectively control that traffic.

Das hat mich dann doch überzeugt.

Danke für eure Meinung und Hilfestellung!

[1] https://docs.netgate.com/pfsense/en/latest/routing/static.html#bypass-firewall-rules-for-traffic-on-same-interface