Créer un tunnel VPN site à site (S2S) via OpenVPN sécurisé avec SSL/TLS (mode L2) sous pfSense 2.6

7. Vérifier le statut du tunnel OpenVPN

Pour vérifier le statut de votre tunnel OpenVPN L2, allez dans : Status -> OpenVPN.

Si OpenVPN est configuré correctement sur les 2 sites et que le pare-feu est configuré correctement des 2 côtés, le statut côté serveur (Peer to Peer Server Instance Statistics) sera "Up".

Idem, côté client (Client Instance Statistics).

Note : il est normal qu'il n'y ait pas d'adresse IP virtuelle dans le cas d'un tunnel VPN en couche 2 étant donné qu'OpenVPN n'utilise pas de sous-réseau dans son tunnel en mode "TAP" (L2).

8. Consultez les journaux (logs) pour OpenVPN

En cas de problème avec le tunnel OpenVPN, vous pouvez consulter ses journaux (logs) via le menu "Status -> System Logs" ou en cliquant sur l'avant-dernière icône rouge (en haut à droite) sur la page de statut d'OpenVPN.

Allez dans l'onglet "OpenVPN" et triez la liste par date / heure en cliquant sur "Time".

La méthode est la même sur l'autre site (peu importe qu'il s'agisse d'un serveur OpenVPN ou d'un client OpenVPN).

9. Test du ping via le tunnel OpenVPN

Pour tester si le tunnel OpenVPN fonctionne, commencez par pinger l'adresse IP LAN du site local, puis celle du site distant.

Dans notre cas, sur notre PC "brux-win10-pc" du site 1 (Bruxelles), nous tentons de pinger l'adresse IP LAN :

• 10.0.0.1 : machine pfSense du site local (site 1 - Bruxelles).
• 10.0.0.2 : machine pfSense du site distant (site 2 - Paris).

Ensuite, depuis la machine "paris-win10-pc" du site 2 (Paris), nous tentons à nouveau de pinger ces adresses IP LAN.

Si cela fonctionne, cela montre que le tunnel OpenVPN fonctionne.

Pour aller plus loin, vous pouvez autoriser le ping (ICMP) pour le trafic entrant dans le pare-feu d'une machine Windows sur chaque site physique.

Ensuite, tentez de pinger en IPv4 (paramètre "-4") une machine du site 2 (Paris) depuis une machine du site 1 (Bruxelles).

Batch

ping -4 paris-win10-pc

Pareil dans l'autre sens.

Batch

ping -4 brux-win10-pc

Si cela fonctionne, c'est que le tunnel OpenVPN fonctionne correctement en mode site à site et comme vous pouvez le voir, le même sous-réseau "10.x.x.x" est utilisé sur les 2 sites physiques.

10. Trafic DHCP bloqué par défaut

Pour le moment, notre machine Windows du site 2 (Paris) possède une adresse IP qui avait été reçue depuis le serveur DHCP du site 2 (Paris) où cette machine se trouve.

Note : dans notre cas, l'adresse IP "10.0.0.2" correspond à l'adresse IP LAN de la machine pfSense du site 2 (Paris).

Notez que vous pouvez aussi voir ceci en utilisant la commande "ipconfig" depuis un invite de commandes.

Attention : étant donné que le trafic DHCP est bloqué par défaut par le pare-feu de pfSense pour les machines ne possédant par encore d'adresse IP, si vous réinitialiser la carte réseau, puis que vous redemander une nouvelle adresse IP, cela ne fonctionnera pas.
De plus, cette machine n'aura plus accès à l'interface web de pfSense étant donné qu'elle ne possède plus d'adresse IP. La seule solution temporaire étant de définir une adresse IP statique sur celle-ci temporairement ou d'utiliser une autre machine du réseau pour accéder à l'interface web de pfSense.

Batch

ipconfig /release
ipconfig /renew

Plain Text

Une erreur s'est produite lors du renouvellement de l'interface Ethernet0 :
Impossible de contacter votre serveur DHCP.
Le délai d'attente de la demande a expiré.

Dans l'interface graphique de Windows, vous verrez le statut "Réseau non identifié" apparaitre pour votre carte réseau.

L'adresse IPv4 utilisée sera "169.254.xx.xx". Ce qui indique que votre machine n'a pas reçu d'adresse IP depuis le serveur DHCP du réseau.

Pour comprendre pourquoi le trafic DHCP ne passe pas, il suffit d'aller sur la machine pfSense du site 2 (Paris) où le client OpenVPN est installé.
Allez dans le menu : Status -> System Logs.

Dans l'onglet "Firewall", triez la liste par date / heure en cliquant sur "Time" et vous verrez que le trafic DHCP est bloqué par la règle de blocage par défaut des interfaces LAN et bridge0 (le pont réseau).

Plain Text

LAN / Default deny rule IPv4 (1000000103) / 0.0.0.0:68 / 255.255.255.255:67 / UDP
bridge0 / Default deny rule IPv4 (1000000103) / 0.0.0.0:68 / 255.255.255.255:67 / UDP

Pour informations :

• le serveur DHCP écoute sur le port 67 UDP.
• le client DHCP utilise le port 68 UDP.
• lorsqu'une machine ne possède pas encore d'adresse IP, elle envoit sa demande DHCP à l'adresse de broadcast (255.255.255.255).

Sources :

• Dynamic Host Configuration Protocol - Wikipédia
• Bridging Two Internal Networks - DHCP and Internal Bridges | pfSense Documentation