Dies ist der zweite Teil meiner vierteiligen Reihe zum Thema VPN mit der pfSense®.
In diesem Teil geht es darum, nur einen bestimmten Rechner oder Port über das VPN zu schicken.

Folgende Artikel sind bisher erschienen:

Viel Spass!

VPN für einen bestimmten Rechner

Dieses Szenario ist das einfachste und soll einen bestimmten Rechner im Netz komplett über das VPN leiten, wenn das VPN aktiv ist (routen) und blockieren wenn nicht.
Hier in dem Beispiel ist das der TESTRECHNER mit der internen IP 192.168.1.150

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

Maßnahme zum verhindern von DNS Leaks:
Der TESTRECHNER bekommt einen externen DNS Server manuell zugewiesen (z.B. fest oder idealerweise über eine eigene DHCP Reservierung)

 

Alias

  • Dazu wird erstmal ein Alias für diesen Rechner angelegt (das macht es später einfacher die Übersicht zu behalten).
    Es wird nicht immer die IP Adresse des Rechner benötigt und sollte die sich mal ändern, reicht es den Alias zu ändern.
    Im Menü bei Firewall – Aliases – IP
    Name: TESTRECHNER
    IP or FQDN: 192.168.1.150 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.
  • 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: TESTRECHNER (den neu erstellten Alias) / 32
    Destination: Any

    Das sollte dann in etwa so aussehen:

    Dann mit Apply Changes anwenden.

 

Firewall / Routing

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

  • Im LAN Interface wird der Verkehr für den TESTRECHNER eine ganz normale PASS Regel erstellt
    Menü Firewall – Rules im Reiter LAN
    Action: Pass
    Interface: LAN (ist vorselektiert)
    Address Family: IPv4
    Source: Single host or alias TESTRECHNER (den neu erstellten Alias)
    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.

 

Firewall / 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 wird mit einer Firewallregel direkt danach gelöst, die in dem Fall jeglichen Verkehr blockiert der von dem Testrechner kommt.

  • Im LAN Interface wird für den TESTRECHNER eine Block Regel erstellt:
    Menü Firewall – Rules im Reiter LAN
    Action: Block
    Interface: LAN (ist vorselektiert)
    Address Family: IPv4
    Source: Single host or alias TESTRECHNER (den neu erstellten Alias)
    Destination: Any
    Dann mit Apply Changes anwenden.
  • Am Ende wird das dann so aussehen. Erst umleiten, dann blocken. Wenn die Reihenfolge nicht stimmen sollte, dann können die Regeln per Drag’n’Drop sortiert werden.

 

DNS Leaks

Folgendes Szenario spielt sich bisher ab:

  • Testrechner fragt pfSense® nach Hostnamen,
  • pfSense® fragt DNS Server des Providers nach der IP,
  • pfSense® antwortet Testrechner mit IP Adresse zum Hostnamen und
  • Testrechner schickt Paket an IP Adresse über VPN

Und das macht gar keinen Sinn. Dann kann ich mir das VPN auch sparen.
Wir müssen also dafür sorgen, das der Testrechner die DNS Anfragen an den DNS Server des Vertrauens direkt schickt.

Hier habt ihr zwei Möglichkeiten:

  1. Am schnellsten geht natürlich, in dem der Testrechner manuell einen DNS Server in der Netzwerkkonfiguration hinterlegt bekommt (Linktipp).
  2. Wer auf der pfSense® den DHCP Server nutzt (das ist der Installations-Standard) und die Rechner auch fleißig die DHCP Clients spielen,
    ist es am elegantesten den Testrechner auch per DHCP mit dem richtigen DNS zu füttern.
    Dafür wird im DHCP Server eine Reservierung für den Testrechner hinterlegt.

    • Öffnet dazu im Menü Status – DHCP Leases und sucht euren Testrechner in der Liste.
    • Klickt dazu unter Actions auf das Linke Plus-Zeichen (Add static mapping),
      dann öffnet sich ein neues Fenster in dem dann schon die MAC Adresse und meist der Hostname vorausgefüllt sind.
      Dort dann noch die Felder IP Address (die IP muss sich außerhalb des Pools befinden) und DNS Servers (Linktipp) befüllen, speichern und anwenden.
    • Damit habt ihr es zentral in der Hand und unabhängig vom eingesetzen Betriebssystem, welcher Rechner wie konfiguriert wird.

 

VPN für einen bestimmten Port

Dieses Szenario ist ebenfalls recht einfach und soll nur einen bestimmten TESTPORT im Netz komplett über das VPN leiten,
wenn das VPN aktiv ist und blockieren wenn nicht. Hier in dem Beispiel ist das der Port 80 (unverschlüsseltes HTTP, Protokoll TCP)

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

Maßnahme zum verhindern von DNS Leaks:
Halt ich in dem Szenario für vernachlässigbar, das es nur um bestimmte Ports geht.

Die Vorgehensweise ist exakt wir bei dem Testrechner, nur mit dem Unterschied das wir anstelle dem TESTRECHNER einen TESTPORT nutzen.
Daher fasse ich das Beispiel hier mal kurz zusammen. Das schafft ihr auch ohne Bilder.

  • Alias für diesen TESTPORT angelegen
  • Im Outbound NAT eine Regel für Protokoll TCP und TESTPORT hinzufügen
  • Im LAN Interface wird das Protokoll TCP und TESTPORT erlaubt (Pass), aber wieder im Display Advanced über das OpenVPN Interface geschickt.
  • Im LAN Interface wird der normale ungetunnelte Verkehr für diesen TESTPORT direkt darunter verboten.

 

Fazit

Wenn einmal verstanden wurde, wie Routung und NAT funktioniert, ist es eigentlich nicht schwer und die pfSense® kann
alle möglichen Szenarien abhängig von Port, Netz oder einzelner IP durch die Weltgeschichte schicken.

Und immer unter dem Menü Diagnostic – States, Reiterkarte Reset States alle aktuellen Einträge entfernen (killen)!
Denn nur neu aufgebaute Verbindungen suchen sich den neuen Weg. Existierende Verbindungen bleiben auf dem alten Pfad!
Auch die Webgui muss danach neu geladen werden, also nicht wundern das die hängt. F5 drücken!