Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

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

icon 18/04/2016 - 2 commentaires

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 :



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 :



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 :





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 :



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 :



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 :





4. Création des utilisateurs

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

alt


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 :

alt


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 :

alt




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 :





6. Configuration du firewall et du NAT

Se rendre dans 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 :



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


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

icon Tags de l'article :

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 30/12/2014 - 2 commentaires

Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).

Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.

À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation de certificat. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement

Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.

Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.

Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.



Création d'une autorité de certification - CA

Actions à effectuer coté serveur OpenVPN

Pour commencer, nous nous rendons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône en forme de "+" 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, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing 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 (10 ans)
  • Distinguished name : l'ensemble de ces 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 (il est possible d'en mettre, mais cela peut poser des problèmes...)

Exemple de résultat obtenu :



Notre autorité de certification est créée.



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 en forme de "+" 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 3 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
  3. Authority Certificate : pour créer un CA intermédiaire
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 (10 ans)
  • Distinguished name : l'ensemble de ces 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 (il est possible d'en mettre, mais cela peut poser des problèmes...) et qui doit, autant que possible, rester unique

Exemple de résultat obtenu :



Notre certificat pour le serveur OpenVPN est créé.



Création d'un certificat client

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 :



Notre certificat pour le client OpenVPN est créé.



Configuration 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 "Peer to Peer (SSL/TLS)"
  • 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 :





Export des certificats

La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.
Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.

Pour cela, nous retournons dans le menu System > Cert Manager :



Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA cert" de l'autorité de certification que nous avons créée précédemment :




Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "export cert" et "export key" du certificat client que nous avons créé précédemment :



La configuration côté serveur OpenVPN est terminée.
Maintenant, nous procédons à l'import des clés publiques/privées et à la configuration côté client OpenVPN.



Import de la clé publique du CA sur le pfSense client OpenVPN

Actions à effectuer coté client OpenVPN

Nous nous rendons dans le menu System > Cert Manager :



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

Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
  • Method : on choisit "Import an existing Certificate Authority"
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
  • Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.

Exemple de résultat obtenu :





Import de la clé publique et de la clé privée du certificat client OpenVPN

Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur l'icône en forme de "+" se trouvant en bas à droite de la liste des certificats existants.

Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Method : on choisit "Import an existing Certificate"
  • Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat Client")
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Private key data : on copie dans ce champ le contenu de la clé privée (.key)

Exemple de résultat obtenu :





Configuration du client OpenVPN

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

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • 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 importée précédemment ("CA Provya")
  • Client Certificate : choisir le certificat client importé précédemment ("Certificat Client")
  • DH Parameters Length : . Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :





Révocation de certificat

Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).

Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.

Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.

Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.

Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).

Pour ajouter une nouvelle CRL, nous cliquons sur l'icône en forme de "+" correspondant au CA qui signera cette CRL ("CA Provya"). Les champs à renseigner sont les suivants :
  • Method : deux méthodes sont possibles :
  1. Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
  2. Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
  • Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
  • Certificate Authority : le CA qui a ou va signé cette CRL
  • Lifetime : la durée de vie de la CRL (9999 jours par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut)

Exemple de résultat obtenu :



Notre CRL est créée. On peut maintenant lui ajouter les certificats à révoquer. Pour cela, cliquer sur l'icône "Edit CRL" :



Il reste à choisir le certificat à révoquer, la raison de la révocation (ce champ est purement informatif) et cliquer sur le bouton "ADD".

Enfin, dans la configuration de notre serveur OpenVPN, nous devons ajouter cette CRL (champ "Peer Certificate Revocation List").



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN


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

icon Tags de l'article :

[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN

icon 11/09/2014 - 7 commentaires

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Par exemple, si l'on souhaite connecter deux réseaux utilisant le subnet 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le subnet du réseau distant est le même que celui du réseau local.

Afin d'y remédier, on propose d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.


Principe de fonctionnement
Pour chaque subnet commun sur les sites distants, nous utiliserons un nouveau subnet disponible associé à du 1:1 NAT.

Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

Schéma réseau


Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.

Le trafic à destination du site A sera translaté en 172.16.1.0/24.
Le trafic à destination du site B sera lui translaté en 172.17.1.0/24.

Une entrée 1:1 NAT sera ajoutée pour chaque subnet pour translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 172.16.1.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 172.17.1.x.

Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 172.16.1.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 172.17.1.50.


Configuration du VPN natté
Sur le serveur pfSense du site A, nous créons une nouvelle règle 1:1 NAT (Firewall > NAT) que nous configurons comme suit :

Configuration 1:1 NAT


Dans le champ External subnet IP, nous indiquons l'adresse réseau du subnet natté soit 172.16.1.0.


Nous procédons de la même manière sur le serveur pfSense du site B ; nous créons une nouvelle règle 1:1 NAT (Firewall > NAT) que nous configurons comme suit :

Configuration 1:1 NAT


Dans le champ External subnet IP, nous indiquons l'adresse réseau du subnet natté soit 172.17.1.0.


Enfin, dans la configuration du client et du serveur OpenVPN, le champ "Remote Network" doit correspondre aux plages d'adresses IP nattées. Soit, sur le pfSense du site A, le champ "Remote Network" est renseigné à "172.17.1.0/24" et sur le site pfSense du site B, le champ "Remote Network" est renseigné à "172.16.1.0/24".

Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.

Le VPN natté est en place !



Pour aller plus loin

[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN


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

icon Tags de l'article :

[pfSense] Monter un accès OpenVPN site-à-site

icon 15/06/2014 - 8 commentaires

Nous allons voir dans cet article comment monter un VPN site-à-site entre deux environnements pfSense en nous reposant sur le logiciel OpenVPN.


VPN site-à-site
OpenVPN permet de monter un VPN site-à-site de manière très simple et efficace.

L'un des sites est configuré comme client et l'autre site comme serveur.

Pour monter notre VPN, nous utiliserons ici le système de clés partagées.
Si avez peu de liens site-à-site à monter, il est recommandé d'utiliser des clés partagées. Au dela de 5 à 6 liens site-à-site, il peut être judicieux d'utiliser la gestion de certificat (SSL/TLS - PKI) par simplicité d'administration.


IPsec vs OpenVPN
Faut-il monter son VPN site-à-site avec OpenVPN ou IPsec ? Vaste question à laquelle nous ne répondrons pas ici ! :-)

Nous préciserons simplement qu'IPsec et OpenVPN peuvent tous les deux être actifs et en service en parallèle sur un même serveur pfSense. La seule contrainte étant, évidemment, de ne pas attribuer les mêmes subnet sur vos lien OpenVPN et IPsec.


OpenVPN Client & Serveur
OpenVPN est basé sur un mode de fonctionnement client-serveur. Qu'un pfSense soit définit comme client ou comme serveur ne changera strictement rien d'un point de vue réseau. Cependant, si vous souhaitez connecter plusieurs sites distants sur un site principal, le plus logique est bien-sûr de définir le site principal comme "serveur" et les sites distants comme "clients".


Configurer OpenVPN côté "serveur"
Sur le pfSense du site "serveur", se rendre dans VPN > OpenVPN. Vous serez dirigez sur la page server par défaut :



Cliquer sur l'icône en forme de "+" pour ajouter un serveur VPN.


  • Server Mode : ici, nous avons cinq possibilités :
  1. Peer to peer (SSL/TLS) : pour monter un VPN site-à-site en utilisant une authentification par certificat.
  2. Peer to peer (Shared Key) : pour monter un VPN site-à-site en utilisant une authentification par clé partagée.
  3. Remote Access (SSL/TLS) : pour monter un accès distant pour clients nomades en utilisant une authentification par certificat.
  4. Remote Access (User Auth) : pour monter un accès distant pour clients nomades en utilisant une authentification par login/password.
  5. Remote Access (SSL/TLS + User Auth) : pour monter un accès distant pour clients nomades en utilisation une authentification par certificat et par login/password.
Nous choisissons Peer to peer (Shared Key).

  • Protocol : nous choisissons UDP.
L'utilisation du protocole TCP n'est pas adaptée à un environnement VPN, car en cas de pertes de paquets ceux-ci devront être retransmis. Ce qui n'est pas forcément souhaité. La conséquence serait un ralentissement du lien VPN à cause d'une forte ré-émission de paquets.
TCP est en revanche particulièrement intéressant si vous devez passer au travers d'une connexion particulièrement restrictive. Dans ce cas, l'utilisation du port 443 (correspondant au port HTTPS) est particulièrement judicieux (il est rare que le port 443 soit bloqué en sortie d'un réseau vers Internet). Attention toutefois, si vous choisissez le port 443, assurez-vous d'abord que le WebGUI de pfSense ne tourne pas déjà sur ce port !

  • Device Mode : nous choisissons tun
TUN travaille avec des frames IP.
TAP travaille avec des frames Ethernet.
  • Interface : l'interface sur laquelle le serveur va recevoir les connexions entrantes. Généralement WAN ou OPT1. Il est également possible de choisir "any" et dans ce cas le serveur sera en écoute sur toutes les interfaces.
  • Local port : port d'écoute du serveur OpenVPN. Par défaut, c'est le 1194. Il est à noter que chaque serveur VPN doit disposer de son propre port d'écoute. De la même manière, il est important de s'assurer qu'aucun autre service ne soit déjà en écoute sur le port choisi... y'en a qui ont essayé ils ont eu des problèmes :-)
  • Description : nom que l'on souhaite donner à ce serveur VPN. C'est ce nom qui apparaîtra dans les listes déroulantes de sélection de VPN se trouvant aux différents endroits du WebGUI pfSense.
  • Shared Key : nous conseillons de laisser coché la case "Automatically generate a shared key". La clé sera à copier/coller côté client.
  • Encryption algorithm : ce paramètre doit être le même côté client et côté serveur. N'importe quel choix sera bon. CAST/DES/RC2 sont moins sécurisés, mais plus rapides. Notre choix se porte sur AES 128 bits
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique.
  • Tunnel Network : réseau utilisé pour le tunnel VPN. N'importe quel réseau inutilisé dans l'espace d'adressage de la RFC 1918 peut être utilisé. Pour une connexion site-à-site, l'utilisation d'un /30 est suffisant (inutile d'utiliser un /24).
  • Local Network/s : désigne les réseaux locaux accessibles par le client. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Remote Network/s : utilisé uniquement pour l'accès au réseau distant (donc dans une configuration site-à-site). Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Concurrent connections : précise le nombre de connexion client possible en simultanée sur ce serveur. Dans le cas d'un VPN site-à-site, ce paramètre peut être renseigné à 1.
  • Compression : permet d'activer la compression LZO sur l'ensemble des flux transitant par ce tunnel VPN. Si les données transitant dans ce tunnel VPN sont principalement des données chiffrées (HTTPS, SSH, etc.), cocher cette option ne fera qu'ajouter un overhead inutile aux paquets.
  • Type-of-Service : cocher cette case indique de reprendre dans les paquets envoyés par OpenVPN la valeur du champ TOS des paquets encapsulés traversant le tunnel. Cette option peut être considérée comme présentant un risque potentiel de sécurité. Aussi, nous ne recommandons pas nécessairement son utilisation.
  • Duplicate Connections : cette option ne doit généralement pas être cochée, à moins que vous ne sachiez ce que vous faites.
  • Advanced : permet de passer des paramètres avancés à OpenVPN. Cela peut notamment être utile si l'on décide de faire du VPN natté (entre deux sites ayant le même plan d'adressage) ou pour pousser des routes spécifiques. Nous ne rentrerons pas dans le détail ici.




Configuration du Firewall
Il est maintenant nécessaire d'autoriser le flux VPN au niveau du firewall. Se rendre dans Firewall > Rules :



Sur l'interface sur laquelle le serveur OpenVPN est en écoute, créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

Dans notre exemple, nous travaillons sur l'interface WAN et l'adresse IP de notre pfSense sur notre WAN est 109.190.190.10, ce qui donne :

  • Interface : WAN
  • Protocol : UDP
  • Source : si l'adresse IP publique du site distant est connue et fixe, la renseigner en choisissant le type "Single host or alias"
  • Destination : type "Single host or alias", address à 109.190.190.10
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN, soit 1194

Ce qui nous donne la règle suivante :




La configuration côté serveur est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN. Pour cela, se rendre dans Firewall > Rules > OpenVPN.


Configurer OpenVPN côté "client"
Sur le pfSense du site "client", se rendre dans VPN > OpenVPN. Puis cliquer sur l'onglet "Client".

Cliquer sur l'icône en forme de "+" pour ajouter un client VPN.

  • Server Mode : ici, nous avons deux possibilités :
  1. Peer to peer (SSL/TLS)
  2. Peer to peer (Shared Key)
Nous choisissons Peer to peer (Shared Key), conformément à ce que nous avons configuré côté OpenVPN serveur.

  • Protocol : choisir le même protocole que celui choisi côté serveur (soit UDP)
  • Device mode : choisir tun
  • Interface : l'interface d'écoute du client OpenVPN. Dans notre cas, ce sera WAN
  • Local port : si ce champ est laissé vide, un port aléatoire sera choisi
  • Server host or address : le nom FQDN ou l'adresse IP publique du site distant (ici, 109.190.190.10)
  • Server port : port d'écoute du serveur OpenVPN distant (ici, 1194)
  • Proxy host or address : adresse du proxy si le pfSense client nécessite de passer par un proxy
  • Proxy port : idem ci-dessus
  • Proxy authentification extra options : idem ci-dessus
  • Server host name resolution : laissez décoché cette case
  • Description : le nom que vous souhaitez donner à votre tunnel VPN
  • Shared Key : copier/coller la clé générée côté OpenVPN serveur
  • Encryption algoithm : renseigner le même algorithme que celui saisi côté OpenVPN serveur
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique
  • Tunnel Network : même réseau que celui renseigné côté OpenVPN serveur
  • Remote Network/s : Renseigner le réseau du site distant ou n'importe quel autre réseau inutilisé si vous souhaitez faire du VPN natté par exemple. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par un point-virgule.
  • Limit ourgoing bandwidth : bande-passante maxi allouée à ce tunnel VPN. Laisser vide pour ne pas fixer de limite.
  • Compression : doit être similaire à la configuration côté OpenVPN serveur
  • Type-of-Service : cocher cette case indique de reprendre dans les paquets envoyés par OpenVPN la valeur du champ TOS des paquets encapsulés traversant le tunnel. Cette option peut être considérée comme présentant un risque potentiel de sécurité.
  • Advanced : permet de passer des paramètres avancés à OpenVPN. Nous ne rentrerons pas dans le détail ici.




La configuration côté client est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN. Pour cela, se rendre dans Firewall > Rules > OpenVPN.


Debug
Pour disposer d'informations sur vos liens OpenVPN (état, date de début de mise en service, volume entrant/sortant, etc.), se rendre dans Status > OpenVPN.

Pour les logs du firewall, se rendre dans Status > System logs > Firewall.


Pour aller plus loin
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN


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

icon Tags de l'article :