Voici comment bloquer simplement une IP bien merdique en entrée sur le pare-feu windows :
Il s'agît d'un serveur chinois qui teste tous les ports possible pour se connecter via SSH.

New-NetFirewallRule -DisplayName "Block IP 116.110.95.45" -Direction Inbound -Action Block -RemoteAddress 116.110.95.45

Nous allons réaliser un VPN OpenVPN de site-à-site en configurant des Cudy R700, placés derrière des pare-feux (PF1 et PF2).
(La représentation du tunnel est volontairement déportée sur le dessin, pour ne pas alourdir. Néanmoins le tunnel passe bien par les 2 PF !)

Nous simulerons un réseau publique (80.80.80.0/24) pour internet.

L'objectif est de pouvoir ajouter le PC CLIENT du Site 2 à l'Active Directory du serveur AD se trouvant sur le Site 1 (un challenge comme un autre !).
Le tunnel VPN devra donc permettre aux machines des réseaux locaux des 2 sites de se contacter mutuellement.

Nous allons donc configurer un serveur OpenVPN sur le Cudy1 (situé sur le Site 1), et le Cudy2 (situé sur le Site 2) jouera le rôle du client VPN, qui se connecte au serveur pour créer le tunnel.
Pour rester simple, toutes les machines du Site 2 devront pouvoir communiquer avec les machines du Site 1.

Etant donné que les passerelles VPN (cudy) sont placées derrière des pare-feux (PF2 et PF1), nous devrons obligatoirement DNATer le port UDP 1194 sur le pare-feu PF1, autrement, lorsque le client VPN (Cudy2) tentera de se connecter au serveur VPN (Cudy1), il ne pourra pas pas l'atteindre.
Nous n'allons pas nous attarder ici sur le DNAT (redirection de port)
L'objectif étant que lorsque le client VPN contacte l'adresse IP publique du PF1 sur le port 1194 (80.80.80.10:1194), le trafic soit redirigé vers l'IP du Cudy1, sur le même port 1194 (192.168.5.2:1194).

80.80.80.10:1194 -> 192.168.5.2:1194

Plusieurs articles montrent comment réaliser un DNAT sur PFsense, OPNsense, DynFi, Wingate etc...
Vous devrez mettre en place ce DNAT seul.

Passons à la configuration des Cudy, à proprement parler.

Configurer un cudy de base :

Tout d'abord, pour configurer un Cudy de base, il faut que le PC client connecté (AD ou CLIENT ici) se mette sur le même réseau que le Cudy : 192.168.10.1/24.
Donc, il faudra configurer l'AD (ou une autre machine sur le Site 1) avec l'IP 192.168.10.2/24 (par exemple) et réciproquement sur le Site 2.

Ensuite, ouvrir un navigateur web, et taper http://192.168.10.1
Le mot de passe de base est "admin" pour s'identifier.

Je ne vais pas détailler la façon de configurer les adressages IP des Cudy, l'ergonomie est tellement bonne que tout se fait en moins de 2 minutes !

Donc, avant de continuer, l'adressage réseau de tous les équipements doit être correctement effectué, conformément au schéma.
La passerelle indiquée sur la configuration IP de l'AD et du CLIENT doit être l'adresse IP du cudy respectif.
Pour l'AD, la passerelle sera 10.10.10.1, pour le CLIENT : 10.10.20.1

----------

Voici le cudy1 (vous n'avez pas encore l'encart du VPN... c'est normal. La capture a été prise post-configuration) :

Voici le cudy2 :

Passons à la configuration du serveur VPN (Cudy1) :

Dans "Paramètres généraux", cliquer sur VPN, puis Paramètres.
La configuration est enfantine, vraiment !

Cependant, il ne faut surtout pas oublier de créer un réseau virtuel pour le VPN.
Ici, il s'agira du réseau 10.199.199.0 (masque : 255.255.255.252)
Pourquoi ce masque ? Parce que nous n'allons connecter que 2 Cudy (le Cudy1 au Cudy2), il n'est donc pas nécessaire d'avoir plus de 2 IP sur ce réseau. Le serveur prendra automatiquement la première (10.199.199.1) et le client la seconde (10.199.199.2).

Une fois la configuration faîte, il faut exporter le fichier de configuration.
Ce fichier devra être importé (clef USB, mail etc..) sur le Cudy2 pour générer plus rapidement la configuration VPN.
Mais avant de l'importer sur le Cudy2, nous allons devoir effectuer une modification (à cause du NAT).

Une fois la configuration exportée, veuillez ouvrir le fichier "client.ovpn" exporté avec le Bloc-Note et procéder à la modification d'adresse IP de destination (remote ...).
Le Cudy1 a naturellement placé sa propre adresse IP WAN sur la ligne "remote ..." suivi du port UDP 1194.
Sauf que cette IP ne pourra pas être contactée directement par le Cudy2 puisque le Cudy1 se trouve derrière PF1, dans un réseau NATé.
Nous allons donc indiquer l'adresse IP publique du pare-feu PF1 (qui effectuera lui-même la redirection de port) : 80.80.80.10.

client
dev tun
proto udp
remote 80.80.80.10 1194
data-ciphers AES-256-GCM
data-ciphers-fallback AES-128-CBC
compress lz4
nobind
auth-nocache
persist-key
persist-tun
user nobody
keepalive 10 120
verb 3

<ca>
-----BEGIN CERTIFICATE-----
# [...] les certificats s'enchaînent.. ne rien toucher.

Envoyer ensuite ce fichier "client.ovpn" sur la machine du Site 2 qui accède au Cudy2.

Configurer le client VPN (cudy2)

Lorsque vous importez le fichier de configuration VPN, l'adresse du Serveur 80.80.80.10 s'affiche automatiquement dans les réglages manuel.
Si vous avez besoin d'appliquer des règles de pare-feu pour la connexion de site-à-site, cela se fait dans "Règle par défaut" ainsi que dans "Sous-réseau distant".

Lorsque la connexion s'initie, le statut Connecté s'affiche en bas. Sur la page d'état du système, vous verrez l'adresse IP de la passerelle pour le tunnel VPN.

La configuration n'est pas tout à fait terminée. Il manque un critère important : le routage !

Il faut créer une route statique sur le Cudy2 afin de permettre au trafic en direction du réseau du Site 1 de passer par le tunnel VPN.

Aller dans Paramètres avancés, Routage :
(pour joindre le réseau 10.10.10.0 (qui habrite le serveur AD), il faut passer par la passerelle du VPN 10.199.199.2).

Grâce à cette règle, le poste CLIENT peut donc contacter l'AD sans avoir besoin d'ajouter une règle à sa table de routage.
Etant donné que la passerelle du CLIENT est l'IP LAN du Cudy2, ce dernier routera alors automatiquement les paquets dirigés vers le réseau local du Site 1 grâce à notre règle de routage ajoutée.

En cas de connexion client-to-site, n'oubliez pas de configurer votre interface "Local Area Connection" en attribuant l'IP du serveur Active Directory distant en tant que DNS. Autrement vous ne pourrez pas accéder aux partages via la VPN.

Nous conviendrons tous que le fait que mettre des serveurs Windows en frontal sur internet est une MAUVAISE idée.
L'idée de ce tuto est d'abord de se familiariser avec la configuration du VPN L2TP/IPsec de Windows Serveur, qui est quelque peu déroutante au début.
Ensuite, une fois la logique de configuration comprise, et bien que les pare-feux modernes (UTM) permettent de créer tous les VPN du monde directement, on pourra néanmoins parfaitement utiliser Windows Serveur pour créer un tunnel VPN, mais en cachant les serveurs VPN derrière de vrais pare-feux.
On activera alors alors le NAT-T de chacun des serveurs windows VPN en créant une clef de registre dans regedit puis en redémarrant chaque serveur après.

reg add HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f 

On mettra en place les DNAT appropriés (UDP 500 et UDP 4500) sur le pare-feu cachant le serveur AUQUEL on essaie de se connecter (La connexion est initiée depuis l'un des 2 serveurs), et on reconfigurera les interfaces VPN des 2 serveurs Windows pour qu'ils pointent vers les IP publiques des pare-feux distants.
Attention au choix des pare-feux concernant ce type de mécanisme avec L2TP. OPNsense par exemple, n'est pas compatible avec ce type de montage, mais PFsense si (c'est très étrange.. ou alors c'est moi qui suis nul !).

Mais pour l'heure, apprenons à configurer un VPN L2TP/IPsec simplement.

Soit le schéma ci-dessus :
- 2 zones géographiquement distantes (Tombouctou et Bayonne).
- 2 serveurs Windows 2022 qui vont faire office de serveurs VPN (VPN1 et VPN2). Tous deux respectivement connectés à internet ainsi qu'à leur propre LAN. Le VPN1 est à Bayonne, le VPN2 est à Tombouctou.
- Nous réalisons le labo sur Hyper-V et créons un commutateur virtuel interne "COM_NET" pour simuler internet entre les 2 VPN. Les commutateurs COM_LAN-01 et COM_LAN-02 sont également des commutateurs internes.
- Nous considérons les configurations réseau IP déjà faîtes sur chaque appareil, conformément à l'adressage IP présenté sur le schéma. Le CLIENT a pour passerelle VPN2 et l'AD VPN1. Pour joindre le domaine, on oubliera pas d'entrer l'IP de l'AD en DNS du CLIENT.

Le but : permettre au poste client CLIENT, situé à Tombouctou, de rejoindre le domaine "BARON.NET" contrôlé par le contrôleur de domaine "AD" à Bayonne.

La configuration se fait en parallèle ici, pour que ce soit plus clair.
Aucun des serveurs ne se trouve dans un domaine pour ce tuto.
Nous utiliserons ici le secret partagé puisqu'il s'agît de se familiariser avec la configuration du VPN L2TP/IPsec sur Windows, et non le certificat SSL. L'utilisation d'un certificat est néanmoins indispensable en production.

1) Installer le rôle Accès Distant sur les 2 serveurs
VPN2 est à gauche, VPN1 est à droite

Cliquez sur "2 Ajouter des rôles et des fonctionnalités".
L'installation est identique sur les 2 serveurs. 

Cochez "Accès à distance" :

Laissez par défaut :

Cochez "DirectAccess et VPN..."

Laissez par défaut :

Laissez par défaut :

Fermez une fois l'installation terminée :

Cliquez sur le drapeau des notifications (un avertissement jaune est apparu) :

Cliquez sur "Ouvrir l'Assistant Mise en route" :
(Il faut parfois attendre une minute avant que l'assistant ne se lance)

2) Configurer le VPN de site à site

Une fois l'Assistant lancé, cliquez sur "Déployer VPN uniquement" :

Cliquez-droit sur la ligne "VPNx (local)" et choisissez" Configurer et activer le routage et l'accès à distance" :

Cliquez sur "Configuration personnalisée" :

Cochez "Accès VPN" et "Connexion à la demande" :

Pas de panique, c'est normal, cliquez OK

Cliquez sur "Démarrer le service" et attendez patiemment.

Cliquez-droit à nouveau sur "VPNx (local)" et choisissez "Propriétés" :

Allez dans l'onglet Sécurité, cochez "Autoriser la stratégie IPsec personnalisée..." et Entrer la même clef partagée sur les 2 VPN :

Cliquez sur "Appliquer", puis sur OK :

Cliquez à présent sur l'onglet IPv4, nous devons spécifier un pool d'IP statiques pour nos interfaces virtuelles de VPN :

Nous avons besoin de 2 IP dans chacun des réseaux LAN distants.
Si vous disposez d'un DHCP sur chaque LAN, alors il n'est pas indispensable d'utiliser un pool statique.. Même si c'est toujours préférable.
VPN2 doit emprunter 2 IP sur le LAN qui lui est associé (192.168.20.0/24) et VPN1 doit faire de même sur son LAN à lui :

Cliquez OK 2 fois. 

Cliquez-droit sur "VPNx (local)", Toutes les tâches, Redémarrer, puis patientez :

Cliquez-droit sur "Interfaces réseau", Nouvelle interface de connexion à la demande... :

Donnez le nom du VPN distant à l'interface (c'est une pratique usuelle).
Donc du côté du VPN2 (à gauche) on appelle l'interface VPN1, et du côté du VPN1 (à droite) on appelle l'interface VPN2 :

Laissez par défaut :

Choisissez L2TP :

Entrez l'IP publique du VPN distant.
Sur VPN2 (à gauche), entrez l'IP de VPN1. Sur VPN1 (à droite), entre l'IP de VPN2

Cochez la création d'un utilisateur :

Cliquez sur "Ajouter" :

Nous devons à présent indiquer à chaque VPN le ou les réseau(x) privés de la zone distante pour lesquels nous voulons que le VPN soit en mesure de router les paquets.
Ici, ce n'est pas difficile puisque chaque VPN n'est connecté qu'à un seul réseau LAN.
VPN2 est connecté à COM_LAN-02 et VPN1 à COM_LAN-01. 
Autrement dit, on indique au VPN de Tombouctou le réseau local de Bayonne, et au VPN de Bayonne le réseau local de Tombouctou.
Attention, il s'agît d'adresses IP RESEAU !

Si besoin d'ajouter plusieurs réseaux, cliquer de nouveau sur "Ajouter".

Cette étape consiste à créer un utilisateur local qui permettra d'établir la connexion.
Sur VPN2, un utilisateur local VPN2 sera créé. Lorsque VPN1 voudra initier la connexion, il devra indiquer les identifiants de cet utilisateur VPN2. 
Sur VPN1, un utilisateur local VPN1 sera créé. Lorsque VPN2 voudra initier la connexion il devra réciproquement indiquer les identifiants de cet utilisateur VPN1.

Nous devons à présent indiquer à chaque VPN les identifiants de l'utilisateur créé localement sur le VPN distant.
Nous indiquons à VPN1 les identifiants de l 'utilisateur VPN2 et réciproquement :

Cliquez-droit sur l'interface nouvellement créée, Propriétés :

Dans l'onglet "Sécurité", Cliquez sur "Paramètres avancés" et remplissez la clef partagée créée plus haut :

Cliquez OK 2 fois.  

3) Démarrer la connexion :

On va initier la connexion VPN depuis Bayonne (VPN1).

Clic-droit sur l'interface VPN2 fraîchement créée, "Se connecter".

La connexion s'établit.
Côté gauche, cliquez-droit dans le vide, Actualisez, pour voir le statut s'actualiser.

Ne reste plus qu'à intégrer le client au domaine en précisant comme DNS l'IP du serveur. Le Routage va se faire tout seul.

Après avoir mis en place :
- le proxy,
- le déchiffrement des connexions SSL,
- importé/créé des utilisateurs
- créé les credential rules pour identifier vos utilisateurs/postes

alors vous pouvez consulter les logs des utilisateurs directement depuis WinGate Management :

Les fichiers de log sont stockés dans "C:\Program Files\WinGate\Logs\WWW Proxy Server Usage"

Par défaut, un fichier de log est créé chaque jour, contenant tout le trafic internet.
Il est possible de changer cela (en fonction du trafic généré par le parc).

Continuons notre découverte de WinGate.

WinGate permet d'attribuer soit une IP, soit un nom d'hôte ou encore une adresse MAC à un utilisateur en particulier. C'est évidemment fort utile pour retracer l'activité "malveillante" ou "incorrecte" d'un poste ou d'un utilisateur en cas de problème... surtout sur un parc de 50 machines.

Il existe 2 façons de procéder sur WinGate :
1) recréer vous-mêmes tous les utilisateurs de votre parc.
2) Connecter un annuaire Active Directory
  (je précise au passage qu'il faut une licence pro ou entreprise pour se connecter à un AD)

Ensuite, il faudra associer soit l'IP, soit le nom d'hôte, soit l'adresse MAC à un utilisateur.
Enfin, et à condition d'avoir au préalable configuré proprement le proxy et le déchiffrement SSL (voir les articles concernant cela dans la rubrique Pare-Feu/Wingate), vous pourrez voir l'activité en direct des utilisateurs.

Pour l'option 1), il suffit d'aller dans la rubrique "Users and Groups", et de cliquer sur "New User".

Vous pouvez également créer des groupes et y incorporer vos utilisateurs.

Pour l'option 2) (via l'AD), il faut déjà que la machine hébergeant WinGate soit membre du domaine AD que l'on veut connecter, puis il nous faut s'y connecter dans WinGate Management.
Cliquer sur "Select Provider"

Associer une IP/nom d'hôte/MAC à un utilisateur.
Une fois que nous avons créé ou importé nos utilisateurs. Nous pouvons les associer à la machine qu'ils utilisent. 

Pour cela, aller dans "Credentials rules", puis cliquer sur "Add a new rule".
Choisissez ensuite la manière d'identifier l'utilisateur (IP/ComputerName/Physical address).
Nous allons choisir l'adresse MAC ici.

(Attention, l'option "Don't allow credentials established..." n'est disponible qu'avec la licence entreprise)

Nous pouvons maintenant observer le trafic de l'utilisateur Marcel Roger dans l'onglet Activity :
(à condition d'avoir au préalable activé le proxy et le déchiffrement SSL.. Voir les articles concerné)

(et constater que l'utilisateur Marcel Roger fait des emplètes de croquettes pour chat sur Amazon :-D).

Evidemment, toute l'activité est loguée sur WinGate. Ce que vous voyez s'afficher dans Activity est intégralement enregistré.

Plus simple à configurer, c'est difficile.

Le Service à utiliser est "WWW Proxy Service" (comme pour le proxy).
Je montre la configuration de base pour un site web hébergé sur le serveur Wingate

1) Télécharger, installer et configurer PHP (au cas où vous en auriez besoin)
- Téléchargez et installer VC15 & VS16 en premier  
- Télécharger PHP 8.2.10 Non Thread Safe  

Décompresser le dossier PHP à la racine (par exemple C:\PHP)

Puis, configurez le fichier C:\PHP\php.ini pour le CMS ou l'application web que vous voulez héberger.
Voici un fichier de configuration php.ini usueI :

[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = -1
disable_functions =
disable_classes =
zend.enable_gc = On
zend.exception_ignore_args = On
zend.exception_string_param_max_len = 0
expose_php = On
max_execution_time = 300
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
extension_dir = "C:\PHP\ext"
enable_dl = Off
cgi.force_redirect = 0
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60

;;;; ---- EXTENSIONS USUELLES ---- ;;;;
extension=zip
extension=bz2
extension=curl
extension=fileinfo
extension=gd
extension=intl
extension=ldap
extension=mbstring
extension=exif
extension=mysqli
extension=openssl
extension=sodium
zend_extension=opcache
error_log  = "C:\Windows\Temp\FastCGI - PHP_errors.log"
upload_tmp_dir = "C:\Windows\Temp\"
cgi.fix_pathinfo = 1
fastcgi.impersonate = 1
;;;; --------------------------------------- ;;;;

[CLI Server]
cli_server.color = On
[Date]
date.timezone = Europe/Paris
[Pdo_mysql]
pdo_mysql.default_socket=
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
[mysqlnd]
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
[PostgreSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
[bcmath]
bcmath.scale = 0
[Session]
session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
;session.cookie_secure = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly = 1
session.cookie_samesite =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.sid_length = 26
session.trans_sid_tags = "a=href,area=href,frame=src,form="
session.sid_bits_per_character = 5
[Assertion]
zend.assertions = -1
[Tidy]
tidy.clean_output = Off
[soap]
soap.wsdl_cache_enabled=1
soap.wsdl_cache_dir="/tmp"
soap.wsdl_cache_ttl=86400
soap.wsdl_cache_limit = 5
[ldap]
ldap.max_links = -1

2) Configurez le serveur Web de Wingate
Lancez Wingate, puis rendez-vous dans les Services.
Installez un nouveau service "WWW Proxy Service" (différent de votre Proxy si vous en avez déjà un).
Je ne l'ai pas fait ici, mais vous pouvez le renommer pour le nom de votre site par exemple.
Sur l'onglet "General" du service WWW Proxy Service, vous pouvez spécifier le port d'écoute pour votre site (par défaut, c'est le 80)

Action : Serve (= servir les requêtes des clients)
Server root folder : le dossier racine de votre site.
Default filename : la page index de votre site (.php si c'est du php)
Allow CGI : permettre l'exécution pour PHP
CGI root folder : le dossier C:\PHP (qui contient les exécutables php)
CGI URL prefix : *.php

Il faut à présent configurer une association des fichiers php du site avec l'exécutable php.exe

Cliquez sur Add et configurer l'extension "php" et pointez l'exécutable "C:\PHP\php-cgi.exe"

N'oubliez pas d'appliquer et de cliquer sur OK.
Voilà, le site est déjà en ligne sur l'IP 127.0.0.1:80

Pré-requis : 
- Wingate installé sur une machine Windows 10/11/Server 2019/2022, le routage est activé, avec une licence active (ou version d'essai 30 jours)
- Vous disposez du plugin Kaspersky fonctionnel avec une licence active (ou version d'essai de 30 jours)

Par défaut, dès lors que le plugin Kaspersky est actif et que les bases de signatures sont chargées, le trafic http est automatiquement scanné dès qu'un client de votre LAN fait une requête depuis son navigateur web.
Ceci étant dû au fait que le proxy est configuré par défaut pour écouter tout ce qui passe sur le port 80.

Dans ce tuto, je vous montre comment intercepter le trafic HTTPS (SSL) sur Wingate, le décrypter, l'inspecter (et éventuellement le bloquer en cas de virus), puis le réencrypter avant qu'il atteigne les clients du LAN.

C'est extrêmement simple à mettre en oeuvre sur Wingate.

1) Créer un certificat SSL autosigné
Cliquez sur "Certificates" dans le "Control Panel", puis cliquez-droit dans la liste vide au milieu ou cliquez directement dans le menu des "Tasks" en bas gauche : "New certificate".

- Créez votre certificat

- Ajoutez une passphrase :

Votre certificat est prêt !

Avant de continuer, nous allons exporter ce certificat car nous en aurons besoin pour nos clients.
Double-cliquez sur votre certificat "WINGATE", rendez-vous dans l'onglet "Détails" et cliquez sur "Copier dans un fichier..."

Veuillez à présent transférer le certificat exporté "wingate.cer" sur l'ordinateur de votre client (ou faîtes une installation par GPO...)

2) Configurer le proxy et mettre en place l'inspection SSL 
Comme dit plus haut, il se déploie automatiquement lorsque vous installez Wingate et écoute le port 80, néanmoins, nous allons changer le port d'écoute et activer l'inspection SSL grâce à notre super nouveau certificat auto-signé.

Double-cliquez sur "WWW Proxy Service" pour afficher ses propriétés.
Si le service n'est pas déjà présent dans liste (ou que vous l'avez supprimé par inadvertance), faîtes un clic-droit, "Install service" est choisissez "WWW Proxy Service"

- Changez le port 80 par défaut pour le 3128 ou un autre.

- Vous assurer que le proxy va bien écouter sur les interfaces voulues 
(Ici, je n'ai qu'un seul LAN, donc je peux le laisser sur "Bind to any IP address on any internal adapter").
Il faut que le proxy écoute sur ce LAN et également sur la Loopback !
A vous de faire en fonction de votre réseau.

- Cliquez sur l'onglet "SSL Inspection"
Cochez selon la capture ci-dessous, choisissez votre certificat SSL créé précédemment dans la liste, puis Appliquez et OK.
(Bon, je suis un peu restrictif, puisque si un site n'a pas son certif à jour, ça ne passera pas... à vous de voir).

A présent, l'inspection SSL fonctionne. Nous devons configurer le CLIENT, afin que ses requêtes soient redirigées vers le Proxy Wingate (elles seront ainsi inspectées)

3) Configurer la redirection des requêtes vers le serveur Proxy Wingate sur votre CLIENT dans le LAN.
Ouvrez la paramètres proxy :

A présent, l'inspection SSL fonctionne... Mais votre CLIENT dans le LAN va râler en vous affichant l'habituelle erreur de certificat SSL à la moindre page web ! C'est normal. Nous allons devoir ajouter le certificat autosigné généré sur Wingate au "magasin" des certificats racine sur notre CLIENT.

4) Exporter le certificat WINGATE et l'importer dans le magasin des certificats racine sur votre CLIENT :
Vous avez normalement importé votre certificat wingate.cer sur votre CLIENT à la fin de l'étape 1).
Il est donc sur le bureau du CLIENT
Nous allons l'importer.
Rendez-vous dans "Gérer les certificats utilisateur"

Cliquez sur "Autorités de certification racines de confiance", puis cliquez-droit sur "Certificats", "Toutes les tâches", "Importer..."

Votre certificat est à présent importé et apparaît dans la liste :

Quittez Edge (vraiment) et relancez-le.
Les erreurs SSL ne sont plus présentes.

Voilà. Tout votre trafic http & https est à présent scanné et inspecté sur le serveur Wingate

Mais vous pouvez aller beaucoup plus loin, en appliquant des Access Rules dans le menu "Web Access Control" sur Wingate.
Vous pouvez créer des règles spécifiques en fonction des utilisateurs de votre AD etc...
C'est assez énorme !

Enfin, si vous avez le plugin Lumen en plus, vous diposez d'une base importante de gestion des accès internet.

Une dernière chose, si vous aviez créé une règle d'accès à internet depuis le LAN TCP HTTPS 443 sur le pare-feu, il faut la supprimer car elle n'est plus utile. Vous remarquerez au passage que celle sur le port 80 est redirigée automatiquement vers le Proxy :

2 pare-feux pfsense en "cluster"

Qu'est-ce que cela veut dire ?
C'est simple : Quand l'un tombe en panne (le master), le second (le backup) prend le relai, et continue à la fois de router les paquets, et d'assurer la sécurité du réseau, sans qu'il n'y ait besoin d'intervention humaine.
Un seul des 2 pares-feux joue le rôle de master en permanence. Il n'y a qu'un pare-feu qui travaille (sur les 2).
Mais dès lors qu'il tombe en panne, le second prend le relai immédiatement.

Cela suppose que ces 2 pfsense (appelons-les PFSENSE01 et PFSENSE02) doivent répondre sur une adresse IP commune (une "VIP", pas une Very Important IP, mais pas loin .. une Virtual IP), que ce soit côté WAN ou côté LAN.

La mise en cluster des PF est extrêmement simple, mais de grâce, lisez ATTENTIVEMENT ce que j'écris !
ça vous évitera un paquet d'em*****...
Le schéma doit être parfaitement maîtrisé.

Un petit schéma pour voir ce qu'on va faire :

Internet arrive par le côté WAN (qui ici, passe d'abord par un réseau non routable, pour les besoins du TP).
Les 2 pares-feux PFSENSE01 et PFSENSE02 vont donc permettre d'isoler le réseau LAN comme on isolerait le réseau LAN de l'entreprise (de façon simpliste ! c'est un TP !!)

Pour les besoins de la mise en cluster  :
1) chaque pare-feu doit avoir, a minima, 3 cartes réseaux :
- une interface côté WAN (WAN). 
- une interface côté LAN (LAN)
- et une interface de synchronisation entre les 2 pare-feux (PFSYNC)

Cette dernière est très importante pour augmenter la sécurité et la rapidité des échanges entre les 2 pares-feux.
On pourrait parfaitement s'en passer, mais ce n'est pas recommandé.

A savoir, vous pouvez (dans le cadre du TP) utiliser un DHCP pour vos interfaces des PF côté WAN, mais vous devrez en revanche impérativement pouvoir disposer d'une IP statique pour les VIP côté WAN et LAN !
Les VIP ne s'adressent pas via DHCP, c'est du statique.

Sur l'hyperviseur, nous parlerons de commutateurs virtuels.
Il faut donc 3 commutateurs virtuels, auxquels seront attachées les interfaces de nos pares-feux.
- COM_EXT (un commutateur "externe") qui est ponté sur la carte réseau physique de notre hyperviseur
- COM_LAN (un commutateur "interne"), qui servira à relier notre CLIENT dans le LAN ainsi que les PF
- COM_PFSYNC (un commutateur "interne" ou "privé") pour relier nos 2 PF et uniquement eux.

2) L'usurpation d'adresse MAC (MAC spoofing) DOIT IMPERATIVEMENT ETRE PERMISE SUR LES INTERFACES WAN ET LAN DE CHACUN DES PARES-FEUX.
Si vous n'activez pas cette fonctionnalité sur votre hyperviseur, la mise en cluster ne fonctionnera tout simplement pas !
Si vous êtes sur Hyper-V, voici où ça se situe :

(Je répète que cette opération doit être réalisée sur les interfaces WAN et LAN de chacun des pares-feux !)

 Sur VMWare Workstation, cette opération n'est pas nécessaire.

Commençons !

1) Créez vos VM, configurez leurs interfaces et adressages IP tel que le précise le schéma.
N'oubliez pas de configurer votre CLIENT, car c'est grâce à lui que nous accéderons aux consoles Web des PF.
Dans un premier temps, mettez lui l'IP de PFSENSE01 comme passerelle. Nous changerons cela à la fin du tuto.

2) Configurez les interfaces des PF en CLI :
- Pour rappel, on commence d'abord par assigner les interfaces (1), puis on paramètre les configurations IP (2) pour chaque interface. (A titre perso, je préfère le faire ainsi, ça va beaucoup plus vite que via la console web)

Voici ce que vous devez obtenir :

3) Depuis votre CLIENT, connectez vous à la console des 2 PFSENSE, côte à côte (prenez cette habitude !) !
(passez les avertissements de sécurité SSL usuels)

Entrez les identifiants par défaut de pfsense : admin/pfsense

- Faîtes la configuration du wizard de base sur les 2 PF :

Libre à vous de mettre autre chose que CloudFlare (1.1.1.1) mais pensez à bien entrer un hostname différent sur chaque PF

(Notre WAN dans ce TP est un réseau non routable (192.168.1.0/24), donc il faut décocher la RFC1918)

(je ne change pas le mot de passe admin pour ce TP... bien entendu, vous le ferez en vrai !)

- Nous voici sur le Dashboard. On va pouvoir commencer la configuration.

4) Configurer les VIP 

- Nous allons créer la VIP côté WAN. Cette VIP aura l'IP 192.168.1.246.
Bien entendu, cette IP doit être libre (et ne pas figurer sur une étendue DHCP... par exemple).

Pour créer une VIP commune aux 2 PF, PFsense va créer un groupe VHID.
Ce VHID doit évidement être le même sur les 2 PF pour la même VIP.

Il faut créer un mot de passe pour ce groupe VHID 1, et mettre le même sur les 2 PF !
(d'où l'intérêt de la configuration des 2 côtés en même temps !).
Prenez soin de ne pas mettre de caractères spéciaux ou d'espaces dans les mots de passe.. ça pose régulièrement des problèmes sur pfsense.

A noter : le skew !! C'est lui qui détermine qui jouera le rôle du master, et qui jouera le rôle du backup !
Le master doit avoir le skew le plus bas (0). Ici, nous alternerons simplement entre 0 et 1.
PFSENSE01 (à gauche) sera donc le master !
PFSENSE02 (à droite) sera donc le backup

Inutile d'appliquer les changements tout de suite, créez tout de suite votre seconde VIP (côté LAN).

- même topo pour la VIP du côté LAN. A ceci près que le VHID n'est plus le même que sur la VIP WAN ! (logique) et que vous avez pris soin de choisir l'interface LAN.

Pour le skew : on ne s'amuse pas à changer de rôle selon une VIP ou l'autre ! 
Nous avions décrété que PFSENSE01 serait le master, donc on remet le skew à 0 pour PFSENSE01 et à 1 pour PFSENSE02.

- Appliquez à présent les changements.

- Les VIP sont à présent configurées.

5) Configurer l'interface de Synchronisation
Comme la configuration a été effectuée au tout début en CLI, nous allons simplement la renommer plutôt que de garder le nom de la première interface optionnelle (OPT1) par défaut de pfsense.

- Changez simplement la description puis descendez tout en bas pour sauvegarder, puis appliquez la configuration.

6) Configurer le cluster
Nous devons maintenant expliquer aux PF comment ils devront communiquer leurs informations de statut et les services configurés
Attention, la configuration n'est pas la même sur les 2 nœuds !

- Cocher la synchronisation des états sur les 2 nœuds.
- Sélectionnez l'interface PFSYNC pour la communication entre les 2 PF
- Indiquez l'adresse IP de l'autre nœud (réciproquement) dans le champs "pfsync Synchronize Peer IP"
- Indiquez l'IP de PFSENSE02 dans le champs "Synchronize Config to IP" sur PFSENSE01 et RIEN SUR PFENSE02 !
- Idem utilisateur et mot de passe (les identifiants par défaut de pfsense : admin/pfsense) , QUE SUR PFSENSE01 (le master)

- Cochez la synchronisation des identifiants admin, puis cliquez sur "Toggle All" en bas pour sélectionner tous les services à synchroniser d'un coup (ou choisissez uniquement ce que vous voulez synchroniser !)

La validation prend plus de temps sur PFSENSE02 que sur PFSENSE01, c'est normal. Patientez.
A l'issue de la sauvegarde, vous voici de retour en haut de la page

7) Visualisez le statut CARP

Vous pouvez constater que chaque PF a bien son statut. PFSENSE01 est le master, PFSENSE02 est en backup.
La configuration de la redondance CARP est terminée.

Si vous coupez PFSENSE01, vous verrez que PFSENSE02 deviendra le master.

8) Règle de pare-feu sur PFSYNC :
Il nous reste une règle de pare-feu à mettre en place sur l'interface PFSYNC pour permettre la réplication automatique de configuration de PFSENSE01 sur PFSENSE02 (Il vous suffira après cela, de ne configurer que PFSENSE01, et les règles se dupliqueront sur le 2 automatiquement).

Voilà.
A présent, XMLRPC va pouvoir répliquer les configurations de PFSENSE01 sur PFSENSE02.

Le meilleur moyen de le tester, c'est de créer une règle à la noix ou de faire un DNAT redirection de ports sur PFSENSE01 et de regarder tout de suite après l'application, si la règle est bien répliquée...
Exemple ici, avec un DNAT rdp sur PFSENSE01... répliqué aussitôt appliqué sur PFSENSE02 :

9) Indiquez la VIP LAN en tant que nouvelle passerelle pour le réseau LAN.
Configurez l'adressage IP de votre CLIENT, afin que la passerelle soit désormais la VIP LAN (10.10.10.3)

Le tuto est terminé....
Mais la configuration du cluster peut aller BEAUCOUP plus loin... Je vous laisse explorer.

Je suis toujours en test de Wingate, par curiosité.. (le dernier des mohicans)
(c'est le dernier pare-feu - hormis celui de windows - à être basé sur le système windows).

Après avoir compris comment faire une redirection de ports (DNAT) - ce qui est d'ailleurs plutôt bien fait - je testais ce matin le scan du trafic HTTP avec le plugin de Kaspersky pour Wingate. Pour le scan du trafic HTTPS, suivez cet article puis le suivant
Il y a 30 jours d'essai gratuit, au-delà, il faut une licence.

Une petite complication empêche de se servir tout de suite du plugin. Ceci étant lié au fichier Kaspersky.key qui se trouve dans le dossier :
C:\Program Files\Kaspersky AV for WinGate (64bit)\Scanner

La version qui s'installe avec le plugin Kaspersky doit être mise à jour, il y a une petite difficulté, suivez les opérations ci-dessous :

Voici comment procéder pour installer correctement le plugin Kaspersky avec Wingate.

1) Stopper le service Wingate Engine
2) Télécharger et Installer le plugin Kaspersky 
3) Relancer WinGate Management et tenter de faire la première update de Kaspersky. (ça va foirer)
4) Télécharger le fichier mis à jour de Kaspersky.key 
5) Remplacer le fichier Kaspersky.key installé avec le plugin par le nouveau téléchargé dans C:\Program Files\Kaspersky AV for WinGate (64bit)\Scanner
6) Redémarrer l'ordinateur
7) Retourner dans WinGate Management et faîtes la mise-à-jour de Kaspersky... 2 fois ! (la première foire parfois)

Regarder la procédure donnée par Adrien de Croy sur le forum si vrai problème : (mais le problème rencontré par cet utilisateur n'est pas vraiment le même !)

WinGate Forums • View topic - Signature update failed

Après le téléchargement de la base, le plugin se met en fonctionnement et commence à scanner le trafic réseau.
Voici un exemple simple avec le fichier eicar pour vérifier que le trafic est bien scanné :
- depuis un poste client derrière le pare-feu wingate, tentez de télécharger le fichier eicar depuis cette page : Download Anti Malware Testfile - EICAR  
Vous devriez voir le résultat suivant :

La détection s'est faite correctement. Le navigateur du client affiche que le trafic a été bloqué en raison d'un virus, et une menace détectée apparaît quelques secondes après sur le panneau de contrôle du plugin Kaspersky.

Vous pouvez ajuster l'analyse de trafic en cliquant sur les Settings (en bas à gauche).
Vous pouvez créer un fichier pour les listes blanches, ajuster la force d'analyse etc..

Concernant le fonctionnement du plugin en lui-même :
Il scanne le trafic réseau (http, ftp etc..) en direct.
Il fonctionne de manière classique : Il segmente les paquets, en laisse passer un petit morceau pour ne pas faire foirer les mises en cache des navigateurs et analyse un petit morceau. Si le paquet est jugé mauvais, le trafic est alors interrompu. Néanmoins, certains flux supportent mal ce type de fonctionnement (notamment le streaming, les MAJ windows...)
Il faut alors utiliser les listes blanches de wingate pour ne pas perturber ces flux.

Etrangement compliqué sur OPNsense

On va prendre un exemple simpliste  :
- J'ai un CLIENT Windows 11 dans mon LAN dont l'IP est 192.168.10.2. (Vous avez évidemment activé le RDP dessus)
- L'adresse WAN de mon pare-feu est 82.34.45.56

Je souhaite pouvoir accéder à mon CLIENT en RDP depuis l'extérieur de mon réseau... Réponse rapide : on fait un DNAT port (port forwarding).

Le principe : On contacte 82.34.45.56:53389 et le pare-feu doit nous rediriger vers 192.168.10.2:3389


Autant c'est facile sur PFsense (voir l'article), autant sur OPNsense...
Attention, vous n'avez pas le droit à l'erreur... Suivez attentivement ou vous allez vous y reprendre à 10 fois (c'est du vécu !)

Sur la console web d'OPNsense : (via votre navigateur internet)

(menu vertical de gauche)

1) Allez dans "Pare-Feu"  -> Paramètres -> Avancé
Cochez "Réflexion pour les transferts de port" et "NAT sortant automatique pour la Réflexion"
Descendez tout en bas et Sauvegardez

2) Pare-feu -> NAT -> Redirection de port
Cliquez sur le petit "+" pour ajouter un DNAT

Configurez à présent votre DNAT :

N'oubliez pas de valider les modifications lorsque votre DNAT est sauvegardé :

Enfin, si vous faîtes du LABO (si votre WAN addresse est une IP non routable du style 192.168...), rappelez-vous qu'OPNsense applique scrupuluseuement la RFC1918... et qu'il vous faudra peut-être la désactiver.

Bien entendu, vous pouvez faire un Alias d'hôtes pour plusieurs machines !

A la différence d'OPNsense, sur Pfsense, vous avez beau choisir le français lors de l'installation, le clavier reste en QWERTY.

Voici comment réparer ce traumatisme !

Lancez le Shell (choix 8) puis tappez :

kbdcontrol -l /usr/share/vt/keymaps/fr.kbd

Quittez le shell pour revenir au menu principal avec

exit

Vous disposez de votre propre liste d'IP (et/ou de sous-réseaux, écrits en notation CIDR) dans un fichier (une par ligne).
Vous souhaitez bloquer les connexions vers/depuis ces IP ?

Voici comment faire pour les bloquer facilement dans opnsense (sans avoir à passer par un proxy)
(les captures d'écran sont réalisées sur opnsense, mais Dynfi se présente de façon identique, vous allez rapidement adapter depuis ces captures)

1) Créer un Alias
Rendez-vous dans Firewall, Aliases

Cliquez sur le + en bas à droite pour ajouter un alias

Choisissez le type : Host(s)
Copiez le contenu de votre fichier d'IP/sous-réseaux dans l'encart "Content"
Sauvegardez

Appliquez l'Alias en cliquant sur Apply en bas

2) Créer une règle flottante bloquante et y pointer notre alias
Rendez-vous dans Firewall, Rules, Floating et cliquez sur le + en haut à droite pour ajouter une nouvelle règle

Choisissez l'Action Block, puis sélectionnez les interfaces LAN et WAN, une par une (ça coche)
Direction/Protocol/Sources : Any
TCP/IP Version : IPv4 + IPv6

Dans l'encart de Destination, entrez le nom de votre alias (BLOCAGE ici)
Entrez une description, puis sauvegardez

Enfin, appliquez les changements pour activer votre règle de blocage.

C'est terminé.

DynFi est un pare-feu français, désormais basé sur FreeBSD.
Il mérite qu'on s'y intéresse !

Pour l'instant, l'interface est la même que sur OPNsense mais le changement ne devrait pas tarder.

Je vous montre ici comment réaliser une connexion VPN IPsec entre 2 Pare-feux DYNFI.
Le but étant de relier 2 LAN distants.

Un schéma pour commencer :

Le but étant de permettre au PC NAN-CLIENT_01 de pouvoir communiquer avec le PC PAR-CLIENT_01, ou avec n'importe quelle autre machine (dont l'AD) du réseau de la zone PAR.

Je passe sur la configuration de vos VMs DYNFI car l'assignation des interfaces et des adresses IP est la même sur OPNsense et PFsense.

Voici cependant ce que vous devez obtenir sur vos pare-feux : (je juxtapose les 2 VMs l'un à côté de l'autre)

Nous allons faire la configuration du VPN IPsec en parallèle sur les 2 pare-feux en même temps.

Depuis les PC clients de vos LAN (NAN-CLIENT_01 et PAR-CLIENT_01), connectez-vous à l'interface web du DYNFI respectif de chaque zone.
(https://10.0.2.1 et https://10.0.1.1).
-> Rendez-vous dans VPN, IPsec, Tunnel Settings

(à gauche, le pare-feu de la zone NAN)                            (à droite, le pare-feu de la zone PAR)

Nous voici dans le menu VPN IPsec, Tunnel Settings... Pour l'instant, il n'y rien.
Nous allons donc créer une Phase 1 (cliquez sur le + encadré !)

Remplissez les informations demandées.
Sur le DYNFI de la zone NAN (à gauche), nous allons pointer la passerelle du DYNFI de la zone PAR
Et réciproquement !
Puis, nous donnons une description stipulant le sens et la phase.

On descend un peu plus bas :
Arrive une étape importante : la clef partagée !
Le mot de passe que vous devez choisir doit être entré sur LES 2 PARE-FEUX. Il doit être identique ! (logique, c'est une clef PARTAGEE).
En ce qui concerne l'encryption de phase 1, laissez les réglages par défaut, ils sont satisfaisants (c'est en phase 2 qu'on va avoir des soucis avec DINFY)

Descendez à présent tout en bas et cliquez sur Save :

Nous voici revenu dans les Tunnel Settings.
Vous pouvez voir notre Phase 1 apparaître.
Inutile d'appliquer les changements maintenant.
Nous allons passer à la Phase 2.
Attention, là, ça diffère un peu de PFsense, il faut cliquer sur le + de notre phase 1 pour créer la phase 2.

On remplit les infos pour la Phase 2 :
Une description, ainsi que le réseau du LAN distant que l'on veut pouvoir joindre (attention au masque !)

C'est là que ça se corse. Attention aux algo d'encryption !!
Respectez ceux que j'indique sur la capture suivante, autrement vous allez avoir des problèmes !
AES 128 pour l'encryption et SHA256 pour le Hash.
Cliquez sur Save.

Appliquez les changements, cochez les cases enable, cliquez sur Save, voilà, votre connection s'active !

Vous pouvez regarder les logs (regardez les icônes plus haut) pour vous assurer que tout va bien, ou cliquez sur Status, Overview, pour vous assurer que votre connexion est bien active.

Dernière étape !!! Votre connection a beau être active, il vous manque des règles pour pouvoir communiquer avec les machines des LAN distants respectifs !!

Donc, on se rend dans Firewall, Rules, IPsec et on clique sur le petit + pour ajouter autant de règles que nécessaires !

Comme l'objectif de ce tuto n'est pas de définir des règles de flux précis, on autorise tout sans vergogne, histoire de tester !!!
(soyons fou !... Ce n'est qu'un labo ici)

Cliquez sur Save, puis appliquez les changements.

Voilà, vous pouvez désormais faire communiquer vos machines entre elles (de LAN à LAN)

Pour les besoins du labo, nous avons utilisé une IP privée (172.20.0.0/12) pour simuler l'internet.
Le fonctionnement reste cependant le même.

Un collaborateur souhaite, depuis chez lui, pouvoir accéder au site intranet de son entreprise hébergé sur un serveur web (SRV-WEB) dans le batîment.

Nous allons (en temps qu'administrateur, depuis le PC admin) configurer le pare-feu de l'entreprise (pfsense1) afin qu'il devienne un serveur OpenVPN, auquel le PC collaborateur pourra se connecter pour accéder au serveur SRV-WEB.

On considère que tous les OS sont déjà installés sur les différentes machines.
On ne s'occupe ici que du paramétrage.

I - Effectuer le paramétrage du pare-feu pfsense1 en lignes de commande:
- Assigner les cartes réseaux aux bonnes interfaces
- Assigner les IP aux interfaces.

Conformément au schéma, voici ce que vous devez obtenir, après avoir assigné les interfaces 1) et attribué l'IP pour chaque interface ainsi que la passerelle pour le WAN 2)

II - Effectuer le paramétrage du pare-feu box-SFR en lignes de commande : (pour ce labo, on monte un second pfsense)
- Assigner les cartes réseaux aux bonnes interfaces
- Assigner les IP aux interfaces.

Conformément au schéma, voici ce que vous devez obtenir, après avoir assigné les interfaces 1) et attribué l'IP pour chaque interface ainsi que la passerelle pour le WAN 2)

III - Effectuer la configuration réseau de chaque machine selon le schéma

- PC admin
- SRV-WEB
- PC collaborateur

Pour le PC collaborateur, ne pas oublier de faire un enregistrement DNS pour le site intranet auquel il souhaite pouvoir accéder.
Nous allons créer le site assistance.lan (GLPI).
Donc, dans le fichier hosts :
10.1.0.200 assistance.lan

Par défaut, PFSENSE laisse passer tous les paquets en provenance du LAN et à destination du WAN (comme la box SFR)
Donc même si ce n'est pas une vraie box SFR, le fonctionnement est le même. Il n'y a donc aucune règle à ajouter.

IV - Déployer le site intranet assistance.lan sur le SRV-WEB
Téléchagez le script de configuration global debian ou freebsd pour aller plus vite.
faîtes également un enregistrement DNS sur le PC admin pour pouvoir tester le bon fonctionnement et faire la première configuration de GLPI.

V - On passe à la configuration du serveur OpenVPN sur le pfsense1 de l'entreprise.
On se connecte depuis le PC admin à l'interface grahpique de pfsense via son URL : http://10.10.0.254

1) Créer l'authorité de certification (en fait, on prend directement celle de pfsense, pas besoin d'en créer une)
System -> Cert. Manager -> CAs -> + Add
 Descriptive Name : VPN-CA
 Method : Create an internal Certificate Authority
 Lifetime (days) : 1095 (3 ans)
 Country Code : FR
 State or Province : ce que vous voulez
 City :
 Organization : VOTRE ENTREPRISE
 Organizational Unit : IT  
 Save

2) Créer le certificat du Serveur OpenVPN
System -> Cert. Manager -> Certificates -> + Add/Sign
 Method : Create an internal Certificate
 Descriptive name : VPN-SERVER
 Certificate authority : VPN-CA
 Lifetime (days) : 1095 (3 ans)
 Common Name : VPN.domaine (s'il y a un domaine.. genre TSSR.INFO -> VPN.TSSR.INFO)  
 Country Code : FR
 State or Province : ce que vous voulez
 City :
 Organization : VOTRE ENTREPRISE
 Organizational Unit : IT
 Certificate Type : Server Certificate  
 Alternative Names : FQDN or Hostname : VPN.domaine
 Save

3) Si vous voulez créer un certificat spécifique à un utilisateur, faîtes cette étape 3), sinon, pour créer un certificat pour tous les utilisateurs, répétez l'étape 2), donnez le Descriptive Name : VPN-CLIENT et changez le Certificate Type pour User Certificate. 

System -> User Manager -> Users -> + Add
 Username : micheline
 Password : P@ssw0rd  (NE PAS DEPASSER 15 CARACTERES... SINON PROBLEMES SUR DES CLIENTS          BSD SI VOUS CHOISISSEZ UNE AUTHENTIFICATION SSL/TLS/USER AUTH LORS DE LA CREATION            DU SERVEUR !!!)
 Certificate : Click to create a user certificate
 Descriptive name : VPN-MICHELINE
 Lifetime : 1095
 Save

4) Créez le serveur OpenVPN
VPN -> OpenVPN -> Servers
 Server mode : Remote Access (SSL/TLS) -> Permet de ne pas avoir à rentrer d'identifiant et de mot de passe           sur le client au moment de la connexion au VPN
 Device mode : tun - Layer 3 Tunnel Mode
 Protocol : UDP on IPv4 only (par exemple)
 Interface : WAN
 Local port : 1194
 Description : SERVEUR-OPENVPN
 TLS Configuration : Use a TLK Key  
 Peer Certificate Authority : VPN-CA  
 Server certificate : VPN-SERVER (Server: Yes, CA: VPN-CA, In Use)  
 DH Parameter Length : 2048 bit  
 Data Encryption Negotiation : Enable Data Encryption Negotiation  
 Data Encryption Algorithms : enlever l'AES-128 de la colonne de droite en cliquant dessus  
 Fallback Data Encryption Algorithm : AES-256-CBC (256 bit key, 128 bit block) 
 Auth digest algorithm : SHA-256 (256-bit)  
 Certificate Depth : Two (Client+Intermediate+Server)  
 Client Certificate Key Usage Validation : Enforce key usage  
 IPv4 Tunnel Network : 10.199.199.0/24 (ou une adresse de classe APIPA 169.254.0.0/16)  
 Redirect IPv4 Gateway : Force all client-generated IPv4 traffic trough the tunnel (dans le cas où vous souhaitez          que toutes les requêtes web du client passent par le tunnel.. Attention aux règles de pare-feu OpenVPN qui          suivront !! Dans le cas présent, on ne l'active pas, puisqu'on ne va autoriser la connexion QUE vers le SRV-          WEB)  
 IPv4 Local network(s) : 10.1.0.0/24  
 Concurrent connections : 20 (tout dépend du nombre de personnes qui se conecteront au serveur openvpn)  Dynamic IP : A vous de voir si vos clients sont en IP fixes ou dynamiques...
 Topology : net30 --Isolated /30 network per client (si vous voulez isoler les clients.. attention, utilise 4 adresses            IP par connection ! -> /30)  
 Inactive : 0
 DNS Default Domain : cocher si vous avez un domaine (genre TSSR.INFO)  
 DNS Server enable : permettre au client d'utiliser le DNS de l'entreprise (indispensable dans le cas d'un active            directory). Rajoute une carte réseau virtuelle sur le client, permettant de renseigner le DNS du Serveur AD            de l'entreprise (où celui qui vous arrange !)  
 Block Outside DNS : pour clients windows 10  
 Force DNS cache update : forcer la mise à jour du cache DNS sur les clients windows  
 NTP Server enable : si l'entreprise est reliée à un serveur NTP particulier
 Save

6) Créer la règle côté WAN,               
permettant une connexion sur le port 1194
Firewall -> Rules -> WAN -> Add  
Protocol : UDP  
Source : any  
Destination Port Range : From 1194 To 1194  
Description : OpenVPN-access  
Save  

Apply Change

Firewall -> Rules -> OpenVPN -> Add (créer les règles souhaitées.. interdire l'accès à l'AD etc..)  
Pour l'exemple, on va uniquement autoriser la connexion vers le SRV-WEB  
Protocol TCP  
Source Network : 10.199.199.0 /24  
Destination : Single host or alias : 10.1.0.200 (IP de SRV-WEB)  
Destination : From 80 to 80  
Description : SRV-WEB_access  
Save  

Apply Change

Dernier point à modifier : dans notre cas de figure, le WAN est un réseau d'IP privé..
Or, par défaut, PFSENSE bloque les IP provenant des réseaux privés à son entrée WAN.

Firewall -> Rules -> WAN : RFC1918
Ouvrez la règle par défaut concernant l'interdiction des réseaux privés d'accéder par la WAN (RFC1918)
Allez décocher les 2 options tout en bas de la règle, enregistrez, et appliquez les changements.

7) Installer le module openvpn-client-export
System -> Package Manager -> Available Packages -> Search term : openvpn -> Search
installez openvpn-client-export

8) Exportez la configuration pour l'utilisateur Micheline (ou celui pour tout le monde)
VPN -> OpenVPN -> Client Export ->  Remote Access
Server : SERVEUR-OPENVPN UDP4:1194  
Additional configuration options : auth-nocache  
Save as default  (descendre plus bas)  
VPN-CLIENT-MICHELINE  
- Pour un client sur Windows : Current Windows Installers  
     Télécharger la version windows qui correspond au poste client  
- Pour un client sur Linux/FreeBSD : Inline Configurations  
     Télécharger 'Most Clients' qui contient la totalité du fichier de configuration du client.

9) Transférez ce fichier sur le client. Pour un client sur FreeBSD, le script de configuration général permet de configurer le client automatiquement.          

On veut relier les 2 LAN (site 1 et site 2) grâce aux pare-feux pfsense

Le labo peut être réalisé sur VirtualBox ou VMWare.
2 clients à paramétrer en réseau interne (chacun dans un réseau interne nommé différemment)
2 pfsense à paramétrer (2 interfaces par pare-feu.. Une pour le LAN (sur le réseau interne du client), la seconde pour le WAN, par pont).

Pour les pare-feux : relever le numéro des cartes MAC pour faire l'assignation des interfaces
Puis assigner les IP correspondantes.

Voici l'exemple de configuration du pfsense1 :

Voici l'exemple de la configuration du pfsense2 :

Pour configurer le VPN IPsec :
Accéder à l'interface web des pare-feux via les clients (avec l'URL de la passerelle correspondante au pare-feu..
Pour le client1 : http://10.1.0.254, Pour le client2 : http://10.2.0.254)

La configuration doit être faîte de manière identique SUR LES 2 PARE-FEUX 

Sur le pfsense1 :

Indiquer la description comme suit et entrez la passerelle WAN du pfsense2 dans "Remote Gateway"

Créez une clef partagée, ET NOTEZ-LA !! Il faudra la rentrer dans le configuration du VPN IPsec de pfsense2

Laissez tout le reste par défaut, et cliquez sur "Save" tout en bas

Entrez la description, et le réseau distant

Laissez tout par défaut, puis cliquez sur "Save" tout en bas

Appliquez les changements en cliquant sur "Apply Changes"

La configuration du pfsense1 est terminée.

Pour configurer le pfsense2, suivez exactement les mêmes étapes, mais changez la Remote Gateway pour indiquer la passerelle WAN du pfsense1. N'oubliez pas d'indiquer EXACTEMENT la même clef partagée (souvenez-vous-de-cette-clef).
Enfin, lors de la création de P2, indiquez le réseau du site 1 dans Remote Network (10.1.0.0/24).

Une fois la configuration du pfsense2 terminée, pour activer la connexion VPN IPsec, vous devez faire ce qui suit sur chacun des 2 pfsense :

 Une fois que vous avez activé la connexion sur chacun des pare-feux, la connection est établie :
Ci-dessous, vous pouvez apercevoir les 2 pfsense :

Si vous souhaitez pouvoir PINGuer le client2 depuis le client1, vous devez ajouter une règle :

Installer Shorewall

loguez-vous en root
apt install shorewall -y

Nous devons à présent configurer 3 fichiers :

1) d'abord les zones que l'on va utiliser dans les règles :
echo "net ipv4" >> /etc/shorewall/zones
echo "fw firewall" >> /etc/shorewall/zones

2) la carte réseau qui sera connectée à l'interface internet (évidemment, changez le nom de votre interface si ce n'est pas eth0)
echo "net eth0 detect" >> /etc/shorewall/interfaces

3) les règles de pare-feu des zones :
echo "fw net ACCEPT" >> /etc/shorewall/policy
echo "net all DROP info" >> /etc/shorewall/policy
echo "all all REJECT info" >> /etc/shorewall/policy

4) Configurer les règles de pare-feu :
echo "ACCEPT all fw tcp 80" >> /etc/shorewall/rules
echo "ACCEPT all fw tcp 443" >> /etc/shorewall/rules
echo "ACCEPT all fw tcp 22" >> /etc/shorewall/rules

5) Démarrer le pare-feu
systemctl start shorewall
systemctl enable shorewall

passer en root

Voir toutes les règles
iptables -L

Pour DROPer le port 55555 en entrée
iptables -A INPUT -p tcp --dport 55555 -j DROP

Example de script
vi redir.sh
#!/bin/bash
# tout ce qui ira à destination du port 23456 sera rerouté vers 10.0.1.8 sur le port 44444

sudo iptables -t nat -A PREROUTING -p tcp --dport 23456 -j DNAT --to-destination 10.0.1.8:44444
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

L'ISO peut se télécharger ici :

https://opnsense.org/download/ 

Si vous testez avec un hyperviseur, n'oubliez pas d'activer plusieurs interfaces (au moins 2, une pour le WAN, l'autre pour le LAN) AVANT de procéder à l'installation d'OPENsense..

Rappel des identifiants de base :
Sur OpenSense, on boot directement sur un environnement LIVE.
Pour installer OpenSense, il faut utiliser les identifiants suivants lorsque vient le moment de s'authentifier.

Login : installer
Password : opnsense

Vous arrivez alors sur l'installeur.
Choisissez le système de fichiers ZFS, beaucoup plus robuste et moderne.

Une fois l'installation terminée, retirez l'ISO au moment du redémarrage.

Cette fois-ci, identifiez-vous en root/opnsense et procéder comme sur pfsense :

1) On assigne les Interfaces 

2) On paramètre les adresses IP sur ces interfaces (au moins pour la LAN.. sinon, impossible d'accéder à l'interface GUI via un navigateur). Si l'installation se fait sur un hyperviseur, il faut donc une seconde VM (dans le LAN) pour pouvoir accéder à l'interface GUI.

3) On s'occupe du reste de la config via l'interface GUI, en se connectant à l'IP (passerelle) d'openSENSE (du LAN)

Rappel des identifiants de base pour l'interface GUI (via le navigateur) :
root/opnsense

Le paramétrage n'est pas bien différent de pfsense sur l'interface !

----Configuration d’interface (LAN et WAN et VLAN),
----Création de zones,
----Création d’un routeur virtuel,
----Paramétrage d’un NAT (VLAN to WAN address)
----Règle de pare-feu internet (http, https, dns)

1 – Topologie

2 – Etapes de configuration :

• Créer l'interface vers le Routeur

             
                                          Configurer l’interface ethernet 1/1 (layer 3, IP 172.25.79.199)

•          Créer les zones WAN et LAN

                                          Créer la zone WAN (layer 3, int. ethernet1/1)

                                          Créer la zone LAN (layer 3, int. ethernet1/2)

• Créer les interfaces pour les VLAN
  
                                 Créer l’interface LAN

                                          Ajout d’une première sous-interface (VLAN 20)

                                          Ajout d’une seconde sous-interface (VLAN 30), en suivant le modèle précédent.
                                          L’onglet « Advanced » permet d’ajouter le Ping.

• Créer le routeur virtuel

                                         
                                         Créer le routeur virtuel VR1

                                          Créer la route statique par défaut pour internet 

• Configurer DHCP sur les VLANS :

                                         Création d’un pool d’adresse pour le VLAN 20 :

                                         Suivre la même procédure pour la création du pool d’adresses pour VLAN 30.

• NAT

                                          NATer le VLAN20 sur la WAN address.

•   Security

                                          Créer la règle VLAN20-to-Internet, avec http, https et DNS

                                          Pour l’autorisation de DNS, nous utilisons une application plutôt qu’un service

                                         Configuration des règles pour http et https

La création d'un alias de règles va permettre, par exemple ici, de pouvoir configurer

une règle de pare-feu d'accès à internet (HTTP,HTTPS,DNS) en une seule règle, via la création d'un alias regroupant ces

3 ports

Lire la suite...

Onglet Local cache :

Onglet General :

Navigateur internet d'un client :

retour sur Squid dans pfsense, onglet ACLs :

Onglet RealTime :

Onglet Antivirus :

Autre règle de redirection DNAT pour accès SSH :