Provya

@Guillaume :
bonjour,
merci pour les réponses. Au fait ma préoccupation réside dans la gestion de deux routes. Je dispose d'un route pour accéder à deux sites différents. Pour raison de sécurité nous avons décider de créer une deuxième route en par tunnel Ipsec entre deux pfsenses situés sur des sites différents.
Dans mon réseau, pour accéder a mon serveur, je dois forcement passé par un routeur cisco quelque soit le route emprunté.
Alors chaque fois que je suppose passer par la voie secondaire créée pour atteindre mon serveur, les paqués sont bloqués au niveau du routeur car j'ai déjà désactivé la première route. Mais si je l'active cela passe. Donc je voudrai savoir si je peux faire du NAT pour habiller les paquets afin d'obligé les paquets a prendre par mon tunnel.

@Deen :

Bonjour,

Je ne comprends pas très bien ce que vous voulez faire.

Si vous voulez gérer une route primaire et une route secondaire entre deux sites afin d'avoir de la haute-disponibilité, la solution réside probablement dans la configuration d'un protocole de routage.

Si vous souhaitez configurer un tunnel IPsec dans un environnement haute-disponibilité (deux pfSense, l'un actif, l'autre passif), la solution est de configurer le tunnel IPsec sur votre adresse VIP et non sur l'interface WAN.

Cordialement,

Guillaume
--
Provya

J'ai un problème qui me tournante. Au fait j'ai deux routes une principale et la deuxième secondaire. La deuxième serait établie par un fail over sur 2 pfsense a partir d'un tunnel IPSEC lorsque la principale est défaillante.
J'ai réussite à faire les configurations mais j'ai de difficulté.
Si je mets la route principale up et secondaire down, tout ce passe bien.
Si je mets la route principale up et secondaire up,avec route secondaire comme niveau 1. Les paquets passent dans le tunnel , dans le pfsense et le retour se fait pas la route principale( ce que je ne veux pas).
Si je mets la route principale down et secondaire up, les paquets passent dans le tunnel et
dans le pfsense du basculement mais n'arrive pas a atteindre l'équipement terminal. Donc plus de retour. Les paquets sont donc perdus.
Quelqu'un a une piste de solution?

bonjour!

@Guillaume : Ok je saisis mieux le concept !

J'avais cru comprendre que dans le schéma, le NAT LAN était lié à une application d'inbound rule et que le NAT WAN était lié à une application d'outbound rule.

Mais pas du tout, dans les deux cas c'est d'abord une inbound rule puis une outbond rule.

Merci c'est clair maintenant

@Pablo :
Bonjour Pablo,

Non, l'ordre de lecture des règles de NAT ne change pas entre un flux LAN > WAN et un flux WAN > LAN.

Si vous reprenez le schéma présent au début de notre article, le DNAT est effectué à l'étape 2 ("NAT LAN") pour un flux LAN > WAN ; ce qui correspond à l'étape "NAT WAN" pour un flux WAN > LAN.

Le SNAT, quant à lui, est effectué à l'étape 4 ("NAT WAN") pour un flux LAN > WAN ; ce qui correspond à l'étape "NAT LAN" pour un flux WAN > LAN.

Cordialement,

Guillaume
--
Provya

Bonjour Guillaume,

Je comprend pas pourquoi l'ordre de lecture des règles de NAT change entre un flux allant du WAN vers le LAN (SNAT > DNAT) et flux allant du LAN vers le WAN (DNAT > SNAT).

Il y a une raison particulière au niveau réseau ?

@cedric :

Bonjour Cédric,

Il faut vérifier que votre serveur OpenVPN soit bien en écoute sur son interface WAN et qu'une règle de filtrage a bien été mise en place afin d'autoriser le trafic entrant sur le port 1194.

Si vous avez une BOX Internet en amont, il faut vous assurer également que le port 1194 soit bien redirigé vers votre serveur OpenVPN.

Cordialement,

Guillaume
--
Provya

Bonjour
tout d'abord merci pour votre tutoriel très explicite.
J'ai essayé de suivre votre tutoriel ainsi que d'autres, mais à chaque fois j'ai un problème.
Lorsque je souhaite monter mon vpn client ca me mets ça :
TLS ERROR : TLS key negociation failed to occur within 60 secondes (check your network connectivity)
TLS ERROR : TLS handshake failed
Merci d'avance

Bonjour,

La 2.5.0 était une cata, la 2.5.1 c'est encore pire... si netgate avait voulu saboter la version CE au profit de pfSense plus, il n'aurait pas fait mieux! Clairement on sent vraiment un changement d'attitude de leur part vis à vis de la version gratuite qui leur fait trop d'ombre... Un conseil, restez en 2.4.5p1 pour ceux qui n'ont pas encore fait l'upgrade, ou passez à autre chose si vous le pouvez...