Règle de routage entre 2 réseaux PFSense
-
Vous trouverez en PJ le schéma de mon réseau.
Bon depuis mon poste (client 1 en 192.168.11.199) j'arrive à envoyer un ping vers 192.168.11.12 mais pas vers 192.168.1.3.
Cependant, depuis 192.168.11.12 je peux émettre un ping vers 192.168.1.3.
Logiquement les réseaux 192.168.11.0/24 et 192.168.1.0/24 étant reliés, je dois pouvoir accéder à 192.168.1.3 depuis mon client sur le réseau 192.168.11.0/24.
Ci-après, quelques screenshot des essais de règles que j'ai fait, sans succès.
-
Sur l'image fourni en post 4 (capture.png),
- la règle 0 est standard,
- les règles 1 et 2 me semblent correctes,
- les règles 3 et 4 sont incorrectes puisque ces règles comportent le caractère '*' dans la source (alors que ce devrait être ETUDIANT (sub)net) : à quoi correspondent-elles ?
Il ne faut avoir QUE les règles utiles !
Je préconise aussi de forcer le reload des règles par Status > Filter Reload.
Le fait que vous ayez repris les règles 3 et 4 montrent que vous ne maitrisez pas encore suffisamment pfSense !Un règle telle que ESSAI1.png doit fonctionner (même si j'écrirais plutôt via un alias la destination lanFPC = 192.168.1.0/24).
Pourquoi pas une règle simple : tcp=ipv4 / proto = icmp+all / source = ETUDIANT subnet / destination = alias - lanFPC / description = e2f ping ?
Une telle règle permet le ping de ETUDIANT vers FPC (= e2f). -
Merci beaucoup pour votre réponse plus que complète :)
En effet, inutile de vous le confirmer mais je maitrise PFSense de manière insuffisante.
Concernant les règles 3 et 4 ce n'est pas moi qui les ai mise en place et mon collègue m'a affirmé qu'elles étaient utiles… Je lui en toucherai mot dès son retour.
A propos de votre proposition de règle, j'essaye de mettre ça en place demain, encore merci.
-
Bonjour JDH,
J'ai essayé de mettre en application votre règle mais malheureusement ça ne fonctionne pas (ni le ping, ni l'accès via mstsc).
Ci-après les screenshot de la mise en place.
-
Pour regarder ce qu'il se passe, on peut utiliser Diagnostics > Packet Capture.
A un ping doit correspondre ICMP Request + ICMP Reply.
Quand tout semble bon et que cela ne fonctionne pas, il faut TOUT regarder DEPUIS LE DEBUT en ne considérant rien comme acquis.
Il y a, bien souvent, un mauvais réglage dans une partie que l'on ne regarde pas parce qu'on la considère comme bonne.
Par exemple, en se trompant sur un masque d'une interface, beaucoup de choses vont fonctionner puis une ne fonctionnera pas …NB : Les règles 3 et 4 sont mauvaises, cela fait au moins 3 fois que je l'écris ...
-
J'ai bien compris que les règles 3 et 4 sont mauvaises, mais je ne peux pas me permettre de les modifier sans consulter mon collègue qui les a mise en place !
Concernant packet capture, je ne comprend pas son fonctionnement.
-
Quand tout semble bon et que cela ne fonctionne pas, il faut TOUT regarder DEPUIS LE DEBUT en ne considérant rien comme acquis.
Je confirme à 100%. Se méfier aussi des options activées mais pas utilisée. Par exemple IP V6 activé, une règle de nat qui traîne, un "block private network" sur une interface, une erreur sur une gateway, une gateway renseignée là où il n'en faut pas, …
La liste est logue et non limitative. Bref il faut en effet TOUT regarder depuis le début et supprimer ce qui ne sert à rien. -
Merci, je vais continuer à fouiller dans les divers onglets du PFSense, et je verrai avec mon collègue à son retour le pourquoi du comment concernant les règles qu'il a créé.
En attendant, je cherche toujours à accéder à mon 2ème réseau depuis un client du 1er réseau, mais sans succès jusque-là… -
Bonjour,
J'ai vu avec mon collègue et selon lui les deux règles fonctionnent. L'une sert à permettre le ping et l'autre à l'agrégation de lien entre nos deux réseaux.
A noter que lorsque je désactive la règle de ping, tout continue de fonctionner, mais selon lui au bout d'un moment ça ne fonctionnera plus…
Je vous mets en P-J les règles en détail ainsi que le schéma réseau si ça peut vous aiguiller.
Qu'en pensez-vous ?Cordialement,
Loïc
-
Je répète que, pour un onglet donné, les règles DOIVENT (/DEVRAIENT) avoir une source qui correspond à l'onglet !
Donc la règle 3 devrait être écrite avec source=ETUDIANT subnet !Quand à la règle 4, la source indiquée est (NOT any). Je peux penser que rien ne correspond à ce type de définition !
Enfin c'est une règle tout protocole : à déconseiller.Le moins qu'on puisse dire, c'est que votre collègue est assez fâché avec pfSense puisqu'il ne respecte pas les bonnes habitudes.
Ce fil a trop duré : ce n'est pas à nous, lecteurs, de vous tenir le bras : prenez vous en charge !!
-
J'ai bien compris votre point de vue et je suis d'accord avec vous. Comme vous l'avez peut-être compris, il y a un turnover important au service informatique et par conséquent des divergences d'opinions ou d'habitudes… D'autant que les uns après les autres à passer par ce service sommes alternants en études informatiques et, par essence, pas forcément au points avec tous les éléments qui composent un réseau.
Ce fil à trop duré ? A quoi sert un forum d'entraide si au bout de deux pages on estime qu'un sujet à suffisamment existé ?
Cordialement,
-
par conséquent des divergences d'opinions ou d'habitudes…
Un service informatique ne fonctionne pas avec des opinions ou des habitudes, mais avec des méthodes, des normes, des procédures, bref de l'organisation.
A quoi sert un forum d'entraide
Il sert à donner le coup de pouce pour débloquer une situation où celui qui est aux commandes a épuisé tout ce qui est raisonnable. Ceci avec méthode.
https://forum.pfsense.org/index.php?topic=9708.0
https://forum.pfsense.org/index.php?topic=69908.0Il en ressort que les participants devraient avoir une maitrise suffisante des fondamentaux. Nous ne sommes pas là pour remédier aux manques de connaissance de base des participants, ni pour servir des recettes toutes faites. Cela dit il arrive très souvent que nous reformulions des évidences, des règles de bases et en général lorsqu'elles sont comprises et assimilées, puis appliquées au cas de l'intervenant, alors les choses vont beaucoup mieux.
J'ai vu avec mon collègue et selon lui les deux règles fonctionnent.
Le véritable problème est la pertinence de ces règles. Une règle du type "Any Any Accept" sur wan fonctionne aussi. On peut discuter de sa pertinence.
Restez sur vos positions tant que vous voudrez, nous n'avons pas les moyens de vous en faire changer. A quoi sert un forum si vous ne faites rien de ce que l'on explique et propose ? -
par conséquent des divergences d'opinions ou d'habitudes…
Un service informatique ne fonctionne pas avec des opinions ou des habitudes, mais avec des méthodes, des normes, des procédures, bref de l'organisation.
Malheureusement vous aurez compris que ce n'est pas moi qui décide de qui à tort ou qui a raison dans le service où je travaille. D'autant que la question n'est même pas là, je ne suis pas assez expérimenté pour décider et juger le travail de chacun.
Je serais le premier partant s'il fallait instaurer plus de rigueur et des démarches plus protocolaires, cependant je ne peux qu'appliquer les directives qu'on me donne et tenter de faire de mon mieux pour changer les habitudes.A quoi sert un forum d'entraide
Il sert à donner le coup de pouce pour débloquer une situation où celui qui est aux commandes a épuisé tout ce qui est raisonnable. Ceci avec méthode.
https://forum.pfsense.org/index.php?topic=9708.0
https://forum.pfsense.org/index.php?topic=69908.0Il en ressort que les participants devraient avoir une maitrise suffisante des fondamentaux. Nous ne sommes pas là pour remédier aux manques de connaissance de base des participants, ni pour servir des recettes toutes faites. Cela dit il arrive très souvent que nous reformulions des évidences, des règles de bases et en général lorsqu'elles sont comprises et assimilées, puis appliquées au cas de l'intervenant, alors les choses vont beaucoup mieux.
J'ai conscience du travail d'aide que vous faites mais ne soyez pas trop rude avec les personnes trop peu expérimentées à votre goût, chacun a ses connaissances et celles que l'on veut bien lui laisser assimiler.
J'ai vu avec mon collègue et selon lui les deux règles fonctionnent.
Le véritable problème est la pertinence de ces règles. Une règle du type "Any Any Accept" sur wan fonctionne aussi. On peut discuter de sa pertinence.
Restez sur vos positions tant que vous voudrez, nous n'avons pas les moyens de vous en faire changer. A quoi sert un forum si vous ne faites rien de ce que l'on explique et propose ?Je ne comprend pas ce que vous me reprochez, je ne campe sur aucun position étant donné que je n'en ai prise aucune. J'essaye juste de jongler tant bien que mal entre les réponses pertinentes et professionnelles que vous m'apportez et les réalités auxquelles je suis confronté en matière de relations sociales avec mon entourage professionnel.
Quoiqu'il en soit j'ai réglé une partie du problème, je ne pouvais faire de ping vers mon deuxième réseau (FPC) car je ne suis pas enregistré sur le domaine (bien que j'ai accès à tout mon réseau ETUDIANT). Élément mis à part, si j'utilise un poste enregistré sur le domaine étudiant, je peux faire un ping vers mon serveur FPC (lui-même sur le domaine FPC) mais pas l'atteindre à travers le service mstsc.
Cordialement,
-
mais pas l'atteindre à travers le service mstsc.
Le port nécessaire est ouvert ?
-
Oui, j'ai créé un NAT et une règle autorisant le port 3389 MS RDP comme sur les PJ.
J'ai ajouté le port MS RDP à ma règle autorisant les ports essentiels à mon réseau.
Pour ce faire j'ai suivi différents tutoriels trouvés sur le web et qui sont censés fonctionner, mais rien n'y fait.
-
Je viens de trouver la solution !! :)
J'ai modifié mon NAT et finit par trouver la bonne configuration.
Ensuite le port 3389 s'autorise automatiquement car une règle est créée automatiquement aussi.Pour me connecter je rentre ensuite l'IP de mon serveur:5002
Merci à tous pour votre aide ;) :)
-
Pas besoin de nat pour traiter ce type de flux entre deux zones internes.
Vos définitions de ports smtp et pop3 c'est du grand n'importe quoi. -
NAT : encore une notion qui vous échappe !
NAT = Network Adress Translation
2 cas : interne vers externe et externe vers interne
interne vers externe : forcément les adresses privées internes ne naviguent pas sur internet, il y a NAT : remplacement de l'ip source par celle de l'interface WAN.
externe vers interne : depuis internet, le flux destiné à l'ip WAN (sur le port donné) est renvoyé (forward) vers une ip interne (éventuellement en changeant de port)En interne, s'il y a plusieurs réseaux, on ne fait aucune translation d'adresse (NAT), il suffit juste de router le trafic autorisé par des règles.
Ports de protocole : encore une écriture pfsense qui vous échappe !
Avec pfSense, le : désigne "de A à B" et non "A et B", alors qu'il suffit juste d'appuyer sur + pour faire 2 lignes (ligne pour A, ligne pour B).
Par ailleurs, il est totalement insecure de permettre certains ports en sortie : il NE FAUT PAS faire cela !
Ports à interdire en sortie : dns=53/tcp, smtp=25/tcp (à réserver au seul serveur de mail interne), smtps=465/tcp, pop=110/tcp et 995/tcp, imap=143/tcp et 993/tcp
Ports assez inutiles vers WAN : rdp=3389/tcp -
Pas besoin de nat pour traiter ce type de flux entre deux zones internes.
Vos définitions de ports smtp et pop3 c'est du grand n'importe quoi.C'est la seule solution trouvée qui fonctionne… N'ayant personne pour m'aiguiller en interne, j'ai du composer avec ce que je trouvais sur le web.
NAT : encore une notion qui vous échappe !
NAT = Network Adress Translation
2 cas : interne vers externe et externe vers interne
interne vers externe : forcément les adresses privées internes ne naviguent pas sur internet, il y a NAT : remplacement de l'ip source par celle de l'interface WAN.
externe vers interne : depuis internet, le flux destiné à l'ip WAN (sur le port donné) est renvoyé (forward) vers une ip interne (éventuellement en changeant de port)En interne, s'il y a plusieurs réseaux, on ne fait aucune translation d'adresse (NAT), il suffit juste de router le trafic autorisé par des règles.
Ports de protocole : encore une écriture pfsense qui vous échappe !
Avec pfSense, le : désigne "de A à B" et non "A et B", alors qu'il suffit juste d'appuyer sur + pour faire 2 lignes (ligne pour A, ligne pour B).
Par ailleurs, il est totalement insecure de permettre certains ports en sortie : il NE FAUT PAS faire cela !
Ports à interdire en sortie : dns=53/tcp, smtp=25/tcp (à réserver au seul serveur de mail interne), smtps=465/tcp, pop=110/tcp et 995/tcp, imap=143/tcp et 993/tcp
Ports assez inutiles vers WAN : rdp=3389/tcpMerci pour les précisions à propos du NAT. Concernant ma situation, qu'est ce qui fait que maintenant tout fonctionne si ce n'est grâce au NAT ?
Si je comprend bien, sur mon alias vous préconisez que je supprime les ports 53, 25, 465, 110, 995, 143 et 993 ? Ça ne risque pas de poser problème pour les personnes utilisant par exemple outlook et qui aurait donc besoin du pop et/ou du smtp ?
Concernant le port 3389, je l'avais rajouté par sécurité lorsque j'essayais d'atteindre mon second réseau via mstsc, mais de toute façon une règle s'est créée automatiquement lors de la mise en place du fameux NAT.EDIT : Vous semblez vouloir absolument souligner toutes les lacunes et incompréhensions de mes posts ^^, je vous rappelle donc que je suis étudiant en BTS SIO et donc par conséquent débutant. ;)
-
La lecture de documentations générales (par exemple le site de Christian Caleca) et de Pfsense en particulier donne largement le détail des concepts de base que sont le routage, le filtrage et la translation d'adresse. ces documentations disent aussi quand et comment les utiliser. Soit vous ne les avez pas lu, ou pas bien comprises. Revoyez tout cela.
Quoi qu'il en soit vous accumulez les erreurs graves qui sont susceptibles d'être préjudiciable au réseau sur le quel vous intervenez.
Manifestement vous aller trop vite et ne comprenez pas ce que vous faites. Vos définitions de groupes de ports en sont un exemple. Pop3 de 25 à 465. Il y a l’erreur de la notation, Jdh vous a expliqué cela, par ailleurs autres erreurs sur les ports : 25/TCP c'est smtp, 465/TCP c'est smtps, 110/TCP c'est pop3, 995/TCP c'est pop3s. http://fr.wikipedia.org/wiki/Liste_de_ports_logiciels
C'est sérieux un firewall, on ne pratique pas par approximation.
Ce qui fait que cela fonctionne, c'est qu'un nat inutile (et même nuisible) à créé une règle correcte pour laisser par le flux. Ce qui fait que cela ne fonctionne pas c'est que vos règles sont mal écrites. Jdh vous a expliqué cela ainsi que les bonnes pratiques.je vous rappelle donc que je suis étudiant en BTS SIO et donc par conséquent débutant.
Etre débutant ne vous dispense pas de méthode, de rigueur. Bien au contraire. Quand l'expérience manque on s'en tient au minimum, au plus simple, on évite les complications. Peut être même que l'on tient compte des conseils …. y compris les bonnes lectures.
Dans cette histoire il y a un autre responsable, c'est l'inconscient qui vous a "lâché" sur ce poste alors qu'il n'existe pas de ressource interne pour vous éviter les erreurs graves. Votre responsable est un irresponsable On ne confie pas la gestion d'un firewall a un étudiant en bts. Là vous n'y êtes pour rien.