Provya

Expertise pfSense

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN

icon 18/04/2019

English version: [pfSense] Secure remote access for your home-office workers with OpenVPN.

Il est de plus en plus souvent nécessaire de pouvoir offrir des solutions d'accès distants à ses utilisateurs nomades.
Ces accès se doivent d'être sécurisés et fiables.

Bonne nouvelle, pfSense et OpenVPN forment la solution idéale pour ce besoin ! :-)



OpenVPN = la solution idéale pour les utilisateurs nomades


OpenVPN est une solution facile à mettre en œuvre et efficace pour les utilisateurs nomades.

OpenVPN propose des clients pour tout type de plate-forme (Windows, MAC, Android, iOS) :

Plateformes supportées par OpenVPN


De plus, pfSense propose un mode d'export des configurations des clients pour encore plus de facilité.


À noter :
Cet article ne traite pas de la configuration d'OpenVPN serveur en mode site-à-site (clé partagée ou X.509).
Cet article traite uniquement de l'accès nomade. Nous ne rentrerons pas dans les détails de configuration d'OpenVPN côté serveur pfSense. Nous nous concentrons sur les spécificités de l'accès nomade.

Il existe plusieurs articles dédiés à la configuration d'OpenVPN en environnement pfSense : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement


Le but est d'offrir une solution de VPN pour les utilisateurs nomades leur permettant de disposer d'un accès sécurisé au réseau local de l'entreprise.
Ces utilisateurs peuvent utiliser un ordinateur ou un smartphone pour se connecter.
Dans tous les cas, ils utiliseront un client OpenVPN.

Dans notre exemple de mise en application, nous partirons sur l'infrastructure suivante :

- le sous-réseau LAN est 172.31.54.0/24
- le sous-réseau OpenVPN est 172.31.55.0/24

accès nomade OpenVPN avec pfSense


Pour l'identification et l'authentification des utilisateurs, nous utiliserons un certificat couplé à un login et un mot de passe.
Le certificat sera commun pour tous les utilisateurs. Le login et le mot de passe seront privatifs.


Passons maintenant à la configuration !



Configuration du serveur OpenVPN


Côté serveur OpenVPN, nous devons créer les éléments suivants :
  1. une autorité de certification, sauf si nous en disposons déjà d'une
  2. un certificat serveur
  3. un certificat client
  4. les accès utilisateurs (login et mot de passe)
  5. le serveur OpenVPN en tant que tel
  6. les règles de firewall et de NAT idoines
  7. la configuration des clients nomades



1. Création d'une autorité de certification


Cette étape n'est nécessaire que si nous ne disposons pas déjà d'une autorité de certification existante.
Si nous en avons déjà créé une lors de la mise en place d'une connexion VPN site-à-site ([pfSense] La gestion des certificats pour les connexions OpenVPN), nous pouvons réutiliser celle-ci plutôt que d'en recréer une nouvelle.

Autrement, nous nous rendons dans le menu System > Cert Manager :

menu System > Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  2. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, nous créons une nouvelle autorité de certification (Create an internal Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (3650 jours, soit 10 ans)
  • Country Code : le code ISO du pays. Dans notre cas : FR
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit être unique.

Exemple de résultat obtenu :

Exemple de configuration d'un C.A. pfSense - Provya


Notre autorité de certification est créée.

Nous devons exporter la clé publique du certificat. Pour cela, dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA" de l'autorité de certification que nous avons créée précédemment :

Exporter un CA pfSense - Provya




2. Création d'un certificat serveur


Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur l'icône "+ Add" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  2. Create an internal Certificate : permet de créer une nouveau certificat
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
Dans notre cas, nous choisissons "Server Certificate".
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (3650 jours, soit 10 ans)
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Par défaut, l'ensemble des champs sont pré-complétés avec les informations issues du CA. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit rester unique

Exemple de résultat obtenu :

Exemple de création d'un certificat pfSense - Provya


Notre certificat pour le serveur OpenVPN est créé.



3. Création d'un certificat client


Il nous reste à créer un certificat pour nos clients nomades.
Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :

Création d'un certificat pour pfSense - Provya


Notre certificat pour les clients OpenVPN est créé.

Nous exportons la clé privée et la clé publique (qui nous sera nécessaire pour les clients nomades).
Pour cela, nous cliquons successivement sur les icônes "Export certificat" et "Export key" du certificat client que nous avons créé précédemment :

Export du certificat et de la clef - pfSense - Provya




4. Création des utilisateurs


La création et la gestion des utilisateurs se passent dans le menu System > User Manager :

menu System > User Manager - pfSense - Provya


Nous commençons par créer un groupe : se rendre sur l'onglet "Groups", puis cliquer sur l'icône "+ Add" se trouvant en bas à droite de la liste des groupes.

Nous renseignons les champs comme suit :
  • Group name : le nom du nouveau groupe. Ce nom ne doit pas contenir d'espace. Dans notre cas, nous indiquons "OpenVPN-user"
  • Scope : la portée du groupe. Nous laissons la valeur par défaut "Local"
  • Description : une description facultative
  • Group Memberships la liste des membres du groupe. Dans notre cas, nous la laissons vide pour le moment

Exemple de résultat obtenu :

Création d'un groupe pfSense - Provya


Si nous souhaitons assigner des privilèges aux membres du groupe, il faut l'éditer en cliquant sur l'icône en forme de crayon se trouvant à sa droite.
Dans notre cas, les utilisateurs n'ayant pas besoin de se connecter à pfSense, nous ne leur attribuons aucun droit particulier.


Nous nous rendons ensuite dans l'onglet "Users" pour créer notre premier utilisateur en remplissant les champs comme suit :
  • Disabled : permet de désactiver un utilisateur sans le supprimer
  • Username : le nom d'utilisateur (sans espace ni caractères spéciaux)
  • Password : le mot de passe
  • Full name : Le nom de l'utilisateur associé à ce compte
  • Expiration date : La date d'expiration du compte. Elle doit être saisie au format américain, c'est-à-dire mm/jj/aaaa (mois/jour/année). Si ce champ est laissé vide, le compte n'expirera jamais.
  • Group Memberships : c'est ici que nous définissons le groupe auquel nous rattachons l'utilisateur. Dans notre cas, nous choisirons "OpenVPN-user"
  • Certificate : si l'on souhaite créer par la même occasion un certificat pour l'utilisateur (ce que nous ne ferons pas)
  • Authorized keys : si l'on souhaite définir la clé autorisée pour la connexion de l'utilisateur (nous ne cochons pas cette case)
  • IPsec Pre-Shared Key : utiliser pour les connexions en VPN IPsec ; ce qui n'est pas notre cas (nous laissons donc ce champ vide)

Exemple de résultat obtenu :

Création d'un utilisateur pfSense - Provya




5. Création du serveur OpenVPN


Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Remote Access (SSL/TLS + User Auth)"
  • TLS Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya (ca-provya)")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat Serveur (certif-serveur-provya)")
  • DH Parameters Length : nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Configuration du serveur OpenVPN




6. Configuration du firewall et du NAT


Se rendre dans Firewall > Rules :

menu Firewall > Rules


Sur l'interface sur laquelle le serveur OpenVPN est en écoute ("WAN", très sûrement), créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

  • Interface : WAN
  • Protocol : UDP
  • Source : choisir "any"
  • Destination : WAN address
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN (1194 dans notre exemple)

Exemple de résultat obtenu :

Exemple d'une règle de filtrage


Si nous avons besoin de faire une redirection d'adresse (cas où le port public utilisé serait différent du port configuré pour le serveur OpenVPN), nous créons une règle de NAT dans Firewall > NAT.
Les éléments à renseigner sont :

  • Interface : WAN
  • Protocol : UDP
  • Src. addr & Src. port : choisir "any"
  • Dest. addr : l'adresse IP WAN
  • Dest. ports : le port d'écoute du serveur OpenVPN
  • NAT IP : l'adresse IP du pfSense sur l'interface WAN
  • NAT Ports : le porte d'écoute du serveur OpenVPN (1194, dans notre exemple)



7. Configuration des clients nomades


Il ne reste plus qu'à mettre en route OpenVPN client sur les postes nomades.

Les clients Windows, Mac, Android ou iOS sont téléchargeables directement sur le site d'OpenVPN ou sur les stores associés : iPhone et Android.

3 fichiers nous serons nécessaires :
  • la clé publique et la clé privée du certificat client créé précédemment
  • un fichier de configuration d'OpenVPN à créer manuellement

La documentation d'OpenVPN fournit un fichier de configuration d'exemple. Il est reproduit ci-dessous.

Les éléments à configurer sont :
  • remote my-server 1194 => à remplacer par l'adresse IP publique (ou le nom de domaine associé) et par le bon port d'écoute
  • ca ca-provya.crt => la clé publique de l'autorité de certification
  • cert provya-client.crt => la clé publique du certificat client
  • key provya-client.key => la clé privée du certificat client

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Windows adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote my-server 1194


# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca-provya.crt
cert provya-client.crt
key provya-client.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
;comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

# Autentification par login et mot de passe
auth-user-pass


Le fichier de configuration d'OpenVPN et les clés publiques & privées sont à stocker dans un même répertoire.


La configuration est terminée.

pfSense propose également un outil d'export (ce qui évite de devoir créer un fichier .ovpn manuellement). Cet outil est accessible en installant le package "OpenVPN Client Export Utility".



Analyse et Debug


Pour voir si un client est connecté, ça se passe dans le menu "Status" > "OpenVPN".

Les logs de connexion sont eux accessibles dans "Status" > "System logs", puis onglet "OpenVPN".



Pour aller plus loin


[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] La gestion des certificats pour les connexions OpenVPN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.


Retrouvez nos services et firewall pour pfSense & OPNsense



Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Soho pour pfSense et OPNsense         Firewall pro-Maxi pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

6 commentaires

ptiseb60 - 20/11/2017 à 14:12:10

Bonjour,

J'ai un soucis apres mise en place d'un openvpn sur pfsense, mes client sous mac se connectent via tunnelblick en utilisant le fichier de configration .ovpn généré par pfsense.
Ils arrivent bien a se connecter et a se pinger sur la plage ip virtuel, cependant ils n'arrivent pas a communiquer avec mon LAN.

Auriez vous une idée de la raison?

Merci d'avance.

@répondre #lien

Guillaume - 21/11/2017 à 15:15:56

@ptiseb60 :
Bonjour,

Peut-être un problème d'autorisation de flux ?
Avez-vous créé une interface logique et autorisé les flux réseau entre vos clients OpenVPN et votre LAN ?

Ça peut également être un problème de règle d'Outbound NAT manquante si vous n'avez pas laissé le mode automatique par défaut.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Mohamed ben amor - 26/08/2022 à 11:54:44

Bonjour,
je veux autoriser quelques adresses mac de confiance et bloquer tous les autres adresses qui se connectent a mon réseau local via le réseau internet

Auriez vous une solution sur pfSense?

Merci d'avance.

@répondre #lien

Guillaume - 30/08/2022 à 08:06:40

@Mohamed ben amor :
Bonjour,

Il y a plusieurs manières de faire, en fonction du niveau de sécurité que vous souhaitez implémenter.

Une solution simple est d'indiquer les adresses MAC autorisées à obtenir une adresse IP sur votre serveur DHCP (menu Services > DHCP Server > champ MAC Address Control). Les autres équipements n'obtiendront pas d'adresse IP.
Pour une solution plus complète, il vous faut regarder du côté d'un NAC (Network Access Control) du type PacketFence.

Cordialement,

Guillaume
--
Provya

@répondre #lien

Tadji - 04/12/2022 à 08:43:21

Bonjour,
Merci pour le travaille colossale fourni sur site, c'est d'une aide inestimable.
J'ai un cas d'utilisation que j'aimerai avoir un regard d'expert.

j'ai 3 sites avec les config suivantes :

A) Site A Principal: 1 Pfsense avec un réseau LAN (192.168.10.0/24)
* 1 serveur d'application et plus autre pc et imprimante

B-C) site B et C sont identique : pas de Pfsense (défaut de moyens)
* 1 PC ou plus sous serveur linux "Ubuntu 20"
* 1 imprimante type TMU en réseau (imprimante thermiques type caisse)
* Boxe type "Liveboxe Orange"
* Réseau LAN (192.168.1.0/24)

Ma question est :
quel type de VPN dois-je monter pour permettre aux imprimantes d'être joignable depuis le site principal et plus exactement depuis le serveur d'application ?

ps : je suppose que pour les PC(serveur Ubuntu) je dois monter des collaborateurs nomades avec OpenVPN !

Dans l'attente de vous lire

@répondre #lien

Guillaume - 21/12/2022 à 13:24:19

@Tadji :
Bonjour,

Il vous faudra dans tous les cas monter un tunnel VPN entre vos sites. Il vous faudra donc un équipement pour réaliser la terminaison VPN sur le site B et sur le site C.
Soit votre imprimante embarque un client OpenVPN, soit vous pouvez utiliser votre serveur Ubuntu pour qu'il fasse office de serveur OpenVPN / IPsec permettant de donner l'accès à votre imprimante.

La documentation en ligne, sur le site ubuntu-fr, vous apporte toutes les précisions nécessaires pour la configuration d'OpenVPN et de l'IP forwarding : https://doc.ubuntu-fr.org/openvpn

Cordialement,

Guillaume
--
Provya

@répondre #lien

icon Flux RSS des commentaires de cet article