Quelle belle et riche information 'ça ne fonctionne pas' ! Au moins c'est très clair pour tous les lecteurs ! Il y a une chose très facile à comprendre : pas d'informations = pas de réponse ! En fait vous ne souhaitez aucune aide ...

Effectivement, ce sont des questions basiques. Malgré les nombreuses tentatives hier, cela ne fonctionne toujours pas. J'ai bien essayé avec un plan d'adressage différent pour la box et le pfsense en paramétrant la box en : 192.168.206.1, la patte wan du pfsense en 192.168.206.2, la patte lan en 192.168.6.1, le pc relié au pfsense en 192.168.6.2. J'accédais bien à l'interface pfsense depuis le pc (même réseau) mais impossible d'accéder depuis le pc à internet. impossible de pinguer un dns google depuis le pc et depuis le pfsense (diagnostics). Lorsqu'on paramétre l'interface wan du pfsense, il est possible de lui affecter une passerelle ? Est ce nécessaire et dans ce cas déclarer dans routage-->passerelle une passerelle avec l'ip 192.168.206.1 (la box) ? J'ai donc bien deux plans d'adressage différents dans ce cas ? D'avance je vous remercie pour vos retours. Merci pour votre lien, je vais me plonger dedans pour quelques révisions basiques. MAJ : je viens de refaire des tests sur un autre site et cela fonctionne. Je vais donc appliquer la même configuration et retester.

Hello @Kawick D'après l'image que vous avez envoyée, il n'y a pas de tunnel IPsec entre Londres et Madrid. A part ça, pour que les machines du réseau 172.16.49.0/24 puissent communiquer avec celles du réseau 172.16.39.0/24, vous devez configurer le routage sur les routeurs de Lisbonne et de Madrid. Sinon, vous devez impérativement configurer une nouvelle phase 2 sur les pfSense de Madrid, Londres et Lisbonne. La phase 2 actuelle ne concerne que les sites X vers Londres. La nouvelle phase 2 doit: Définir es réseaux sources et destinations qui seront autorisés à communiquer via le tunnel IPsec. Ici, les sélecteurs de trafic doivent autoriser le trafic entre 172.16.49.0/24 et 172.16.39.0/24 Choisissez les protocoles de sécurité (IKEv1 ou IKEv2) et les algorithmes de cryptage et d'authentification à utiliser pour sécuriser le tunnel. à tester et voir si ca marche ou pas.. bonne chance!

Merci @Pandora88 pour toutes ces infos ! J'ai laissé un peu de côté le reverse proxy avec HAproxy et Squid pour l'instant et je me concentre sur Nginx Proxy Manager. @Pandora88 said in Interface WAN connectée à un vpn wireguard: Pour ce qui est de la gestion des certificats SSL, le proxy NGINX est capable de porter le certificat pour chiffrer la connexion de bout en bout. Lors de la première connexion, mettre à jour obligatoirement les identifiants de l’admin. Après cela, vous pouvez vous accéderez au tableau de bord principal à partir duquel vous pourrez configurer vos hôtes proxy. Il est conseiller d'utiliser Docker et docker-compose pour déployer NPM, ce qui pourrait simplifier la gestion et la configuration. J'ai bien fait tout ça sur mon container qui héberge NPM. Je vais continuer ma découverte au fur à mesure des services que je vais déployer dans mon LAN Je m'y suis pas encore attaqué mais j'aimerais essayer de créer un tunnel VPN pour accéder à mon LAN et faire du cache sur NPM. Je suis preneur d'infos si quelqu'un en a ?

@Denis-2 Merci pour ton retour (y)

Hello J'ai fais quelques recherches, et voici ce que j'ai trouvé. Normalement, la config de l’adresse IP de la carte WAN dépend de la façon dont votre réseau est configuré. Habituellement, la carte WAN est configurée pour recevoir une adresse IP automatiquement en DHCP, mais dans votre cas, comme vous avez un routeur/VPN (Express VPN) en amont, vous devrez configurer une adresse IP statique sur la carte WAN qui est dans le même sous réseau que votre routeur/VPN Ce que vous pouvez tester : Adresse IP WAN : Vous pouvez choisir une adresse IP libre dans le même sous-réseau que votre routeur/VPN. Par exemple, si votre routeur/VPN a l’adresse IP 10.184.16.2, vous pouvez choisir une adresse IP comme 10.184.16.3 pour la carte WAN de votre pfSense. Masque de sous-réseau : Cela dépend de la taille de votre sous-réseau. Si vous utilisez un sous-réseau classique /24, le masque de sous-réseau serait 255.255.255.0. Passerelle : C’est généralement l’adresse IP de votre routeur/VPN, dans votre cas, 10.184.16.2. Serveurs DNS : Vous pouvez utiliser les serveurs DNS de votre choix. Certains utilisent les serveurs DNS publics de Google (8.8.8.8 et 8.8.4.4), d’autres préfèrent utiliser ceux de leur fournisseur d’accès à Internet. N’oubliez pas de sauvegarder vos paramètres et de redémarrer pfSense pour que les changements prennent effet.

Problème réglé en ajustant le firewall, le LAN serveur accède bien au LAN client. Il me reste un souci, j'avait une règle NAT pour rediriger un port spécifique depuis le WAN serveur vers une IP client. Cette règle fonctionnait en Site to Site Shared Key mais je ne parviens pas à la faire fonctionner sur le VPN TLS/SSL. [image: 1710152632512-capture-d-x27-%C3%A9cran-2024-03-11-112308.png] Qu'est ce que le passage en TLS/SSL peut avoir à voir avec cela? Des Idées?

@Bob60 Bonjour à tous, Pour ceux qui cherche la solution pour le problème d'OpenVPN décrit ci-dessus, j'ai eu la solution sur ce forum, partie anglophone ;-) Il suffisait de rajouter une CSO (réécriture spécifique au client) en complément de la configuration du serveur. https://forum.netgate.com/topic/186219/site-to-site-openvpn-routing-issue En espérant que cela puisse servir, Robert

@seb-nevers Pourquoi avoir cocher "Gateway duplicates" ? Pour cette situation avec un triangle de 3 sites ce n'est pas une obligation. Je ferais bien un test sans cette option qui déclenche 2 connexions en phase 1 entre les deux sites (les 2 connexions au statut "Connecting"). Si le soucis n'est pas là, il faut aller regarder dans les logs du service IPSec pour trouver ce qui retourne une erreur.

@seb-nevers Bonjour, nous sommes une petite structure avec environ 3000 étudiants et 300 personnels. Nous avons des Netgate/pfSense en HA avec des sites à sites en OpenVPN et IPSec, plusieurs dizaines de VLAN, une centaine de connexions VPN pour le télétravail, le FreeRADIUS, le serveur DHCP. Nous n'utilisons pas SquidGuard mais le package pfSense pfBlocker DNSBL à la place, qui récupère aussi les fichiers de blacklist. Tous les logs du firewall sont envoyés sur un serveur de log en cas de perquisition. Pour le portail captif, l'authentification passe par OpenLDAP mais de l'AD fonctionnerait aussi. Pour la formation, si vous êtes en Europe, je pense que Provya ou Viatitude devraient pouvoir vous proposer cela, mais avec un compte CPF, je ne sais pas. Pour la partie hardware, nous avons des Netgate 7100 HA mais nous allons passer à du serveur Dell plus puissant car avec notre population, les 7100 sont un peu légers au niveau CPU. Nous utilisons pfSense depuis 2009 et ça a toujours fait le travail. Le TAC est au top, très réactif. La version de pfSense que nous utilisons est la pfSense Plus. Bonne journée.

@Tueurdragon Avec des interfaces en 10G, il est grand temps de passer à un firewall physique et non virtuel. Je ne vois aucun intérêt à disposer d'un firewall avec 256G de disque ... Je vous informe qu'en virtualisant, il y a forcément des problèmes réseau du fait de la virtualisation et de problèmes de drivers notamment avec un gros trafic. D'où la nécessité d'aller à un firewall physique (avec des interfaces réseau bien reconnues par BSD ...).

Mes excuses. j'ai manqué de préciser qu'au niveau des sous réseaux des VLANs que c'était aussi du 192.168 (ça tombait sous le sens pour moi vu que j'avais dit que le LAN était 192.168.33.0/24 donc je n'ai pas pas pris le temps de réécrire 192.168 devant) Je reprends. Réseau LAN: 192.168.33.0/24. Gateway: 192.168.33.110 (addresse du pfsense) DHCP et DNS un windows server en 192.168.33.210 Réseau VLAN 45: 192.168.200.0/24 (réseau mis en place pour tests) Gateway : 192.168.200.1 (Ip du pfsense) DHCP range (192.168.200.10-192.168.200.20) DNS: 192.168.200.1 (Le pfsense) Réseau VLAN 180: 192.168.35.0/24 (Réseau de téléphonie) Gateway : 192.168.35.1 (Ip du pfsense) DHCP range (192.168.35.10-192.168.35.230) DNS: 192.168.35.1 (Le pfsense) Réseau VLAN 170: 192.168.192.0/24 (Sert à un seul équipement et sort via une IP publique différente des autres réseaux) Gateway : 192.168.192.254 (Ip du pfsense) DHCP range (192.168.192.10-192.168.192.20) DNS: 192.168.200.1 (le pfsense) Réseau VLAN 180: 192.168.36.0/24 (Réseau Wifi public) Gateway : 192.168.36.1 (Ip du pfsense) DHCP range (192.168.36.10-192.168.36.200) DNS: 192.168.36.1 (Le pfsense)