1. Préparation des interfaces membres du pont-réseau

2. Configuration du pont-réseau

• Member Interfaces : les interfaces membres du pont-réseau. Dans notre cas, LAN et WIFI
• Description : une description facultative
• Advanced Options : suivant votre configuration, il peut être pertinent d'activer le protocole Spanning Tree (RSTP/STP). Pour un pont entre un réseau filaire et sans-fil, cela n'est pas forcément nécessaire. Dans notre cas, nous ne modifions pas les options avancées.

3. Configuration du filtrage (subtilité à connaître)

• le paramètre net.link.bridge.pfil_member : active le filtrage sur l'interface de chaque membre du pont-réseau lorsqu'il est positionné à 1
• le paramètre net.link.bridge.pfil_bridge : active le filtrage sur l'interface du pont-réseau lui-même lorsqu'il est positionné à 1

4. Les limites

Portail captif

Haute-disponibilité

Multi-WAN

Proxy transparent

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : interfaces réseaux pfSensepfSense

Principe de fonctionnement

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

• Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
• Method : 3 méthodes sont possibles :

1. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
2. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
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

• Key length : la longueur de la clé de chiffrement du certificat. 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
• Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
• 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)
• Autres champs : l'ensemble des champs suivants sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Ils peuvent être laissés vides ou complétés.

Création d'un certificat serveur

• Method : 4 méthodes sont possibles :

1. Create an internal Certificate : permet de créer une nouveau certificat
2. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
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.
4. Sign a Certificate Signing Request : permet de signer un fichier de requête

• 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. 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 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)
• Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
• Autres champs : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Ils peuvent être laissés vides ou complétés.
• 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

Création d'un certificat client

Configuration du serveur OpenVPN

• Server Mode : choisir "Peer to Peer (SSL/TLS)"
• TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Nous conseillons de la cocher. La clé TLS sera générée automatiquement. Il restera à la copier côté client.
• Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya")
• Server Certificate : choisir le certificat serveur créé précédemment ("Certificat serveur OpenVPN Provya (Server: Yes, CA: CA Provya)")
• DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Export des certificats

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

• 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 : nous choisissons "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.

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

• 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 OpenVPN Provya")
• 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)

Configuration du client OpenVPN

• Server Mode : choisir "Peer to Peer (SSL/TLS)"
• TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Décocher la case "Automatically generate a TLS Key", et copier dans le champ "TLS Key" la clé TLS qui a été généré côte serveur OpenVPN.
• 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 OpenVPN Provya")
• DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Révocation de certificat

• 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 signé ou va signer cette CRL
• Lifetime : la durée de vie de la CRL (10 ans par défaut)
• Serial : le numéro de série de la CRL (0 par défaut pour la première)

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : certificatsopenVPNpfSenseVPNX.509

• interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1 (pour des interfaces Realtek), igb0, igb1 (pour des interfaces Intel Gbps), etc.
• interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
• interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.

Interfaces physiques

Interfaces virtuelles

Interfaces logiques

Groupe d'interfaces

1. Règles définies en Floating
2. Règles définies sur les groupes d'interfaces
3. Règles définies sur les interfaces logiques

Cas particulier : OpenVPN

Cas d'application

1. les interfaces logiques
2. les groupes de gateway
3. les adresses VIP
4. l'interface localhost
5. toutes les interfaces logiques existantes (choix "any")

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : interfaces réseaux pfSensepfSense

Généralités sur la priorisation de trafic

• Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
• Rules : "règle d'affectation" définissant la queue par laquelle un paquet va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.

Cas d'application

• qVoIP : ce sera la queue réservée à la téléphonie
• qACK : ce sera la queue réservée aux paquets ACK
• qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic

Configuration des queues

• Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
• Scheduler Type : choisir "CBQ"
• Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
• Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
• TBR Size : laisser vide

• Enable/Disable : cocher la case pour activer la file d'attente
• Queue Name : le nom de la file d'attente. Ici, ce sera "qVoIP"
• Priority : on choisit "7"
• Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
• Scheduler options : laisser vide
• Description : une description optionnelle
• Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1000 Kbps"
• Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

• Enable/Disable : cocher la case pour activer la file d'attente
• Queue Name : le nom de la file d'attente. Ici, ce sera "qACK"
• Priority : on choisit "6"
• Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
• Scheduler options : laisser vide
• Description : une description optionnelle
• Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "300Kbps"
• Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

• Enable/Disable : cocher la case pour activer la file d'attente
• Queue Name : le nom de la file d'attente. Ici, ce sera "qDefaut"
• Priority : on choisit "2"
• Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
• Scheduler options : cocher la case "Default Queue"
• Description : une description optionnelle
• Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1400Kbps"
• Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

1. qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
2. qACK : pour le trafic ACK (acquittement TCP)
3. qDefaut : pour le reste du trafic

• Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface LAN
• Scheduler Type : choisir "CBQ"
• Bandwidth : indiquer le débit max en download diminué de 10% (soit 2700Kbps)
• Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
• TBR Size : laisser vide

Configuration des rules

1. Règles définies en Floating
2. Règles définies sur les groupes d'interfaces
3. Règles définies sur les interfaces logiques

1. Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
2. Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
3. Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"

• Action : nous choisissons "Match"
• Interface : nous choisissons l'interface "WAN"
• Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
• Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
• Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

• Action : nous choisissons "Match"
• Interface : nous choisissons l'interface "WAN"
• Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
• Protocol : nous choisissons "UDP"
• Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

• Action : nous choisissons "Match"
• Interface : nous choisissons les interfaces "WAN" et LAN
• Protocol : nous choisissons "TCP"

Remise à zéro de la table d'état

Analyse et Debug

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : CBQpfSensepriorisation de traficQoS

1. Procédure de mise à niveau pour un pfSense seul

1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
2. Mise à jour du serveur pfSense
3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure

Sauvegarde de la configuration

Mise à jour du serveur pfSense

Sauvegarde de la configuration après la mise à jour

2. Procédure de mise à niveau d'un cluster de pfSense

1. Faire une sauvegarde du pfSense secondaire
2. Lancer la mise à jour du pfSense secondaire
3. Une fois la mise à jour du pfSense secondaire complète, faire une sauvegarde du pfSense primaire
4. Désactiver CARP sur le pfSense primaire => les adresses VIP vont basculer sur le pfSense secondaire
5. Lancer la mise à jour du pfSense primaire

Sauvegarde de la configuration du pfSense secondaire

Mise à jour du serveur pfSense secondaire

Sauvegarde de la configuration du pfSense primaire

Désactivation CARP du pfSense primaire

Mise à jour du serveur pfSense primaire

3. Vérifier et corriger la mise à jour des packages

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : mise à jour pfSensepfSensepfSense redondantupgrade

Principe de fonctionnement

Configuration du VPN natté

• Interface : l'interface de notre tunnel VPN OpenVPN
• External subnet IP : le sous-réseau utilisé pour le NAT. Soit, pour le site A : 192.168.100.0
• Internal IP : le sous-réseau local que nous souhaitons translater. Dans notre cas : LAN net
• Destination : Any

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : NATopenVPNpfSenseVPN

Activer le service DHCP

Configuration du serveur DHCP

• BOOTP : cocher cette case permet de désactiver la prise en charge des requêtes BOOTP. Le protocole BOOTP est en quelque sorte l'ancêtre du protocole DHCP.

• Deny unknown clients : cette option permet de filtrer les requêtes DHCP.

• Ignore denied clients : cocher cette case permet d'ignorer les requêtes DHCP des clients interdits plutôt que de leur renvoyer une réponse explicite de refus. Cette option n'est pas compatible avec une configuration de pfSense en haute-disponibilité.

• Ignore client identifiers : permet d'ignorer l'UID du client. Cette option peut être intéressante si l'on souhaite qu'un ordinateur disposant d'un dual-boot conserve la même adresse IP lorsqu'il bascule d'un système d'exploitation à l'autre. Cependant, activer cette option revient à ne pas respecter les spécification officielles du fonctionnement du protocole DHCP.

• Subnet : cette ligne rappelle l'adresse du réseau.

• Subnet mask : cette ligne rappelle le masque de sous-réseau.

• Available range : cette ligne donne la plage maximale sur laquelle des adresses IP peuvent être attribuées. Cette information est bien pratique pour les réseaux n'étant pas en /24.

• Range : permet de définir la plage d'adresses IP qui sera utilisée.

• WINS servers : permet de définir jusqu'à 2 serveurs WINS (Windows Internet Name Service) qui seront passés aux clients DHCP.

• DNS servers : ce champ peut être renseigné ou resté vide. Si l'on souhaite passer au client la même configuration DNS que celle configurée dans pfSense, alors il faut laisser ces champs vides. En revanche, si l'on souhaite passer au client d'autres serveurs DNS que ceux configurés dans pfSense, ou si l'on souhaite que ce soit pfSense qui agisse comme serveur DNS, il faut renseigner les adresse IP correspondantes ici.

• Gateway : si pfSense est la passerelle pour ce réseau, ce champ peut être laissé vide. Dans le cas contraire, nous indiquons ici l'adresse IP de la passerelle.

• Domain name : permet d'indiquer aux clients le nom de domaine correspondant au réseau et donc qu'ils devront utiliser pour former leur FQDN. Si rien n'est indiqué, c'est le nom de domaine renseigné dans la configuration gloable de pfSense qui sera passé aux clients.

• Domain search list : cette information est utile dans le cas où l'on dispose de plusieurs domaines.

• Default lease time et Maximum lease time : ces deux options permettent de contrôler la durée des baux DHCP.

• Failover peer IP : si vous possédez deux serveurs pfSense configurés en failover, renseignez ici l'adresse IP physique (pas l'adresse virtuelle) du second serveur pfSense. Autrement, laissez ce champ vide.

• Static ARP : cette option est l'exact opposé de "Deny unknow clients" : elle permet de lister les machines capables de communiquer avec pfSense sur le réseau. Ainsi, tous les terminaux n'étant pas référencés (c'est-à-dire dont l'adresse MAC est connue et référencée dans pfSense) ne pourront pas communiquer avec pfSense. Il faut faire très attention lorsque l'on manipule cette option ! De plus, lorsqu'elle est cochée, cette option reste active même si le service DHCP est arrêté.

• Time format change : par défaut, les durées de baux DHCP sont affichées au format UTC. En cochant cette option, elles sont formatées au fuseau horaire local. C'est une option d'affichage purement esthétique.

• Statistics graphs : cocher cette option permet d'activer les graphiques RRD. Cette option est désactivée par défaut.

• Dynamic DNS : cette option permet de définir un serveur DNS dynamique (à saisir dans le champ correspondant). Dans le cas où pfSense est configuré en mode "DNS forwarder", cette option ne devrait pas être cochée, et le DNS forwarder devrait être configuré en conséquence.

• MAC Address Control : cette option permet de filtrer les accès au serveur DHCP par adresses MAC.

• NTP servers : permet de définir un à deux serveurs NTP.

• TFTP server : permet de saisir l'adresse IP ou le nom d'hôte d'un serveur TFTP. Cette option est principalement utilisée pour l'auto-provisioning pour la téléphonie sur IP. Elle correspond à l'option DHCP 66.

• LDAP : permet d'envoyer l'URI d'un serveur LDAP aux clients en faisant la demande. Cela correspond à l'option DHCP 95. Le format saisi doit être celui d'une URI LDAP tel que ldap://ldap.example.com/dc=example,dc=com.

• Network booting : pour activer cette fonctionnalité, il faut cocher la case correspondante (Enables network booting), saisir l'adresse IP du serveur ainsi que le nom du fichier d'image disque bootable. L'ensemble de ces champs doit être complété pour que cette option fonctionne correctement.

• Additional BOOTP/DHCP Options : permet de pousser n'importe quelle option DHCP (dont nous détaillons le paramétrage au paragraphe suivant).

Les options avancées du serveurs DHCP

Exemple de configuration avancée : serveur DHCP pour ordinateurs et téléphones IP

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : auto-provisioningDHCPpfSense

VPN site-à-site

IPsec vs OpenVPN

OpenVPN Client & Serveur

Configurer OpenVPN côté "serveur"

• 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.

• Protocol : nous choisissons "UDP on IPv4 only".

• Device Mode : nous choisissons tun

• 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. Dans notre cas, nous saisissons "VPN Provya".
• 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 si l'une des deux parties ne supporte pas le protocole NCP. N'importe quel algorithme travaillant avec une clé d'au moins 128 bits sera bon. 256 bits sera encore mieux. CAST/DES/RC2 sont moins sécurisés, et donc à bannir. Notre choix se porte sur AES 256 bits CBC
• Enable NCP : cocher la case permet d'activer le protocole NCP pour que le client et le serveur négocie le protocole de chiffrement le plus approprié. Nous laissons la case cochée.
• NCP Algorithms : Les algortithmes de chiffrement que nous souhaitons supporter côté serveur.
• Auth digest algorithm : nous laissons la valeur par défaut SHA256.
• Hardware Crypto : précise si le serveur dispose d'un support cryptographique.
• IPv4 Tunnel Network : réseau utilisé pour le tunnel VPN. N'importe quel réseau privé 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). Dans notre cas, nous utilisons le sous-réseau 10.0.8.0/30.
• IPv4 Remote network(s) : désigne le ou les réseaux distants accessibles par le serveur. Il convient d'utiliser la notation CIDR (ex : 192.168.1.0/24). Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par une virgule. Dans notre cas, nous indiquons le réseau utilisé sur le site B, soit 192.168.2.0/24.
• 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/LZ4 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.
• Custom options : 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

• Interface : WAN
• Protocol : UDP
• Source : si l'adresse IP publique du site distant n'est pas connue on laisse any, sinon on la renseigne 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 dans notre cas.

Configurer OpenVPN côté "client"

• Server Mode : ici, nous avons deux possibilités :

1. Peer to peer (SSL/TLS)
2. Peer to peer (Shared Key)

• Protocol : choisir le même protocole que celui choisi côté serveur (soit UDP on IPv4 only)
• Device mode : choisir tun
• Interface : l'interface via laquelle le client OpenVPN va joindre le serveur. Dans notre cas, ce sera WAN
• Local port : si ce champ est laissé vide, un port aléatoire sera choisi
• Server host or address : l'adresse IP publique du site distant, c'est-à-dire l'adresse IP publique du site A dans notre cas (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 : idem ci-dessus
• Description : le nom que vous souhaitez donner à votre tunnel VPN (ici, VPN Provya)
• Auto generate / Shared Key : décochez la case "Auto generate" et copier/coller la clé générée côté OpenVPN serveur
• Encryption algorithm : renseigner le même algorithme que celui saisi côté OpenVPN serveur (AES-256-CBC). Cet algorithme sera utilisé uniquement si NCP n'est pas activé ou supporté
• NCP Algorithms : les mêmes que ceux sélectionnés côté serveur
• Auth digest algorithm : on laisse la valeur par défaut, soit SHA256
• Hardware Crypto : précise si le serveur dispose d'un support cryptographique
• IPv4 Tunnel Network : même réseau que celui renseigné côté OpenVPN serveur, soit 10.0.8.0/30
• IPv4 Remote Network(s) : on renseigne le réseau du site distant. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par une virgule. Dans notre cas, cela donne : 192.168.1.0/24
• 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
• Advanced : permet de passer des paramètres avancés à OpenVPN. Nous ne rentrerons pas dans le détail ici.

Debug

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : openVPNpfSenseVPN

Recommandations générales

1. La configuration se fait sur l'interface d'arrivée du paquet

2. Il faut être le plus précis possible

3. Toujours préciser la source pour les interface internes

4. Préciser la destination lorsqu'elle est connue

5. Utiliser des alias

6. Ventiler et regrouper ses règles

7. Commenter, commenter, commenter

• le succinct descriptif fonctionnel à l'origine de la création de la règle ;
• la date d'implémentation de la règle (cette information est gérée automatiquement par pfSense) ;
• la référence de la demande (n° de ticket ou code projet) ;
• le nom ou le matricule de la personne qui a créé ou modifié la règle (cette information est gérée automatiquement par pfSense, à condition que tout le monde n'utilise pas le compte "admin" par défaut...)

Ordre des règles de filtrage

1/5. Règles d'autorisation des flux à destination du pare-feu (administration ; services hébergés sur pfSense)

2/5. Règles d'autorisation des flux émis par le pare-feu (pfSense n'est pas concerné)

3/5. Règles de protection du pare-feu (règles spécifiques)

4/5. Règles d'autorisation des flux métiers

• une organisation par entité métier (regroupement des règles du service comptabilité, des ressources humaines, du service achat, etc.) ;
• une organisation par fonctions & services offerts : accès aux bases de données, accès à l'intranet, accès au serveur de messagerie, accès à Internet, etc.

5/5. Règle d'interdiction finale (inutile pour pfSense)

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : pfSensesécurité

CBQ - Class Based Queueing

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

PRIQ - Priority Queueing

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

H-FSC

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Qlimit

(BP / 8) / MTU = nb paquets/sec.

(10.000.000 / 8) / 1500 = 833 pq/sec

realtime

upperlimit

linkshare

1. realtime : bande-passante minimale garantie à une queue
2. linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
3. upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
4. bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

NLSC

1. m1 : bande passante initiale attribuée à la queue
2. m2 : bande passante définitive attribuée à la queue
3. d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

Options

1. Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
2. Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
3. Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
4. Random Early Detection In and Out (RIO) : idem RED.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)

Pour aller plus loin

Retrouvez nos services et firewall pour pfSense

store.provya.fr

Tags de l'article : CBQHFSCpfSensepriorisation de traficPRIQQoS