@PascalB41 :
Bonjour Pascal,
Je vous confirme que pfSense Plus est basé sur un principe d'abonnement annuel.
Je vous confirme qu'il n'y a aucune urgence à migrer votre installation. pfSense CE continu d'être développé plutôt activement.
Concernant OPNsense, quelles améliorations attendez-vous ? OPNsense est parfaitement stable et bien plus efficace que pfSense sur beaucoup de sujets.
Cordialement,
Guillaume
--
Provya
@Michel B. :
Bonjour Michel,
Merci beaucoup pour la précision.
Cordialement,
Guillaume
--
Provya
Moi ce qui me gave dans cette histoire c'est qu'il y a 3 ans j'ai choisi pfSense CE pour remplacer mon Microsoft TMG suite à l'abandon pur et simple du produit par son éditeur.
Et cette info que j'ai découverte sur le forum Netgate l'an dernier est tombée au moment où j'avais pleinement fini d'installer pfSense CE. Aujourd'hui *toute* notre communication passe par pfSense CE. Internet et téléphonie. Alors il n'y a effectivement pas urgence à changer (ou pas) de produit, mais c'est pénible, j'ai l'impression de revivre l'abandon de TMG il y a des années de cela.
Le passage à une licence payante je n'ai rien contre sur le principe. Mais là on partira surement sur une charge financière récurrente, il faudra payer son abonnement comme pour Microsoft 365 ou Veeam. Les profits des éditeurs sont déjà bien plus élevés que dans l'industrie mais ça ne leur suffit pas, il va falloir passer à la caisse tous les ans.
Personnellement je vais attendre et voir comment la situation évoluera mais si OPNSense s'améliore je serai plus tenté par cette solution.
Bonjour Guillaume,
merci pour vos explications claires et précises sur le montage d'un VPN et les autres articles très intéressants.
Une petite précision qui pourrait aider certains :
pour effectuer un test de traffic au travers de votre VPN IPSEC, vous pouvez essayer de pinger le serveur pfsense distant mais attention ce ping doit être réalisé depuis une machine de votre réseau et pas depuis le pfsense local au risque de ne pas fonctionner.
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html
@noma :
Bonjour,
Si le paquet openvpn est présent dans les dépôts Debian, vous devriez pouvoir utiliser la commande suivante :
apt-get install openvpn
Les fichiers de configuration se trouveront dans le répertoire /etc/openvpn/
Autrement, vous pouvez jeter un œil au site web d'OpenVPN : https://openvpn.net/vpn-software-packages/.
Mais seules les version 10 et 11 de Debian sont prises en compte. Debian 7 est vraiment une vieille version de Debian.
Cordialement,
Guillaume
--
Provya
bonjour,
j’ai merci pour votre tutoriel mais un un petit souci: comment tester l’accès distant depuis un poste client Debian version-7 ? sur un poste client windows ça marche bien mais je ne sais pas installer le client openvpn sur les machines debian version-7.
j’ai énormément besoin de votre aide.
merci d’avance.
@Deen :
Bonjour,
Oui, la configuration de NAT sortant (Outbound NAT) peut être une solution dans votre cas.
Il y a un point de vigilance à avoir en tête : arrivés sur le site de destination, les paquets réseaux ne présenteront plus leur adresse IP source d'origine ; ainsi, si vous avez mis en place du filtrage en fonction des adresses IP sources, il faudra sûrement l'adapter.
Cordialement,
Guillaume
--
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?