1 - non non non, il n'est aucunement nécessaire de gérer des routes statiques dans ton cas.
Les routes statiques servent à dire à pfSense où aller pour joindre des réseaux qu'il ne connait pas (donc pas adjacents) et qui ne sont pas joignables via la route par défaut.

2 - Tu ne vas jamais (vraiment jamais) y arriver si tu fais des modifications "juste comme ça pour tester" sans vraiment comprendre si celles-ci sont nécessaires et à quoi elles servent.

Pour le routage inter VLAN, tu n'as besoin que de règles FW au niveau des interfaces, sur chaque interface des équipements qui doivent joindre d''autres équipement sur un VAN différent.
Si ça ne fonctionne pas juste avec ça, c'est que, à mon avis, il y a un problème quelque part et que l’implémentation n'est pas celle que tu  décris et que tu penses être.

Regarder les routes (menu diagnostics/routes) est juste un moyen de vérifier que le design est bien celui que tu décris car je n'ai aucun doute que dans ce cas, pfSense a géré correctement les routes associées aux VLANs.

Sur un site important, il y a une machine à affranchir.
Comme les fax, ce type de machine va devoir muer avant 2020 puisque ce sera la fin des lignes RTC analogiques.
Or, le fabricant de cette machine nous a fourni un kit permettant de la connecter en ethernet.
On pourrait penser que les ingénieurs ont imaginé une connexion super sécurisée via le web pour nous facturer les timbres créés.
Mais, bien que super intelligents, ils n'ont pas pensé à ce qu'il y ait un proxy sur le réseau : aucun réglage pour le définir !
C'est dire ce que je pense d'eux …

Cela arrive que des ingénieurs, pas ingénieux, conçoivent des systèmes sans jamais penser à l'implantation chez le client ...

J'ai donc les 2 règles suivantes, et dans l'ordre :

pour un groupe de machines précises, accès direct à Internet pour les protocoles HTTP et HTTPS, refus d'accès à Internet pour les protocoles HTTP, HTTPS

Le proxy et cette machine à affranchir font partie du groupe autorisé, forcément.
Les autres machines ont donc accès à Internet à condition de passer par le proxy.

Votre premier fil est dans la même exacte configuration : Squid + SSL_BUMP sur pfSense.
Je préconise TOUJOURS d'arrêter cette config folle et irréflechie :
proxy explicite et dédié hors de pfsense (avec les 2 règles indiquées), et sans SSL_BUMP bien sûr.

J'espère que vous avez bien compris que c'est à cause de SSL_BUMP que la connexion à Exchange ne fonctionne pas ..
Demain, les sites HTTPS sécurisés avec HSTS ne fonctionneront pas avec SSL_BUMP ... (cf https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security )

Lorsque je lis cette question

Et est ce que c'est normale que j'ai pas Shared Key Server??

Et que je vois cette configuration (copie d'écran ci dessous), je me permet d'en douter.
Idem lorsque je lis le fichier de configuration client.
Je comprend que l'on pose la question de ce qu'est la fonctionnalité "Shared Key Server". Je m'interroge lorsque l'on se demande si c'est normal alors que l'on a déployé des certificats.

ce que j'ai fais c'est que j'ai suivis des tuto

Pas nécessaire lorsque c'est compris évidement.
Au fait CBC ou GCM et pourquoi ? SHA1 et pourquoi ? La cohérence de vos paramètres crypto dans cette configuration vpn m'échappe. Mais comme vous comprenez tout ce que vous faites …

La réponse est vive. Mais il y a un moment où il faut arrêter de me chatouiller, çà fini par me faire rire.

ovpnConf.JPG
ovpnConf.JPG_thumb

Ouais, enfin, vaut mieux remercier quelqu'un qui vous dit des choses exactes et précises :

authentification ou pas, ce n'est pas Squid qui va résoudre, en pratique, votre problème, c'est son addons classique !

Tout cela est abondamment vu et revu : il faut chercher, et je ne vois rien de votre part …

Il est beaucoup plus essentiel de

chercher avant de poser une question, présenter son problème de façon claire, (quel gain de temps ... pour les autres ... et donc pour soi !) présenter sa réflexion ...

Si vous aviez seulement parcouru un site du nom de l'addons plus .org (Documentation + Basic configuration / Extended Config), il y a longtemps que cela serait en place !

C'est le navigateur qui part sans cartes ni boussole :
Seneque "Il n'est pas de vents favorables pour celui qui ne sait où il va"

Fini pour moi.

Bonjour,

Merci @chris4916 pour la réponse effectivement c'est fonctionnel maintenant.

Pour ceux qui cherchent :

il faut faire l'ajout sur l'IPsec du réseau virtuel de openvpn 10.0.8.0/24

Coté openvpn server : pusher la route du réseau Lan derrière l'ipsec.

Merci pour votre aide, le problème est résolu vous pouvez fermer le topic.

Les tests et vérifications c'est simple :

un pc a besoin de 4 infos un premier test c'est les 3 ping

Bonjour,

Regarde ce lien, tu trouvera du matériels adapter à tes besoins et compatible avec pf
=> https://www.osnet.eu/fr/products/appliances

Et comment ton routeur Cisco est-il connecté à pfSense ???

62.71.100.112/28 est ton interface "publique" (coté internet / WAN)
l'IP utilisée est 62.71.100.114, les autres sont des routes statiques.

Donc tout ça, c'est coté Cisco…  mais qui de pfSense ?
Un petit schéma de l’implémentation physique peut-être ?  ;)

pfSense est un firewall SPI, c'est à dire Statefull Packet Inspection, ce qui signifie, pour faire court, que pfSense va maintenir une table des connexions en cours.
Si une règle à autorisé un flux de, par exemple, LAN vers internet, les packets qui vont revenir via l'interface WAN vont être automatiquement acceptés.

La flèche devant l'interface indique le sens du flux (in/out). tu peux lire le log en mode "raw" pour avoir plus de détail
https://doc.pfsense.org/index.php/Filter_Log_Format_for_pfSense_2.2

Je ne sais pas comment tu imagines l'approche du debug mais à ta place, je regarderai en priorité cette histoire de TCP:SA qui dénote un problème autre que des règles de FW.
Pourquoi aurais-tu, sur l'interface LAN_LAB1_SRV un flux entrant en provenant de 10.10.3.0/24 ?

C'est, à mon avis, mais tu donnes peu d’information sur comment est construit ton réseau (à grand coup de VM, ça n'aide pas, je suis d'accord  :)) la source de la plupart de tes problèmes.
C'est ton point 2 (de ta deuxième série de question) et le souci n'est pas, à mon avis, coté pfSense mais coté VM. ou alors il y a un typo quelque part.

La mise en œuvre de multi WAN ne nécessite absolument aucune modification des règles de NAT par défaut de pfSense en mode automatique.
Tout se passe dans la gestion des gateway, des groupes de gateway, des tiers… Et des règles de FW

Merci pour votre retour qui me permet d'y voir un peu plus clair.

Sinon pour répondre a vos questions, je virtualise sur la derniere version de vmware/vcenter, sans autres possibilités.
Pour mon expertise, je débute. Pour le NAT cela m'a été plus ou moins imposé… Mais je vais recommencer sans.

J'efface ma copie et je recommence sur du propre avec une meilleur compréhension.

Vous êtes débutant.
Merci de lire les fils du haut du forum, en particulier A LIRE EN PREMIER.
A minima, vous présenterez votre schéma sous une forme lisible par tous, … et ne soyez pas avare de précisions ...

Il est notable que la virtualisation nuit à la bonne perception de ce qu'il se passe ... y compris pour les plus habitués !

Personne ne pourra vous aider

sans informations fiables et précises, sans résultat de test bien exposés : test des 3 pings

Merci chris4916 pour t'être penché sur mon problème.

Je l'ai résolu en créant une règle NAT Outbound pour autoriser le trafic de mon LAN distant à sortir sur l'interface WAN du routeur pfSense.

La règle : https://privatebin.delurk.com/?3633c1848e48c4fd#B0UjaOJuj6nlUVuY+fTC24rSKTSWx7g3mMnAAZnuTqk=

Dylan,

effectivement, soit tu ne sais pas l'exprimer correctement (en tous cas ton post n'est pas vraiment compréhensible) soit tu n'as pas bien compris à quoi sert DHCP et comment ça fonctionne mais ce que tu décris n'a pas, en terme de réseau, beaucoup de sens.

Les adresses WAN, c'est coté WAN :-)
DHCP, c'est coté LAN et ça va délivrer des adresses IP sur le(s) LAN, à des machines physiques ou des VM, peu importe.

Mais il n'y a pas de lien direct entre les 2.

Ce qui va éventuellement faire un lien, ce n'est pas DHCP mais les options de forward, ou de NAT 1:1, ou encore de reverse proxy qui vont permettre d'accéder à des machines "sur le LAN" en utilisant des adresses IP publiques.
Ou encore des règle de FW avec une option qui force la gateway en sortie pour que les flux sortants empruntent une IP publique spécifique.

je viens d'avoir ma reponse directement par pcengines, je pensais que parce qu'il y avait un emplacement sim, le modem est inclus, et non

il faut que j'en rajoute un  :-X

Bonjour

J’ai regardé les logs mais cela ne m a pas beaucoup aidé mais j’ai fini par trouvé le problème (un peu au hasard).

Nous avons plusieurs serveurs accessibles depuis l’extérieur par une url de type :
http://moodle.mondomaine.fr
http :://labolangue. mondomaine.fr
etc….

Nous avons commencé à les passer en https
Tout  fonctionnait bien depuis 3 ou 4 semaines jusqu’à ce plantage.

Dans le reverse proxy j’ai juste enlevé tout ce que j’ avais fait (onglets web servers et mapping)
Et j’ai tout réinstallé (squid3 et squidguard).
A priori c’est reparti.

Cordialement, Frédéric

Bonsoir ,

Ou " OPNsense "