Sélectionner une page

10 GbE – Firewall

par | 19 Déc 2021 | Lab | 1 commentaire

Print Friendly, PDF & Email

Avant la mise en œuvre du réseau 10 GbE, j’utilisais un firewall pfSense CE (Community Edition – version Open Source) à mon domicile et sur le serveur dédié hébergé chez Scaleway. J’ai donc logiquement installé ce type de firewall sur un serveur virtuel de mon serveur VMware mais j’ai eu une mauvaise surprise en constatant que le download plafonnait à 2 Gb/s, loin du 8 Gb/s attendu avec la Freebox Delta…

Sur les forums LaFibre.info et smpfr.info, j’ai lu qu’il fallait acquérir une box Netgate avec une version commerciale de pfSense (pfSense FE) pour atteindre les 8 Gb/s mais aussi quelques autres posts au sujet d’alternatives possibles à pfSense CE.

J’ai donc commencé des tests fin 2019 avec un autre logiciel Open Source, OPNsense, mais j’ai malheureusement constaté la même limite que pfSense. Par ailleurs, et pour info, j’ai trouvé OPNsense moins complet que pfSense notamment dans la gestion du routage IPSec.

Un autre logiciel Open Source, VyOS, semblait bien correspondre à mes besoins mais je ne l’ai pas testé car il ne proposait qu’une interface en ligne de commande alors que je recherchais un confort d’utilisation avec une interface graphique.

Je me suis donc orienté vers un logiciel commercial, Untangle (racheté en 2022 par Arista), dont la version Home Protect Basic vaut 50$/an.

MAJ mars 2022 : depuis février 2022, Netgate, l’éditeur de pfSense, propose une migration de pfSense CE vers pfSense Plus, le nouveau nom de pfSense FE qui était la version installée sur les box firewall commercialisées par Netgate (pour vous y retrouver dans les différentes versions, lisez cet article). Netgate fait miroiter des performances supérieures à 10 Gb/s (tests sur une box équipée de 16 vCPUs et 16 Go RAM), et même sur une plateforme virtuelle. J’ai donc créé une VM (8 vCPUs, le max possible sur VMware ESXi, et 16 Go RAM) avec une version de pfSense Plus Home en suivant ce guide d’installation. Mais quelle déception à l’arrivée ! Le débit max continue à plafonner à 2 Gb/s ! Alors, certes, je suis à la moitié de puissance que le test effectué par Netgate sur sa box mais j’arrive pourtant à des performances cibles à 8 Gb/s sur Untangle avec le même nombre de vCPUs, soit 8 vCPUs, que la VM de test pfSense Plus Home… Je suis donc revenu à Untangle mais j’ai par contre migré le firewall du serveur dédié en version pfSense Plus Home. Pour le moment, je n’ai noté aucun changement par rapport à pfSense CE.

MAJ août 2022 : MAJ des règles du firewall Untangle et des fichiers Excel et PDF joints dans cet article.

Untangle

L’objectif de cet article est de détailler le paramétrage de Untangle mis en œuvre dans le cadre de l’architecture VMware présentée ici.

Installation

L’installation du firewall Untangle :

  • Untangle est installé une machine virtuelle (VM)
  • Le fichier ISO Untangle est copié sur le Datastore de l’hôte VMware
  • Dans les paramètres de la VM, sélectionnez Fichier ISO de la banque de données pour le paramètre Lecteur CD/DVD, puis sélectionnez le fichier ISO Untangle
  • Cliquez sur Mettre sous tension, la VM se lance et l’installation démarre…

L’installation en cours :

L’installation est terminée et le paramétrage va débuter :

Les différentes interfaces réseaux sont identifiées en commencant par le WAN puis le LAN et efin les autres interfaces :

Le DHCP récupère les informations réseaux de l’interface WAN :

On définit l’adresse IP et le masque de l’interface LAN (plus de détail sur le choix de cette adresse dans la suite de l’article) :

Finalisez l’installation en choissisant les dernières options :

Dashboard

Voici la page d’accueil du firewall une fois ce dernier complétement installé et paramétré :

Config – Network

Interfaces

Pour commencer le paramétrage, cliquez sur le menu Config puis Network :

Le premier onglet concerne les interfaces et j’ai rencontré quelques soucis dans leur attribution lors de la création de la machine virtuelle Untangle. En effet, comme pour pfSense, Untangle s’attend à ce que la 1ère interface soit le WAN (la Freebox) et la seconde le LAN. Cet ordre-là a fonctionné tant que je déclarais 4 interfaces, mais à la 5ème interface ajoutée dans WMware, Untangle ne reprenait plus les interfaces dans l’ordre attendu.

Finalement, pour un nombre d’interfaces supérieur à 4, j’ai trouvé le contournement suivant en déclarant sur VMware le WAN en 1ère interface et le LAN non pas en seconde mais en dernière interface. Ce qui donne l’ordre suivant dans ma configuration VMware :

  1. Interface WAN
  2. Interface DMZ1
  3. Interface DMZ2
  4. Interface Routeur 4G secours
  5. Interface LAN

Dans Untangle, on retrouve alors l’ordre attendu dans l’onglet Interfaces du menu Network, soit :

  1. Interface WAN
  2. Interface LAN
  3. Interface DMZ1
  4. Interface DMZ2
  5. Interface Routeur 4G secours

L’interface WAN est paramétrée en DHCP et récupère automatiquement l’adresse IP V4 full-stack commandée sur l’espace abonné Free. Vous pouvez également modifier les DNS de l’opérateur par les suivants :

Pour les interfaces physiques (parent) pour lesquelles j’ai ensuite créé des VLAN (enfant), soit LAN, DMZ1 et DMZ2, je les ai renommés en ajoutant le suffixe MGMT et en utilisant un réseau en 10.0.XXX.0/24 afin de pouvoir utiliser par la suite les noms abrégés, LAN, DMZ1 et DMZ2 avec un sous-réseau en 192.168.XXX.0/24 pour ces interfaces utilisant des VLAN.

Ce qui donne pour l’interface physique LAN, ou parent LANMGMT, qui sera désactivée une fois le VLAN créé :

Pour créer l’interface enfant LAN qui sera réellement utilisée, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent LANMGMT, le VLAN Tag 10 et l’adresse IP 192.168.10.1/24 :

On procède de la même façon pour tous les autres VLAN comme précisé dans l’article Switches et VLAN.

Auparavant, configurez le DHCP dans l’onglet DHCP Configuration. Pour l’interface LAN, la plage DHCP est comprise entre les adresses IP 192.168.10.129 et 192.168.10.254 :

Pour l’interface enfant WIFI, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent LANMGMT, le VLAN Tag 20 et l’adresse IP 192.168.20.1/24 :

Dans l’onglet DHCP Configuration, paramétrez la plage DHCP pour l’interface WIFI qui est comprise ici entre les adresses IP 192.168.20.129 et 192.168.20.254 :

Pour l’interface enfant WIFIGUEST, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent LANMGMT, le VLAN Tag 30 et l’adresse IP 192.168.30.1/24 :

Dans l’onglet DHCP Configuration, paramétrez la plage DHCP pour l’interface WIFIGUEST qui est comprise ici entre les adresses IP 192.168.30.129 et 192.168.30.254 :

Pour l’interface enfant DOMO, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent LANMGMT, le VLAN Tag 40 et l’adresse IP 192.168.40.1/24 :

Dans l’onglet DHCP Configuration, paramétrez la plage DHCP pour l’interface DOMO qui est comprise ici entre les adresses IP 192.168.40.129 et 192.168.40.254 :

Pour l’interface enfant SURVEILLANCE, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent LANMGMT, le VLAN Tag 50 et l’adresse IP 192.168.50.1/24 :

Dans l’onglet DHCP Configuration, paramétrez la plage DHCP pour l’interface SURVEILLANCE qui est comprise ici entre les adresses IP 192.168.50.129 et 192.168.50.254 :

L’interface physique DMZ1, ou parent DMZ1MGMT, qui sera désactivée une fois le VLAN créé :

Pour l’interface enfant DMZ1, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent DMZ1MGMT, le VLAN Tag 90 et l’adresse IP 192.168.90.1/24 :

Pas de configuration DHCP pour l’interface DMZ1.

L’interface physique DMZ2, ou parent DMZ2MGMT, qui sera désactivée une fois le VLAN créé :

Pour l’interface enfant DMZ2, cliquez sur le bouton Add Tagged VLAN Interface dans l’onglet Interfaces du menu Network et indiquez l’interface parent DMZ1MGMT, le VLAN Tag 91 et l’adresse IP 192.168.91.1/24 :

Pas de configuration DHCP pour l’interface DMZ2.

Pour mémoire, le rôle des différents VLAN :

  • Le VLAN LAN (10) héberge les serveurs accessibles directement depuis les PC :
    • Le serveur AppServer1 sur lequel est installé le logiciel Avahi (mDNS)
    • Le serveur WebServer1 qui supporte les applications d’administration comme Cockpit, InfiniteWP et UniFi Network Controller
    • Les différents NAS qui servent de stockage de fichiers pour l’un et de support de sauvegarde pour l’autre
    • Le serveur WindowsServer qui est un serveur Windows Server 2016 hébergeant principalement Active Directory, le service d’annuaire LDAP de Microsoft
  • Le VLAN WIFI (20), Wifi « privé » pour les PC portables, tablettes et smartphone de la famille qui auront accès aux différents services du LAN
  • Le VLAN WIFIGUEST (30), Wifi pour les invités avec uniquement un accès à Internet et à la DMZ1,
  • Le VLAN DOMO (40) héberge le serveur domotique Jeedom et tous les équipements domotiques Wifi
  • Le VLAN SURVEILLANCE (50) accueille les caméras de surveillance IP filaires (Axis) et Wifi (Arlo et Netatmo)
  • Le VLAN DMZ1 (90) héberge les serveurs suivants :
  • Le VLAN DMZ2 (91) héberge le serveur VPN avec l’application OpenVPN Access Server

Pour finir, l’interface 4G est paramétrée en DHCP et récupère automatiquement l’adresse IP du routeur « 4G » de secours, GL-iNet MT300N v2 Mango, qui possède une connexion 4G via une clé USB 4G Huawei E8372h :

Services

Dans l’onglet Services du menu Network, déclarez les ports TCP d’accès à la page d’administration Untangle, par exemple :

Port Forward Rules

Dans l’onglet Port Forward Rules du menu Network, différents ports TCP/UDP en provenance de l’extérieur (WAN) sont redirigés vers les différents serveurs de l’infrastructure suivants :

  • Les ports 8000 (Zed Online), 27015 (CS:GO) et 25565 (Minecraft) vers le serveur de jeux situé dans la DMZ1 (Gameserver)
  • Les ports 443 (Web HTTPS) et 32400 (Plex) vers le serveur Web situé dans la DMZ1 (Webserver3)
  • Le port VPN et le port d’accès vers le serveur Web OpenVPN Access Server situé dans la DMZ2 et aux profils VPN (Openvpnas)
  • Depuis le serveur dédié hébergé chez Scaleway uniquement, le port 636 (LDAPS) vers le serveur Windows situé sur le LAN (Windows Server)

DNS Server

Dans l’onglet DNS Server du menu Network, les différents noms des services utilisés sur le Web sont déclarés en adresses IP statiques ainsi que le nom de domaine :

DHCP Server

Dans l’onglet DHCP Server du menu Network, pour chaque équipement de l’infrastructure une adresse IP fixe lui est attribuée conformément au tableau de référence Excel créé à cet effet :

Advanced – Network Cards

Dans l’onglet Advanced puis Network Cards du menu Network, le MTU est fixé à 9000 (Jumbo Frames) pour les interfaces eth1 (LAN), eth2 (DMZ1) et eth3 (DMZ2) et à Auto pour les autres :

Advanced – Access Rules

Dans l’onglet Advanced puis Access Rules du menu Network, autorisez ou non les protocoles les plus courants sur les interfaces WAN et non WAN :

Config – Administration

Admin

Dans l’onglet Admin du menu Administration, ajoutez les administrateurs Untangle et indiquez les sous-réseaux depuis lesquels ils pourront accéder à l’interface d’administration :

Certificates

Dans l’onglet Certificates du menu Administration, déclarez le certificat SSL :

Pour les domaines officiels (.com, .org, etc.), j’utilise le plus souvent un certificat de type « wildcard » proposé par Namecheap.

Pour les certificats auto-signés, j’utilise l’application XCA qui est un outil de management de certificats X.509.

Par exemple, les certificats auto-signés utilisés sur les différentes DMZ :

Lors de la création d’un certificat serveur, sélectionnez le modèle TLS_server pour que les paramètres s’ajustent automatiquement, notamment :

  • X509v3 Extended Key Usage : TLS Web Server Authentication
  • X509v3 Subject Alternative Name : DNS:copycn
  • Netscape Cert Type : SSL Server

Lors de la création d’un certificat client, sélectionnez le modèle TLS_client pour que les paramètres s’ajustent, notamment :

  • X509v3 Extended Key Usage : TLS Web Client Authentication
  • Netscape Cert Type : SSL Client

Lors de la création d’un certificat CA auto-signé, sélectionnez le modèle CA

Google

Dans l’onglet Google du menu Administration, liez le compte Google Drive à Untangle pour permettre une sauvegarde quotidienne automatique de la configuration sur Drive :

Config – Email

Dans le menu Email, renseignez le serveur SMTP et l’adresse Email qui recevra tous les rapports, les alertes, etc. :

Config – Upgrade

Dans le menu Upgrade, définissez si vous désirez effectuer des mises à jour automatique et à quelle heure dans la journée :

Config – System

Dans l’onglet Regional du menu System, indiquez la langue et les options régionales :

Apps

WAN Failover

Pour la suite, rendez-vous dans le menu Apps :

Je vais détailler les principales applis de ce menu.

Pour commencer, cliquez sur l’application WAN Failover, qui peut détecter une panne sur une interface WAN et rerouter le trafic vers une autre interface disponible et activez-la dans l’onglet Status :

On retrouve dans cette application les deux interfaces pour lesquelles le paramètre is WAN a la valeur true dans l’onglet Interfaces du menu Config/Network, c’est-à-dire les interfaces WAN et 4G.

Dans l’onglet Tests de l’application WAN Failover, définissez le type de test que vous souhaitez réaliser pour déclarer une interface active ou non et provoquer le basculement vers la seconde interface :

L’interface 4G est connecte à un petit routeur, le GL-iNet MT300N v2 Mango. Dans l’onglet Interfaces du menu Config/Network, la configuration est automatique (DHCP) et récupère une adresse IP du routeur GL-iNet dans son sous-réseau par défaut, 192.168.9.0/24. Le routeur est lui-même accessible depuis le LAN via l’adresse d’administration par défaut 192.168.9.1

La clé 4G Huawei E8372h n’est pas connectée au routeur GL-iNet car l’abonnement 4G, SFR Internet Partout, s’active au premier trafic réseau détecté pour un coût fixe de 3€/jour. Je connecte donc la clé 4G sur le port USB du routeur uniquement si la Freebox est HS. L’administration de la clé 4G est accessible depuis le LAN via l’adresse d’administration par défaut 192.168.8.1

Intrusion Prevention

Dans l’onglet Status, activez l’application Intrusion Prevention qui analyse, détecte et bloque les attaques et le trafic suspect à l’aide de signatures :

Dans l’onglet Rules, activez toutes les règles proposées :

Firewall

Dans l’onglet Status de Firewall, activez le firewall qui signalera et bloquera les sessions en fonction des règles que vous allez définir :

Dans l’onglet Rules, définissez les règles de firewall que vous souhaitez activer :

Je suis parti sur la même logique que pfSense dans la création des règles firewall, c’est-à-dire en partant toujours de l’interface source à destination d’autres interfaces, serveurs et/ou services avec les autorisations suivies par les interdictions.

Ce qui donne par exemple pour l’interface DMZ1 tout abord les autorisations suivantes utiles au bon fonctionnement des serveurs :

  • Serveur à serveur/service :
    • Du serveur WebServer3 vers le Windows Server présent sur le LAN uniquement pour le service d’annuaire (LDAPS). Les applications Nextcloud, Piwigo, etc., pourront ainsi utiliser l’annuaire AD centralisé pour autoriser les utilisateurs reconnus à se connecter
    • Du serveur WebServer3 vers les NAS2 présent sur le LAN uniquement pour le service de système de fichiers NFS afin d’assurer les sauvegardes des bases de données SQL vers le NAS2
    • Du serveur WebServer3, uniquement pour le service Web (HTTP), vers le Tuner TV HDHomeRun pour accéder à la TV et vers le serveur Domotique pour accéder à l’application Jeedom
  • Interface à serveur/service
    • De l’interface DMZ1 vers le serveur NAS1 pour le service de temps (NTP) afin de permettre à tous les serveurs présents sur la DMZ1 d’utiliser le même serveur de temps et d’être ainsi sur la même horloge
  • Puis on finit par une règle qui interdit tout trafic de l’interface DMZ1 vers toutes les autres interfaces non WAN existantes.

Pour y voir plus clair, j’ai créé un fichier Excel qui recense les différentes règles du firewall Untangle. Vous pouvez le télécharger ici ou ici au format PDF. Avec le format Excel, vous avez la possibilité de filtrer toutes les colonnes du tableau (Source, Destination…) afin de détailler les règles par interface ou serveur.

A noter, les règles sont optimisées sur Untangle (62 règles vs 131 dans le tableau Excel). En effet, lorsque j’autorise par exemple plusieurs services (HTTP, HTTPS, SSH) de l’interface LAN vers d’autres interfaces, une seule règle suffit avec Untangle. Par contre, le détail dans le fichier Excel (une ligne par service ou port) permet de vérifier l’exhaustivité des règles.

Tunnel VPN

Dans l’onglet Status, activez l’app Tunnel VPN qui permet de disposer de connexions chiffrées vers des serveurs VPN distants :

Dans l’onglet Tunnels, ajoutez les serveurs VPN distants :

Le premier tunnel VPN, que j’ai nommé NordVPNTunnel, est une connexion à un serveur VPN du fournisseur NordVPN auprès duquel j’ai souscrit un abonnement :

Dans la liste déroulante Provider, vous pouvez choisir le fournisseur VPN NordVPN mais je vous conseille de sélectionner Custom ovpn file with username/password et de récupérer un fichier de configuration sur le site Web de NordVPN.

Cliquez sur ce lien pour télécharger un fichier de configuration en choisissant le pays, le type de serveur (VPN Standard) et le protocole (OpenVPN UDP) :

Sur cet autre lien, vous avez accès à l’ensemble des fichiers de configuration OpenVPN de NordVPN, tous serveurs et tous pays :

Le second tunnel VPN, que j’ai nommé DSVPNTunnel, est une connexion vers le serveur VPN du firewall pfSense que j’ai configuré sur le serveur dédié que je loue chez Scaleway :

Dans la liste déroulante Provider, sélectionnez Custom ovpn file with username/password puis téléchargez un fichier de configuration OpenVPN en appuyant sur le bouton Select VPN Config File.

Le fichier OpenVPN utilisé :

client
dev tun
remote serveur_distant.com n°port udp4
persist-tun
persist-key
resolv-retry infinite
comp-lzo no
verb 3
auth-nocache
auth-user-pass
fast-io

# Cipher and Hash Algorithms
ncp-ciphers AES-256-GCM:AES-256-CBC
cipher AES-256-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
tls-client
tls-timeout 10
auth SHA512

# Certificates
verify-X.509-name "serveur_distant.ds" name
key-direction 1
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
</key>
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-crypt>

Pour finir, rendez-vous dans l’onglet Rules où on définit les règles qui permettront d’utiliser ces connexions sécurisées. Dans l’exemple suivant, tous les flux réseau d’un PC portable seront redirigés vers n’importe quel VPN disponible et l’accès à un site Web, mon-ip.com, transitera par le serveur NordVPN :

IPsec VPN

Dans l’onglet Status, activez l’app IPsec VPN qui autorise des connexions chiffrées vers des serveurs IPsec distants :

En 2018, j’utilisais une connexion IPsec entre le firewall pfSense de mon domicile et le firewall pfSense hébergé sur un serveur dédié chez Scaleway.

Très facile d’utiliser IPsec sur pfSense depuis qu’il est possible de router différents réseaux sur cette connexion (option Routed VTI).

Malheureusement, il n’existe pas l’équivalent sur Untangle même si j’ai réussi à créer une connexion IPsec entre le firewall Untangle et le firewall pfSense distant.

Peut-être faut-il créer un IPsec VPN mobile depuis l’onglet VPN Config pour se connecter au tunnel IPsec pfSense ou inversement ? Mais c’est une option que je n’ai pas testée pour le moment…

J’ai préféré créer un tunnel GRE qui permet de router facilement les réseaux concernés. Un tunnel GRE n’est pas chiffré contrairement à IPsec mais j’utilise sur ce tunnel des protocoles qui eux sont chiffrés comme HTTPS, SSH, etc., afin de communiquer entre les différents réseaux.

Dans l’onglet IPsec Tunnels, créez votre tunnel IPsec :

Les paramètres du tunnel IPsec :

  • Connection Type : Tunnel
  • IKE Version : IKEv2
  • Connect Mode : Always Connected
  • Interface : WAN
  • Remote Host : le nom d’hôte distant ou son adresse IP
  • Local Identifier : le nom d’hôte local ou son adresse IP
  • Remote Identifier : le nom d’hôte distant ou son adresse IP
  • Local Network : le réseau privé local – ex. 10.168.11.1/30
  • Remote Network : le réseau privé distant – ex. 10.168.11.2
  • Secret Share : la clé secrète partagé entre les deux côtés du tunnel IPsec
  • DPD Interval : 30
  • DPD Timeout : 120
  • Phase 1 IKE :
    • Encryption : AES-256
    • Hash : SHA-256
    • DH Key Group : 14 (modp2048)
    • Lifetime : 28800
  • Phase 2 ESP :
    • Encryption : AES-256
    • Hash : SHA-256
    • DH Key Group : 14 (modp2048)
    • Lifetime : 3600

Dans l’onglet GRE Networks, indiquez le sous-réseau privé GRE, 10.168.14.0/24, et créez un tunnel GRE :

Précisez l’interface concernée (WAN), l’hôte distant et le réseau distant soit la DMZ du serveur dédié Scaleway, 192.168.190.0/24 :

Configuration Backup

Dans l’onglet Status, activez l’app Configuration Backup qui permet de réaliser des sauvegardes de la configuration du firewall Untangle sur Google Drive :

Définissez l’heure de la sauvegarde :

Le lien avec Google Drive se fait dans le menu Config/Administration/Google. Sur cette page, définissez le nom du dossier de sauvegarde dans le Cloud :

pfSense

L’objectif de cet article est de détailler le paramétrage de pfSense mis en œuvre dans le cadre de l’architecture VMware présentée ici.

Installation

L’installation du firewall pfSense CE :

  • pfSense CE (pfSense Plus Home depuis mars 2022) est installé sur une machine virtuelle (VM) d’un hôte VMware hébergé sur un serveur dédié Scaleway
  • Copiez le fichier ISO pfSense sur le Datastore de l’hôte VMware
  • Dans les paramètres de la VM, sélectionnez Fichier ISO de la banque de données pour le paramètre Lecteur CD/DVD, puis sélectionnez le fichier ISO pfSense CE
  • Cliquez sur Mettre sous tension, la VM se lance et l’installation démarre…

Pour la suite de l’installation, je vous envoie vers Google où vous trouverez de nombreuses infos à ce sujet.

Dashboard

Voici la page d’accueil du firewall une fois ce dernier complétement installé et paramétré :

Interfaces

Interface Assignments

Lors de l’installation de la VM, pfSense demande l’affectation des adaptateurs réseaux aux deux interfaces WAN et LAN :

  • Pour l’interface WAN, indiquez l’adaptateur réseau vmx0
  • Pour l’interface LAN que l’on renommera plus tard en DMZ, indiquez l’adaptateur réseau vmx1
  • Les autres interfaces seront déclarées par la suite via le GUI pfSense

Définissez ensuite pour chaque interface une adresse IP :

  • Pour l’interface WAN, saisissez l’adresse IP Failover fournie par Scaleway (voir article VMware), un masque sur 24 bits, et pas de gateway pour le moment
  • Pour l’interface LAN (ou DMZ), j’ai saisi l’adresse suivante 192.168.190.1, un masque sur 24 bits, pas de gateway et une plage DHCP (192.168.190.129 à 192.168.190.254)

Scaleway fournit une gateway universelle, 62.210.0.1, pour les différentes adresses IP Failover. Cette gateway ne fait pas partie du même sous-réseau que votre IP Failover. Il va donc falloir le préciser via une option dans le menu System/Routing du GUI pfSense.

J’ai créé une VM Linux Lite afin de pouvoir se connecter via le LAN (http://192.168.190.1) tant que le WAN n’est pas opérationnel. A la première connexion au GUI pfSense, une fois que vous avez passé l’assistant de configuration proposé par défaut, cliquez sur le menu System, puis Routing. Et dans l’onglet Gateways, cliquez sur le bouton Add et ajoutez la gateway 62.210.0.1 (sur cette copie écran l’action a déjà été réalisée et la gateway s’appelle WANGW) :

Sur cette même page, cliquez sur le bouton Display Advanced puis cochez la case de la dernière option, Use non-local gateway, qui propose d’utiliser une gateway non comprise dans le sous-réseau de l’interface WAN :

Les différentes interfaces une fois l’installation complétement finalisée (GRE, IPsec, OpenVPN…) :

C’est sur cette page que vous allez pouvoir définir de nouvelles interfaces comme GREHOME, IPSECHOME et NORDVPN suite à la création des différentes connexions GRE, IPsec et OpenVPN. Je développe ci-dessous les interfaces WAN, DMZ et GREHOME. Pas les deux dernières interfaces, IPSECHOME et NORDVPN, dont le paramétrage est identique à celui de GREHOME.

WAN

Il est important de revenir sur cette interface dans le menu Interfaces/WAN une fois que la gateway a été créée (menu System/Routing) pour l’attribuer au WAN. Dans la liste déroulante de l’option IPv4 Upstream gateway, choisissez la gateway WANGW – 62.210.0.1 :

Pour les interfaces WAN, bien sûr WAN et NordVPN (VPN client), cochez les cases Block private networks and loopback addresses et Block bogon networks :

DMZ

Initialement cette interface s’appelle LAN, c’est sur cette page que vous allez pouvoir la renommer en DMZ :

GREs

Dans le menu Interface/Assignments, cliquez sur l’onglet GREs et ajoutez une nouvelle connexion GRE en cliquant sur le bouton Add :

Indiquez l’adresse IP WAN du routeur Untangle (Freebox Delta) et les adresses IP locales et distantes du tunnel GRE qui se trouvent dans le même sous-réseau que l’interface GRE du routeur Untangle :

System

General Setup

Dans le menu System puis General Setup, indiquez le nom du serveur, son nom de domaine et les DNS, qui sont les suivants :

  • Les DNS OpenDNS soit 208.67.222.222 et 208.67.220.220
  • Le DNS Cloudflare soit 1.1.1.1
  • Le DNS Quad9 soit 9.9.9.9

Précisez le fuseau horaire, les serveurs de temps (voir le chapitre NTP), la langue et les différentes options pfSense :

Advanced – Admin Access

Si vous utilisez un certificat, utilisez une connexion HTTPS et indiquez le certificat utilisé (voir le chapitre Certificate Manager) et le port s’il est différent du port HTTPS (443) :

Activez le Secure Shell et précisez le port. On va créer une clé SSH RSA et utiliser l’option Public Key Only, mais pour débuter, choisissez l’option Password or Public Key et le port SSH par défaut (22) :

Clé SSH RSA

Pour créer une clé SSH RSA, clé publique et clé privée, installez MobaXterm (c’est ce logiciel que j’utilise) ou PuTTY.

Lancez MobaKeyGen (menu Tools) ou PuTTYgen selon le logiciel utilisé (c’est la même interface). Dans la section Parameters, sélectionnez RSA et modifiez le nombre de bits à 4096 pour une meilleure sécurité (par défaut 2048). Appuyez sur le bouton Generate tout en bougeant la souris dans la fenêtre de l’application pour générer le plus de caractères aléatoires possible :

Il est nécessaire de créer une passphrase pour sauvegarder la clé privée puis pour vous authentifier lors de la connexion SSH au serveur. Rendez-vous sur le site Diceware et créez une passphrase en français d’au moins 8 mots :

Collez la passphrase générée dans les 2 cases prévues à cet effet dans MobaKeyGen et cliquez sur Save public key pour sauvegarder la clé SSH RSA publique et Save private key pour sauvegarder la clé SSH RSA privée, par exemple sous le nom ssh-rsa-ma_cle_privee.ppk

Copiez également le texte dans le premier bloc qui représente la clé SSH RSA publique dans le format attendu par le serveur et qui sera copiée dans le ~/.ssh/fichier authorized_keys du compte utilisateur :

Pour pfSense, pas la peine d’aller modifier en mode console le fichier ~/.ssh/fichier authorized_keys car il suffit de coller la clé SSH RSA publique que vous venez de copier dans la case Authorized SSH Keys du compte administrateur de votre firewall pfSense accessible depuis le menu System/User Manager/Users :

A noter que la ligne se termine par un commentaire, par exemple rsa-key-20220124 que vous pouvez remplacer par un texte plus parlant comme par exemple le nom d’utilisateur et le nom du serveur soit admin@routeur2

Dans le client SSH MobaXterm, créez une nouvelle session SSH, renseignez le nom du serveur, le port, cochez la case Use private key et indiquez l’emplacement sur votre PC de la clé SSH privée, C:/…/ssh-rsa-ma_cle_privee.ppk :

Connectez-vous en SSH au serveur qui vous demandera alors la passphrase. Si la connexion se passe bien, revenez sur le GUI pfSense dans le menu System/Advanced/Admin Access et choisissez maintenant l’option Public Key Only et le port que vous souhaitez utiliser (mettez à jour MobaXterm si ce n’est plus le port 22).

Advanced – Networking

J’ai dû réinstallé fin 2021 VMware et les différentes VM suite à une panne, le matériel n’étant plus maintenu chez Scaleway pour une offre datant de 2016…

Maintenant, sur cette gamme plus récente datant probablement de 2019 ou 2020, je n’ai pas rencontré de blocage de l’IP Failover pour cause d’utilisation d’IPv6 suite à l’installation de pfSense.

Néanmoins je vous invite à bloquer, juste après l’installation de pfSense, tout trafic IPv6 en ne cochant pas la case Allow IPv6 dans le menu System/Advanced/Networking, et en cochant les cases Prefer IPv4 over IPv6 et IPv6 DNS entry :

Advanced – Miscellaneous

Dans le menu System/Advanced/Miscellaneous, vous pouvez sélectionner dans la fenêtre déroulante de l’option Cryptographic Hardware le module AES-NI CPU-based Acceleration pour accélérer les fonctions de chiffrement et de déchiffrement :

Advanced – Notifications

Dans le menu System/Advanced/Notifications, déclarez un serveur mail afin de recevoir les notifications du firewall :

Routing – Gateways

Une fois que vous avez déclaré les différentes interfaces, vous récupérez dans le menu System/Routing/Gateways, la liste des différentes gateways :

Définissez la gateway IPv4 par défaut, WANGRP, qui est un groupe de gateways.

Routing – Static Routes

Dans le menu System/Routing/Static Routes, définissez les routes statiques pour le tunnel GRE, dans cet exemple, vers le LAN, le Wifi et l’OpenVPN du domicile :

Dans cet exemple, le Destination Network est le LAN du domicile (192.168.10.0/24) et la Gateway est celle du tunnel GRE :

Routing – Gateway Groups

Dans le menu System/Routing/Gateway Groups, créez un groupe de différentes gateways avec une condition pour basculer de l’une à l’autre :

Dans cet exemple, la gateway WAN est définie en priorité 1 ou Tier 1 et la gateway NordVPN en priorité 2 ou Tier 2. La condition pour basculer de l’une à l’autre est choisie via l’option Trigger Level et ici elle est définie à Member Down :

Certificate Manager

Dans le menu System/Cert. Manager/CAs, ajoutez les certificats CA (autorité de certification) des différents certificats que vous allez utiliser dans les différentes applications de ce firewall :

Dans le menu System/Cert. Manager/Certificates, ajoutez les certificats utilisés par les applications :

Plus d’infos au sujet de la création des certificats dans ce chapitre.

Package Manager

Dans le menu System/Package Manager, vous pouvez installer différents packages, notamment Open-VM-Tools puisque pfSense est une VM. Je détaille dans cet article Snort et Darkstat :

User Manager

Dans le menu System/User Manager/Authentification Servers, définissez le serveur LDAP, en l’occurrence l’Active Directory (AD) du Windows Server installé à mon domicile, qui permettra d’authentifier les utilisateurs des serveurs OpenVPN pfSense :

Indiquez un nom, par exemple AD Server, le nom du server, le port, le protocole, le Base DN et les Containers :

Indiquez le compte AD ou Bind credentials et son mot de passe, et les différents attributs LDAP :

Testez la connexion via le menu Diagnostics/Authentification

Firewall

Aliases

Dans le menu Firewall/Aliases/IP, définissez les différents alias que vous pourrez utiliser dans différentes applications de pfSense :

NAT – Port Forward

Dans le menu Firewall/NAT/Port Forward, définissez la redirection de port vers le serveur et le port souhaité (les règles utilisent les alias) :

NAT – Outbound

Dans le menu Firewall/NAT/Outbound, choisissez le mode Hybrid qui utilise à la fois les règles manuelles tout en utilisant les règles automatiques. Le NAT Outbound ou sortant ou encore source, contrôle la manière dont pfSense traduira l’adresse source et les ports pour le trafic quittant une interface. Le firewall ne définissant pas automatiquement les règles pour toutes les interfaces, il faudra donc les ajouter manuellement pour les interfaces GRE et IPsec :

Rules – WAN

Définissez, dans le menu Firewall/Rules/WAN, les règles pour l’interface WAN (on retrouve automatiquement les règles de redirection de port) :

Rules – DMZ

Dans le menu Firewall/Rules/DMZ, j’ai laissé les règles par défaut, notamment la seconde qui autorise tout le trafic sortant de cette interface :

Rules – GRE

Dans le menu Firewall/Rules/GREHOME, j’ai ajouté une règle qui autorise tout le trafic sortant (idem pour les 3 interfaces suivantes, NORDVPN, IPsec et OpenVPN) :

Services

DHCP Server

Lors de la création des interfaces, une plage DHCP a été définie uniquement pour la DMZ et on retrouve ces informations dans ce menu, Services/DHCP Server/DMZ :

DNS Resolver

Dans le menu, Services/DNS Resolver/General Settings, le service DNS Resolver est activé avec la possibilité d’utiliser les requêtes DNS over SSL/TLS vers les serveurs DNS (choisissez le certificat du serveur) :

Cochez également les cases suivantes :

  • DNSSEC pour renforcer l’authentification du DNS
  • DNS Query Forwarding (cochez les 2 cases) ce qui permet d’envoyer les requêtes DNS SSL/TLS vers les serveurs déclarés dans le menu System/General Setup
  • DHCP Registration et Static DHCP afin d’inscrire les différents baux et adresses statiques DHCP dans le DNS Resolver

Dans Host Overrides, indiquez l’adresse IP que vous souhaitez renvoyer pour un host comme dans cet exemple pour le NAS1 et le Windows Server :

Dans le menu, Services/DNS Resolver/AdvancedSettings :

Cochez les cases suivantes pour renforcer la sécurité :

  • Hide Identity
  • Hide Version
  • Prefetch Support
  • Prefetch DNS Key Support
  • Harden DNSSEC Data

NTP

Dans le menu, Services/NTP/Settings, activez le service et précisez le serveur NTP préféré, dans cet exemple le serveur NAS1 :

Snort

Snort est un Système de Détection d’Intrusion (IDS) installé via le menu Package Manager. Dans le menu Services/Snort/Interfaces, définissez l’interface concernée soit le WAN :

Dans Wan Settings, activez Block Offenders et Kill States pour bloquer automatiquement les IP qui ont générées une alerte Snort :

Une « Pass List » est également créée, elle contient par défaut les adresses LAN, WAN, VPN, etc. On pourra la compléter avec un alias dans le menu Services/Snort/Pass Lists :

Dans WAN Categories, activez les différentes règles que vous aurez choisies dans le menu Services/Snort/Global Settings :

Dans Wan Rules, vous avez la liste des règles actives :

Dans le menu Services/Snort/Global Settings, choisissez les règles que vous souhaitez activer :

Dans le menu Services/Snort/Updates, vous pouvez mettre à jour toutes les règles que vous avez choisies précédemment :

Toutes les alertes qui ont matchées avec les règles sont visibles dans le menu Services/Snort/Alerts. Vous pouvez ajouter les règles et les IP sources qui ont matchées à tort avec une règle dans la Suppression List en cliquant sur la croix rouge :

La liste des hosts bloqués par Snort sont visibles dans le menu Services/Snort/Blocked. Vous pouvez supprimer un host bloqué en cliquant sur la croix rouge :

Dans le menu Services/Snort/Pass Lists, vous pouvez préciser un alias pour les adresses IP que vous souhaitez exclure de l’analyse Snort :

Dans le menu Services/Snort/Suppression List, vous retrouvez les règles et les adresses IP que vous avez exclues dans le menu Services/Snort/Alerts :

Diagnostics

Darkstat

Darkstat est un outil d’analyse et de statistique réseau installé via le menu Package Manager. L’interface graphique de Darkstat :

Dans le menu Diagnostics/Darkstat Settings, définissez les différentes interfaces qui seront analysées et le port de l’application et le nom de l’hôte pour la consultation Web :

VPN

IPsec

Pour le moment j’utilise un tunnel GRE, mais j’ai tout de même créé un tunnel IPsec avec Untangle même si je n’ai pas encore trouvé d’utilisation pratique. Tout commence dans le menu VPN/IPsec :

Les paramètres de la phase 1 IKE (P1) :

  • Key Exchange version : IKEv2
  • Internet Protocol : IPv4
  • Interface : WAN
  • Remote Gateway : le nom d’hôte distant ou son adresse IP
  • My Identifier : le nom d’hôte local ou son adresse IP
  • Peer Identifier : le nom d’hôte distant ou son adresse IP
  • Pre-Shared Key : la clé secrète partagé entre les deux côtés du tunnel IPsec
  • Encryption Algorithm :
    • Algorithm : AES
    • Key Length : 256 bits
    • Hash : SHA256
    • DH Key Group : 14 (2048 bits)
  • Dead Peer Detection (DPD) : cochez la case

Les paramètres de la phase 2 ESP (P2) :

  • Mode : Routed (VTI) – mode qui permet de créer une gateway pour router les réseaux locaux vers l’autre bout du tunnel… du moins entre firewall pfSense…
  • Local Network : adresse IP locale
  • Remote Network : adresse IP distante
  • Protocol : ESP
  • Encryption Algorithms : AES 256 bits
  • Hash Algorithms : SHA256
  • PFS key group : 14 (2048 bits)
  • Life Time : 3600

OpenVPN Servers

Créez vos serveurs VPN via le menu VPN/OpenVPN/Servers :

OpenVPN Servers – Clients

Le premier serveur OpenVPN permet à des clients OpenVPN, se présentant sur le port TCP HTTPS (443), de se connecter au firewall pfSense et de bénéficier ainsi de l’adresse IP WAN de ce serveur. Les paramètres sont les suivants :

  • Server Mode : Remote Access (SSL/TLS + User Auth)
  • Backend for authentification : le serveur AD défini via le menu User Manager
  • Protocol : TCP on IPv4 only
  • Device mode : tun – Layer 3 Tunnel Mode
  • Interface : WAN
  • Local port : 443

La suite des paramètres :

  • TLS Configuration : cochez la case
  • TLS Key : insérez une clé TLS (OpenVPN Static Key)
  • TLS Key Usage Mode : TLS Encryption and Authentification
  • TLS keydir direction : Use default direction
  • Peer Certificate Authority : certificat CA enregistré dans le magasin de certificats pfSense
  • Server Certificate : certificat enregistré dans le magasin de certificats
  • DH Parameter Length : 4096 bit
  • ECDH Curve : Use default

La suite des paramètres :

  • Data Encryption Negotiation : cochez la case
  • Data Encryption Algorithms : choisissez les algorithmes AES-256-GCM et AES-256-CBC
  • Fallback Data Encryption Algorithm : AES-256-GCM (256 bit key, 128 bit block)
  • Auth digest algorithm : SHA512 (512-bit)
  • Hardware Crypto : No Hardware Crypto Acceleration
  • Certificate Depth : One (Client+Server)
  • Strict User-CN Matching : cochez la case

La suite des paramètres :

  • IPv4 Tunnel Network : le sous-réseau utilisé pour établir la connexion, dans cet exemple 10.168.13.0/24
  • Redirect IPv4 Gateway : cochez la case
  • Allow Compression : Refuse any non-stub compression (Most secure)
  • Type-of-Service : cochez la case

La suite des paramètres :

  • Dynamic IP : cochez la case
  • Topology : Subnet – One IP address per client in a common subnet
  • Inactive : 300
  • Ping method : keepalive – use keepalive helper to define ping configuration
  • Interval : 10
  • Timeout : 60
  • DNS Server enable : cochez la case
  • DNS Server 1 : 208.67.222.222
  • DNS Server 2 : 208.67.220.220
  • DNS Server 3 : 1.1.1.1
  • DNS Server 4 : 9.9.9.9
  • Block Outside DNS: cochez la case
  • Force DNS cache update: cochez la case

La suite et fin des paramètres :

  • Custom options : insérez les directives suivantes
port-share 192.168.190.100 443;
script-security 2;
client-connect /usr/local/sbin/ovpnup.sh;
client-disconnect /usr/local/sbin/ovpndown.sh;
push "route 192.168.190.0 255.255.255.0";
tls-verify "/usr/local/sbin/ovpnCNcheck.sh /usr/local/sbin/userlist.txt";
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
remote-cert-eku "TLS Web Client Authentication";
comp-lzo no
    • port-share : cette directive permet de partager le port 443 (HTTPS) avec le serveur Web (192.168.190.100)
    • script-security : avec l’option 2, OpenVPN permet l’utilisation d’exécutables et de scripts
    • client-connect : cette directive lance un script au démarrage de la session VPN cliente (voir le chapitre Scripts OpenVPN)
    • client-disconnect : cette directive lance un script quand la session VPN cliente se termine (voir le chapitre Scripts OpenVPN)
    • push route : cette directive permet au client d’avoir accès à la DMZ en lui poussant la bonne route
    • tls-verify : permet de lancer un script qui va vérifier au démarrage de la session le nom du certificat X.509 (voir le chapitre Scripts OpenVPN). Concrètement, le script va vérifier si le CN (Common Name) du certificat X.509 est conforme au CN enregistré dans un fichier texte (userlist.txt). Il s’agit du nom d’utilisateur AD issu du Windows Server présent à mon domicile
    • tls-cipher : précise les suites de chiffrement autorisées
    • remote-cert-eku : permet de vérifier que le certificat client est bien client
    • comp-lzo : option à « no » pour interdire la compression
  • Username as Common Name : cochez la case
  • Send/Receiver Buffer : j’ai choisi la valeur la plus élevée soit 2MB
  • Gateway creation : IPv4 only
  • Verbosity level : valeur par défaut (3)

Le fichier client correspondant pour OpenVPN Community sous Windows :

client
dev tun
remote serveur_distant.com 443 tcp4
persist-tun
persist-key
resolv-retry infinite
setenv opt block-outside-dns
comp-lzo no
verb 3
auth-nocache
auth-user-pass

# Cipher and Hash Algorithms
ncp-ciphers AES-256-GCM:AES-256-CBC
cipher AES-256-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
tls-client
tls-timeout 10
tls-crypt serveur_distant.ta.key 1
auth SHA512

# Certificates
# Installer le certificat CA (ca_serveur_distant.com.crt) pour l'utilisateur actuel dans le magasin Autorités de Certification Racines de Confiance des certificats Windows
# Installer le certificat utilisateur (prenom@serveur_distant.com.p12) pour l'utilisateur actuel avec les options par défaut dans le magasin par défaut des certificats Windows
# Changer l'empreinte numérique (thumbprint) de la directive cryptoapicert par celle du certificat utilisateur
ca ca_serveur_distant.com.crt
cryptoapicert "THUMB:XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX"
verify-X.509-name "routeur.serveur_distant.com" name

Le fichier client correspondant pour OpenVPN Community sous Linux :

client
dev tun
remote serveur_distant.com 443 tcp4
persist-tun
persist-key
resolv-retry infinite
setenv opt block-outside-dns
comp-lzo no
verb 3
auth-nocache
auth-user-pass

# Cipher and Hash Algorithms
ncp-ciphers AES-256-GCM:AES-256-CBC
cipher AES-256-GCM
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
tls-client
tls-timeout 10
auth SHA512

# Certificates
verify-X.509-name "routeur.serveur_distant.com" name
key-direction 1
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
</key>
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-crypt>

 

OpenVPN Servers – Router

Le second serveur OpenVPN permet au client VPN Untangle de se connecter au firewall pfSense. Vu le fonctionnement du client VPN sous Untangle, je ne l’utilise pas et c’est la connexion GRE qui est privilégiée. Les paramètres sont les suivants :

  • Server Mode : Remote Access (User Auth)
  • Backend for authentification : le serveur AD défini via le menu User Manager
  • Protocol : UDP on IPv4 only
  • Device mode : tun – Layer 3 Tunnel Mode
  • Interface : WAN
  • Local port : précisez un port

La suite des paramètres :

  • TLS Configuration : cochez la case
  • TLS Key : insérez une clé TLS (OpenVPN Static Key)
  • TLS Key Usage Mode : TLS Encryption and Authentification
  • TLS keydir direction : Use default direction
  • Peer Certificate Authority : certificat CA enregistré dans le magasin de certificats pfSense
  • Server Certificate : certificat enregistré dans le magasin de certificats
  • DH Parameter Length : 4096 bit
  • ECDH Curve : Use default

La suite des paramètres :

  • Data Encryption Negotiation : cochez la case
  • Data Encryption Algorithms : choisissez les algorithmes AES-256-GCM et AES-256-CBC
  • Fallback Data Encryption Algorithm : AES-256-GCM (256 bit key, 128 bit block)
  • Auth digest algorithm : SHA512 (512-bit)
  • Hardware Crypto : No Hardware Crypto Acceleration
  • Certificate Depth : One (Client+Server)

La suite des paramètres :

  • IPv4 Tunnel Network : le sous-réseau utilisé pour établir la connexion, dans cet exemple 10.168.12.0/24
  • Redirect IPv4 Gateway : cochez la case
  • Allow Compression : Refuse any non-stub compression (Most secure)
  • Type-of-Service : cochez la case

La suite des paramètres :

  • Dynamic IP : cochez la case
  • Topology : Subnet – One IP address per client in a common subnet
  • Inactive : 0 – cette valeur désactive cette option sinon le VPN se déconnecte puis se reconnecte dès que le compteur est atteint
  • Ping method : keepalive – use keepalive helper to define ping configuration
  • Interval : 10
  • Timeout : 60

La suite et fin des paramètres :

  • Custom options : insérez les directives suivantes
script-security 2;
client-connect /usr/local/sbin/ovpnup.sh;
client-disconnect /usr/local/sbin/ovpndown.sh;
push "route 192.168.190.0 255.255.255.0";
tls-verify "/usr/local/sbin/ovpnCNcheck.sh /usr/local/sbin/userlist.txt";
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
remote-cert-eku "TLS Web Client Authentication";
comp-lzo no
    • script-security : avec l’option 2, OpenVPN permet l’utilisation d’exécutables et de scripts
    • client-connect : cette directive lance un script au démarrage de la session VPN cliente (voir le chapitre Scripts OpenVPN)
    • client-disconnect : cette directive lance un script quand la session VPN cliente se termine (voir le chapitre Scripts OpenVPN)
    • push route : cette directive permet au client d’avoir accès à la DMZ en lui poussant la bonne route
    • tls-verify : permet de lancer un script qui va vérifier au démarrage de la session le nom du certificat X.509 (voir le chapitre Scripts OpenVPN). Concrètement, le script va vérifier si le CN (Common Name) du certificat X.509 est conforme au CN enregistré dans un fichier texte (userlist.txt). Il s’agit du nom d’utilisateur AD issu du Windows Server présent à mon domicile
    • tls-cipher : précise les suites de chiffrement autorisées
    • remote-cert-eku : permet de vérifier que le certificat client est bien client
    • comp-lzo : option à « no » pour interdire la compression
  • Username as Common Name : cochez la case
  • Send/Receiver Buffer : j’ai choisi la valeur la plus élevée soit 2MB
  • Gateway creation : IPv4 only
  • Verbosity level : valeur par défaut (3)

OpenVPN Clients

Créez vos clients VPN via le menu VPN/OpenVPN/Clients :

OpenVPN Clients – NordVPN

PfSense est client du fournisseur VPN NordVPN. Les paramètres sont les suivants :

  • Server Mode : Peer to Peer (SSL/TLS)
  • Protocol : UDP on IPv4 only
  • Device mode : tun – Layer 3 Tunnel Mode
  • Interface : WAN
  • Server host or address : un serveur NordVPN
  • Server port : 1194

La suite des paramètres :

  • Username : utilisez les informations d’identification de service de votre compte NordVPN
  • Password : mot de passe de l’identifiant de service
  • TLS Configuration : cochez la case
  • TLS Key : insérez la clé TLS (OpenVPN Static Key) que l’on retrouve dans le fichier OpenVPN d’un serveur NordVPN
  • TLS Key Usage Mode : TLS Authentification
  • TLS keydir direction : Use default direction
  • Peer Certificate Authority : certificat CA que l’on retrouve dans le fichier OpenVPN d’un serveur NordVPN et enregistré dans le magasin de certificats pfSense
  • Client Certificate : paramètre non utilisé, laissez le certificat par défaut

La suite des paramètres :

  • Data Encryption Negotiation : cochez la case
  • Data Encryption Algorithms : choisissez les algorithmes AES-256-GCM et AES-256-CBC
  • Fallback Data Encryption Algorithm : AES-256-CBC (256 bit key, 128 bit block)
  • Auth digest algorithm : SHA512 (512-bit)
  • Hardware Crypto : No Hardware Crypto Acceleration

La suite des paramètres :

  • Allow Compression : Refuse any non-stub compression (Most secure)
  • Topology : Subnet – One IP address per client in a common subnet
  • Don’t add/remove routes : ce paramètre est important dans la configuration que j’utilise avec un groupe de gateways composé du WAN en priorité 1 et de ce VPN en priorité 2. Si cette case n’est pas coché et malgré les priorités définies dans le groupe de gateways, tous les flux sont routés par défaut sur ce VPN
  • Inactive : 0 – cette valeur désactive cette option sinon le VPN se déconnecte puis se reconnecte dès que le compteur est atteint
  • Ping method : keepalive – use keepalive helper to define ping configuration
  • Interval : 10
  • Timeout : 60

La suite des paramètres :

  • Custom options : insérez les options suivantes que l’on retrouve dans le fichier OpenVPN d’un serveur NordVPN et qui ne sont pas déjà incluses dans le paramétrage OpenVPN client de pfSense
tls-client;
remote-random;
tun-mtu 1500;
tun-mtu-extra 32;
mssfix 1450;
persist-key;
persist-tun;
reneg-sec 0;
remote-cert-tls server
  • Exit Notify : Retry 1x
  • Send/Receiver Buffer : Default
  • Gateway creation : IPv4 only
  • Verbosity level : default

Scripts OpenVPN

Dans les configurations des serveurs OpenVPN, différentes directives permettent de lancer des scripts.

Lors de la connexion du client VPN, le script ovpnup.sh, écrit par Belgotux et que j’ai adapté, envoie à l’administrateur par mail plusieurs infos issues de variables d’environnement OpenVPN. Connectez-vous en SSH à pfSense et saisissez les commandes suivantes :

vi /usr/local/sbin/ovpnup.sh

#!/bin/sh
# Auteur : Belgotux
# Site : www.monlinux.net
# Adresse : [email protected]
# Version : 1.0
# Date : 08-03-2015
# Licence : GPLv3
# Changelog :
# Description :
# use openvpn local environment variable, see openvpn man
# In your server config file :
# client-connect /usr/local/bin/openvpn-notify.sh
# client-disconnect /usr/local/bin/openvpn-notify.sh

[email protected]

(echo "Action = $script_type
VPN conf file = $config
Common name = $common_name
X509 Common name = $X509_0_CN
X509 email Address = $X509_0_emailAddress
SHA1 fingerprint = $tls_digest_0
Public IP address = $trusted_ip
VPN IP address = $ifconfig_pool_remote_ip
Bytes received from client = $bytes_received
Bytes sent to client = $bytes_sent"
) | /usr/local/bin/mail.php -s"VPN DS : connexion $common_name" $MAILTO
exit 0

chown root:wheel /usr/local/sbin/ovpnup.sh
chmod 755 /usr/local/sbin/ovpnup.sh

Lors de la déconnexion du client VPN, le script ovpndown.sh, écrit par Belgotux et adapté par mes soins, envoie à l’administrateur par mail plusieurs infos issues de variables d’environnement OpenVPN. Connectez-vous en SSH à pfSense et saisissez les commandes suivantes :

vi /usr/local/sbin/ovpndown.sh

#!/bin/sh
# Auteur : Belgotux
# Site : www.monlinux.net
# Adresse : [email protected]
# Version : 1.0
# Date : 08-03-2015
# Licence : GPLv3
# Changelog :
# Description :
# use openvpn local environment variable, see openvpn man
# In your server config file :
# client-connect /usr/local/bin/openvpn-notify.sh
# client-disconnect /usr/local/bin/openvpn-notify.sh

[email protected]

(echo "Action = $script_type
VPN conf file = $config
Common name = $common_name
X509 Common name = $X509_0_CN
X509 email Address = $X509_0_emailAddress
SHA1 fingerprint = $tls_digest_0
Public IP address = $trusted_ip
VPN IP address = $ifconfig_pool_remote_ip
Bytes received from client = $bytes_received
Bytes sent to client = $bytes_sent"
) | /usr/local/bin/mail.php -s"VPN DS : deconnexion $common_name" $MAILTO
exit 0

chown root:wheel /usr/local/sbin/ovpndown.sh
chmod 755 /usr/local/sbin/ovpndown.sh

Lors de la connexion, la directive tls-verify lance le script ovpnCNcheck.sh , écrit par Robert Penz, qui va vérifier au démarrage si le CN (Common Name) du certificat X.509 est conforme au CN enregistré dans le fichier texte userlist.txt. On ajoutera un CN par ligne dans ce fichier texte et il s’agit du nom d’utilisateur AD issu du Windows Server présent à mon domicile. Connectez-vous en SSH à pfSense et saisissez les commandes suivantes :

vi /usr/local/sbin/userlist.txt
chown root:wheel /usr/local/sbin/userlist.txt
chmod 400 /usr/local/sbin/userlist.txt

vi /usr/local/sbin/ovpnCNcheck.sh

#!/bin/sh
# ovpnCNcheck -- an OpenVPN tls-verify script
# """""""""""""""""""""""""""""""""""""""""""
#
# This script checks if the peer is in the allowed
# user list by checking the CN (common name) of the
# X509 certificate against a provided text file.
#
# For example in OpenVPN, you could use the directive
# (as one line):
#
# tls-verify "/usr/local/sbin/ovpnCNcheck.py
# /etc/openvpn/userlist.txt"
#
# This would cause the connection to be dropped unless
# the client common name is within the userlist.txt.
#
# Special care has been taken to ensure that this script
# also works on openwrt systems where only busybox is
# available
#
# Written by Robert Penz <[email protected]> under the GPL 2
# Parts are copied from the verify-cn sample OpenVPN
# tls-verify script.

[ $# -eq 3 ] || { echo usage: ovpnCNcheck.sh userfile certificate_depth X509_NAME_oneline ; exit 255 ; }

# $1 -> cn we are looking for
# $2 -> certificate_depth
# $3 -> X509_NAME_oneline

if [ $2 -eq 0 ] ; then
    /usr/bin/grep -q "`expr match "$3" ".*CN=\([^,]*\)"`" "$1" && exit 0
    exit 1
fi
exit 0

chown root:wheel /usr/local/sbin/ovpnCNcheck.sh
chmod 755 /usr/local/sbin/ovpnCNcheck.sh

 

Conclusion

Voilà, c’est fini !

Si vous êtes arrivé au bout de cet article, bravo 😊

Le prochain article traitera des NAS, avant de revenir dans d’autres articles sur les autres VM du serveur VMware ESXi.

A bientôt pour de nouvelles aventures !

 

1 Commentaire

  1. loic
    loic sur 22 Déc 2022 à 19:41

    Bonjour,

    J’ai beaucoup cherché la même solution et aussi étonnant que ca puisse l’être j’ai contacté le support pfsense, pour savoir pourquoi ils bloquaient a 10giga. Ils m’ont répondu qu’il n’y avait pas de blocage mais qu’il fallait certainement utiliser la fonctionner SR-IOV de la carte réseau WAN de pfsense pour atteindre les débits maximums.
    Avez-vous pu tester ?

    Réponse

Poster le commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *