Dies ist der dritte Teil meiner vierteiligen Reihe zum Thema VPN mit der pfSense®.
In diesem Teil geht es darum,  ein ganzes lokales Netz über das VPN zu schicken und zu verhindern das nichts mehr über den normalen Internetzugang fließt.

Folgende Artikel sind bisher erschienen:

Viel Spass!

Update:

20200204: Fehler behoben in der Floating Regel. Nach einem frischen Neustart der pfSense® kamen die Tunnel nicht hoch, da keine DNS Anfragen überhaupt möglich waren. Diese brauchen wir natürlich zumindest hier direkt von der pfSense® aus.

VPN für das gesamte lokale Subnetz

In diesem Szenario soll das gesamte lokale Netz (192.168.1.0/24) komplett über das VPN geleitet werden,
wenn das VPN zu ExpressVPN aktiv ist (permit) und blockieren wenn nicht.

Achtung! Die folgende Konfiguration sorgt dafür das KEIN Internetzugang mehr für das ausgesuchte Subnetz möglich ist,
sollte der VPN Tunnel nicht verbunden sein!

Maßnahme zum verhindern von VPN Leaks:
Im LAN Interface der Firewall wird der normale ungetunnelte Verkehr für den ganze subnetz verboten, sollte der VPN down sein.

Maßnahme zum verhindern von DNS Leaks:

  1. Die pfSense® bekommt ein paar manuelle DNS Server hinterlegt, die nur über das VPN geschickt werden,
  2. es wird per DNS over TLS gearbeitet und
  3. es wird jeglicher andere unverschlüsselte DNS Verkehr, der nicht zur pfSense® selber geht, geblockt.

 

DNS Server

  • Im 2. Teil hatten wir einem einzelnen Rechner noch per DHCP die DNS Server mitgegeben.
    Das legen wir aber nun global auf der pfSense® fest und sorgen noch dafür das die DNS Anfragen nur verschlüsselt rausgehen.
    Denn auf der anderen Seite des Tunnels käme die Anfrage ja sonst unverschlüsselt wieder raus.

    • Geht dazu in System – General Setup und tragt dort unter DNS Server Settings folgende DNS Server ein
      (der grüne Button Add DNS Server fügt der Liste immer eine neue Zeile hinzu).Hier ist wichtig, das jeder Eintrag den ExpressVPN Gateway mitgegeben wird. Sonst würde die pfSense® die Anfrage über alle verfügbaren Kanäle rausjagen.
      Die beiden Optionen DNS Server Override und Disable DNS Forwarder bleiben also deaktiviert.
    • Unter Services – DNS Resolver werden dazu noch folgende Optionen aktiviert:
      • Enable SSL/TLS Service – Respond to incoming SSL/TLS queries from local clients
        Client im Netz dürfen auch anfragen per TLS stellen
      • DNSSEC – Enable DNSSEC Support
        Domains und die Antworten des DNS werden per DNSSEC validiert
      • DNS Query Forwarding – Enable Forwarding Mode
        Hierauf kommt es an: Anfragen nur noch an die DNS Server weiterleiten, die wir weiter oben definiert haben
      • Use SSL/TLS for outgoing DNS Queries to Forwarding Servers
        Und das ganze bitte verschlüsselt!Mit Save speichern und Apply Changes aktivieren
        Damit schickt der DNS Resolver die DNS Anfragen nur noch an die vorgegebenen DNS Server und immer über Port 853.

Alias

  • Nun wird ein Alias für lokale Netz (192.168.1.0/24) angelegt (das macht es später einfacher die Übersicht zu behalten).
    Es wird nicht immer dien Angabe des Subnetzes in den Regeln benötigt und sollte das sich mal ändern, reicht es dann den Alias zu ändern.Im Menü bei Firewall – Aliases – IP
    Name: LOKALNET
    Type: Network(s)
    Network or FQDN: 192.168.1.0 / 24 und mit Save abspeichern.
    Apply Changes nicht vergessen!

 

Outbound NAT

Soll nun also ein Paket vom Testrechner in Richtung VPN fliegen, dann muss es auf die IP Adresse des VPN Providers übersetzt werden:

  • Im Outbound NAT wird eine Regel für diesen Rechner angelegt, damit das NAT’ting in Richtung VPN Provider stimmt.
    • Dafür muss vorher im Menü unter Firewall – NAT – Outbound im Reiter Outbound
      der Outbound NAT Mode auf Hybrid Outbound NAT rule generation umgestellt werden.
      Dann mit Save bestätigen und wiederum mit Apply Changes anwenden.
      Anders als in vielen andere Anleitungen reicht es tatsächlich den hybiden Modus zu nutzen.
      Der manuelle Modus wird meiner Meinung nach nicht benötigt und macht es nur unnötig kompliziert.
    • Damit können wir nun bei den Mappings eigene Regeln hinterlegen (vorher war das deaktiviert), was wir nun auch gleich mit Add durchführen:
      Action: Pass
      Interface: OpenVPN Interface (das was wir in Teil1 erstellt haben)
      Address Family: IPv4 (Es wird kein IPv6 unterstützt)
      Protocol: Any
      Source: LOKALNET (den neu erstellten Alias)
      Destination: Any

      Das muss dann abgespeichert so aussehen:

      Dann mit Apply Changes anwenden.

 

Firewall / Routing

So. Wie fliegt nun ein Paket vom LOKALNET in Richtung VPN? Das Paket soll ja auch korrekt geleitet werden!
Mit einer Firewallregel die auch gleichzeitig das Routing bzw. den Gateway zuweist.
Aber vorher:

DNS blockieren

  • Als allererstes wird unverschlüsselter DNS Verkehr (Port 53) ins Internet blockiert aber zur pfSense® erlaubt.
    Das bekommt man elegant in eine einzige Regel:
    Action: Block
    Interface: LAN
    Address Family: IPv4
    Protocol: UDP
    Source: any
    Destination: INVERT MATCH und This firewall (self)
    Destination Port Range: DNS (53)
  • Als zweites wird vorsichtshalber jeglicher DNS (53 UND 853) Verkehr über das WAN Interface RAUS blockiert.
    Hierfür benötigen wir zwei sog. Floating Regeln mit Quick Option.
    Alle Quick Regeln werden immer als allererstes abgearbeitet: Interfaces – Rules – Floating
    Action: Block
    Quick: Aktiviert (Apply the action immediately on match.)
    Interface: WAN
    Direction: Out
    Address Family: IPv4
    Protocol: TCP/UDP
    Source: INVERT MATCH aktivieren / This Firewall
    Destination Port Range: 1. Regel: 53 und in der 2. Regel: 853


    Was dann in der Übersicht wieder so ausschaut:

 

Umleiten

Die Richtung (Gateway) geben wir nun in einer Firewall Regel an.

  • Im LAN Interface wird der Verkehr vom LOKALNET eine ganz normale PASS Regel erstellt
    Menü Firewall – Rules im Reiter LAN

    Action: Pass
    Interface: LAN
    Address Family: IPv4
    Protocol: Any
    Source: „Single Host or Alias“: LOKALNET
    Destination: Any
  • Mit Druck auf den Button Display Advanced, könnt ihr ganz unten noch den gewünschten Gateway definieren.
    Dort wieder das neu erstellte Interface aus Teil 1 auswählen:

    und mit Save abspeichern.

 

Killswitch

Aber was passiert nun, wenn das VPN nicht aktiv ist und vermieden werden soll, das der unberechtigte Verkehr von dem Testrechner über den lokalen Provider fliegt?

Das kann in der Form mit einer einfachen Regel leider nicht gelöst werden.
Wird, wie oben, ein Gateway manuell zugewiesen dieser auch im Falle der Verfügbarkeit genutzt. Standardmäßig fällt die pfSense® aber auf den normalen Gateway zurück; sie möchte dem Benutzern ja eigentlich auch immer irgendeine Verbindung ermöglichen.

Diesen „Gutes Routing“ Automatismus kann man aber deaktivieren unter:
System – Advanced – Miscellaneous.
Dort die Option Skip rules when gateway is down aktivieren.

Damit wird die Regel, die auf einen inaktiven Gateway verweist, zwar in der GUI angezeigt, aber intern nicht erstellt.
Erst dadurch wird mit einer Firewallregel, direkt unter der oberen, jeglichen Verkehr blockiert der von dem Testrechner kommt.
Vorher wird diese Regel schlichtweg ignoriert! Wichtig!

  • Im LAN Interface wird für den TESTRECHNER nun diese Block Regel erstellt:
    Menü Firewall – Rules im Reiter LAN:Action: Block
    Interface: LAN
    Address Family: IPv4
    Destination: Any
    Source: Single host or alias TESTRECHNER (den neu erstellten Alias)
    Dann mit Apply Changes anwenden.
  • Alle drei Regeln sehen dann zusammen so aus:

    Nach „Apply Changes“ und Reset States (s.o.) geht alles über den VPN Gateway.

 

Tests

Ein paar Tests, das es auch wirklich so ist und alles funktioniert:

  • Ping Test
    • VPN aktiv: ping auf 1.1.1.1 geht durch
    • VPN inaktiv: ping auf 1.1.1.1 geht NICHT durch
  • DNS Lookup Test
    • VPN aktiv: nslookup www.heise.de 1.1.1.1 wird NICHT beantwortet
      VPN aktiv: nslookup www.heise.de wird beantwortet
    • VPN inaktiv: keine DNS Anfragen werden beantwortet
  • Unter Diagnostics – States kann über die Auswahl des Interfaces geprüft werden, was an Verbindungen jeweils aktiv ist.
    Idealerweise verbleibt auf dem WAN interface NTP Verkehr (Port 123) und die VPN Tunnel (Port 1195).
    Auch wenn der VPN Tunnel inaktiv ist!
  • Hier noch ein paar externe Seiten, die noch einen ganzen Zoo an Tests durchführen:

 

Tipps

Falls ihr von euren Provider eine IPv6 Adresse auf dem WAN Interface bekommt, sollten dafür auch entsprechende Block Regeln erstellt werden. Falls der VPN Provider aber gar kein IPv6 unterstützt, langt auch das deaktivieren von IPv6 auf dem WAN Interface und das Deaktivieren der Option Allow IPv6 in System unter Advanced – Networking