VPN IPSEC - pfsense-to-pfsense - net-to-net

to0ks

Bonjour,

Voici le problème rencontré sur notre configuration pour l'interconnexion de 2 Pfsense en VPN IPsec à travers internet.

Le schéma:

Les deux Freebox FREE1 et FREE2 sont configurée en mode routeur.
Avec une redirection des ports UDP 500 et 4500 vers les interface WAN de chaques Pfsense "PF1" et "PF2".

Voici la configuration VPN IPSEC de chaque Pfsense "PF1" et "PF2" :

–----------------------------------------------------------------

Box PF1:

Interface: WAN
Local subnet: LAN subnet
Remote subnet: 192.168.82.0 / 24
Remote gateway: {public IP Box PF2 87.x.x.x}

Box PF1 Phase1:

Negotation mode: aggressive
My identifier: My IP address
Encryption algorithm: Blowfish
Hash algorithm: SHA1
DH key group: 2 (1024 bit)
Lifetime: 28800
Authentication method: pre-shared key
Pre-Shared key: xxxxxxx

Box PF1 Phase2:

Protocol: ESP
Encryption algorithm: Blowfish
Hash algorithm: SHA1
PFS key group: 2 (1024 bit)
Lifetime: 86400

–----------------------------------------------------------------

Box PF2:

Interface: WAN
Local subnet: LAN subnet
Remote subnet: 10.10.87.0 / 24
Remote gateway: {public IP Box PF1 82.x.x.x}

Box PF2 Phase1:

Negotation mode: aggressive
My identifier: My IP address
Encryption algorithm: Blowfish
Hash algorithm: SHA1
DH key group: 2 (1024 bit)
Lifetime: 28800
Authentication method: pre-shared key
Pre-Shared key: xxxxxxx

Box PF2 Phase2:

Protocol: ESP
Encryption algorithm: Blowfish
Hash algorithm: SHA1
PFS key group: 2 (1024 bit)
Lifetime: 86400

–----------------------------------------------------------------

Sur chaque Pfsense "PF1" et "PF2"
Lorsqu'on coche "Enable IPsec" la connexion s'établie.

Dans "Status IPsec" le tunnel est bien activé avec le status au vert.
Dans "Status IPsec" l'onglet SAD affiche bien les informations avec les sources / destinations / Protocol / SPI etc ….
Dans "Status IPsec" l'onglet SPD affiche correctement les routes des sous réseaux.

Sur chaque Pfsense "PF1" et "PF2"

Sur "PF1"
Dans Firewall -> Rules -> IPSEC
Proto Source Port Destination Port Gateway
* 10.10.87.0/24 * * * *

Sur "PF2"
Dans Firewall -> Rules -> IPSEC
Proto Source Port Destination Port Gateway
* 10.10.82.0/24 * * * *

Après toute la configuration :

Depuis PF1 « ping WAN et LAN de PF2 » ne ping pas.
Depuis PF2 « ping WAN et LAN de PF1 » ne ping pas.
Depuis le poste CLIENT1 « ping vers CLIENT2 LAN » ne ping pas.
Depuis le poste CLIENT2 « ping vers CLIENT1 LAN » ne ping pas.
Depuis le poste CLIENT1 « ping vers PF2 LAN et WAN » ne ping pas.
Depuis le poste CLIENT2 « ping vers PF1 LAN et WAN » ne ping pas.

Une solution ?

Merci de vos réponses et de votre aide.

Juve

mettre les deux freebox en mode routeur afin que chaque pfsense porte L'IP publique sur son intrrface WAN. rediriger l'udp ne suffit pas (ca ne sert que pour l echange des cles et des messages de controle).il faut aussi rediriger les protocoles AH et ESP, hors free ne le permet pas.

to0ks

@Juve:

mettre les deux freebox en mode routeur afin que chaque pfsense porte L'IP publique sur son intrrface WAN. rediriger l'udp ne suffit pas (ca ne sert que pour l echange des cles et des messages de controle).il faut aussi rediriger les protocoles AH et ESP, hors free ne le permet pas.

Tu veux dire mettre les deux Freebox en mode Bridge afin que chaque interface WAN des Pfsense porte l'IP publique de free ?

D'après mes recherches :

Le protocole AH est conçu pour assurer l'intégrité en mode non connecté et l'authentification de l'origine des datagrammes IP sans chiffrement des données (pas de confidentialité).
Le protocole ESP peut assurer, au choix, un ou plusieurs des services suivants :
* confidentialité des données et protection partielle contre l'analyse du trafic si l'on utilise le mode tunnel.
* intégrité des données en mode non connecté et authentification de l'origine des données, protection partielle contre le rejeu.

Donc selon toi, il faut rediriger ces deux protocoles et la Freebox ne permet que la redirection les protocoles TCP et UDP.
A tu une référence de routeur qui puisse gérer la redirection de ces Ports est ainsi pouvoir utiliser l'IPsec ?

Dois-je comprendre que pour créer un tunnel VPN avec deux Freebox qui font du NAT les solutions qu'il me reste sont : OpenVpn et PPTP ?

Merci d'avance.

ccnet

J'anticipe les réponses de Juve que je laisse profiter de ces vacances. Oui pour les deux questions.

to0ks

Malgrés le fait que le NAT doit être évité avec IPsec car il cause le changement des datagrammes.

J'ai vu qu'il existé une solution qui est le NAT-Traversal.
Quels sont les solutions offertes par Pfsense concernant "IPsec & NAT-Traversal" ?
Cette solution permet d’encapsuler l’ESP ou l’AH dans un paquet UDP pour la faire transiter au travers d'un équipements de NAT.

Voici un extrait des informations que j'ai trouvés pour palié au problème du NAT: (un avis ?)

Problème de NAT, de fragmentation et de delai de connexion

NAT

Si le client se trouve derrière une passerelle assurant le NAT tel que c'est souvent le cas lorsque l'on a un réseau local et une passerelle pour accéder au net, vous ne pourrez pas utiliser IPSec directement. En effet, les paquets sont encapsulé dans des paquets ESP (au dessus de IP) qui par définition ne possède pas de port est sont donc très difficile à NATer. Dans ce cas, on utilisera NATT afin d'encapsuler les paquets ESP dans des paquets UDP pour passer les passerelles.

Pour ce faire,dans le fichier /etc/racoon/racoon.conf, dans la section remote, on mettre nat_traversal on;

De plus, il peut arriver que l'échange IKE ne se fasse pas si le port UDP du NAT change du fait de la faible persistance des associations de NAT dans les passerelles. Il peut donc être utile de faire des envoie de paquets « vide » pour faire persister l'association NAT sur la passerelle traversée.

Pour ce faire, on ajoutera ceci dans le fichier /etc/racoon/racoon.conf :

**timer {

natt_keepalive 5sec; #10 seconde maxi

}**

Fragmentation

La fragmention intervient lorsque l'on utilise, par exemple, une liaision DSL qui suppose par défaut que les paquets UDP ne sont pas de grande taille. La fragmentation va donc arriver plus fréquemment dans un IPSec NATé.

Il y a deux types de fragmentation possible pour IPSec :

la fragmentation des paquets IKE lors de l'établissement des clés IPSec. On peut choisir la fragmentation IKE qui est une extension de ce protocole
la fragmentation des paquets ESP lors des communications. Dans ce cas, il faut simplement fragmenter les paquets IP encapsuler dans ESP pour faire des paquets UDP/ESP de plus petite taille.

Dans le fichier /etc/racoon/racoon.conf, dans la section remote, on mettra ike_frag on;

Delai de connexion

Il peut arriver que la connexion entre le client et le serveur ne soit pas très fiable et donc que des déconnexions arrivent. Pour cela, on peut forcer le serveur IKE à renouveller les clés régulièrement.

Pour cela, dans le fichier /etc/racoon/racoon.conf, on ajoutera dans la section remote, dpd_delay 20;

Juve

pfsense 1.2.3 suporte le NAT-T mais la n'est la question, NAT-T devrait être supporté par la freebox puisque c'est elle qui NAT.
NAT-T n'est normalement pas utilisé en site-to-site mais en roadwarrior lorsque le client qui désire se connecter en IPSEC à un serveur est lui même derrière un routeur effectuant du NAT.
Dans votre cas le fait de changer le mode de fonctionnement de votre freebox en mode bridge solutionnera tous vos problèmes.

to0ks

La situation est maintenant très clair.
Merci pour vos explications Juve et Ccnet.

jdh

Je profite de ce fil très clair :

la question est posée de façon complète (on sent que c'est bien préparé),
la réponse est directe et simple.

L'alternative à un tunnel IPSEC est le tunnel OpenVPN (site-à-site). (cas de livebox non transformable en modem)

(J'exclu le tunnel PPTP largement obsolète et pas adapté à un site-à-site).

Qu'en est-il de l'affichage du statut du VPN (monté/tombé) ?
Qu'en est-il du maintien de la connexion ?
Qu'en est-il des fonctions de relance ?