Règle de routage entre 2 réseaux PFSense



  • Bonjour,

    Sur mon PFSense, j'ai 4 interfaces :

    • ADSL Etudiant (là où ma ligne internet étudiant arrive)
    • ADSL FPC (là où ma ligne FPC arrive)
    • ETUDIANT (là où mon réseau étudiant repart)
    • FPC (là où mon réseau FPC repart)

    Depuis mon poste connecté au réseau étudiant, je peux évidemment faire un ping vers mon serveur étudiant (sur mon réseau étudiant) et je peux y accéder via mstsc.
    Par ailleurs, je ne peux pas faire de ping vers un élément de mon réseau FPC, ni y accéder via mstsc.

    Cependant, depuis mon serveur sur le réseau étudiant, je peux faire un ping vers mon serveur sur mon réseau FPC. Les deux sont donc bien reliés.

    J'ai beau retourner les règles dans tous les sens, je n'arrive pas à autoriser l'accès vers le réseau FPC depuis un élément du réseau ETUDIANT.

    Verriez-vous une solution qui m'échappe ? Comment procéderiez-vous ?

    D'avance merci,

    Cordialement,

    Loïc



  • Quelle obscure clarté ! (oxymore)

    Un débutant, qui lit juste un peu les docs du site, sait que

    • les règles sont dans Firewall > Rules > onglet (interface d'arrivée du 1er paquet)
    • les règles sont testées de haut en bas

    Si vous souhaitez être aidé, il est TRES judicieux de fournir des informations, en particulier une copie d'écrans des règles de l'onglet ETUDIANT !
    C'est vraiment pas du boulot de poser une question sans AU MINIMUM fournir cette information basique !



  • C'est vraiment très léger comme présentation et approche des besoins. Il y a un minimum de règles à mettre en place dans toutes configurations. On ne sait pas ce que vous avez fait ou pas dans votre cas. Si vous n'avez rien fait tout est normal. Pour l'usage des règles il n'y a rien à "retourner dans tous les sens". Il y a une documentation, un fonctionnement précis à connaitre (Cf post jdh) et un peu de méthode de travail à appliquer.



  • Merci pour vos réponses.

    Je sais comment fonctionnent les règles, ainsi que l'emplacement où elles se trouvent, j'en ai d'autres qui tournent sans souci.
    Sur la capture ci-dessous vous trouverez un aperçu de mon interface, peut être que ça vous apportera les renseignements nécessaires.

    Concernant les règles que j'ai "retourné dans tous les sens" j'ai essayé de faire un règle qui autoriserait l'accès à mon réseau FPC via mon IP sur le réseau étudiant, une règle qui lierait les 2 réseaux, une règle qui autoriserait le ping entre les deux (ne serait-ce que pour voir si ça fonctionne), etc. J'ai donc bel et bien retourné les règles dans tous les sens.

    Concernant mon premier post il avait pour but d'introduire mon problème, je ne sais pas quelles informations sont nécessaires pour aiguiller d'éventuels professionnels de PFSense qui accepteraient de m'aider. Au fur et à mesure des réponses, je peux évidemment fournir les informations requises.

    Je débute dans le monde de l'administration de réseau et qui plus est avec ce PFSense que je ne connais que très peu, il va donc de soit que mes posts peuvent paraitre incomplets.

    Cordialement,

    LG




  • Sur la capture ci-dessous vous trouverez un aperçu de mon interface, peut être que ça vous apportera les renseignements nécessaires.

    Je ne la vois pas.

    je ne sais pas quelles informations sont nécessaires

    Adressage, schéma, topologie physique, configuration Pfsense … Liste non limitative



  • Dans l'autre fil (celui du torrent) Jdh et moi vous avons expliquer comment fonctionne les règles de FW sous PF

    Il n'y a aucune ''magie'' ni ''truc/astuce''

    SEULEMENT de la logique à appliquer ''bêtement'' pour peut que l'on ai identifier les besoins réel ^^

    Je vous ai d'ailleur vivement recommander de réecrire TOUTES vos règles selon les conseils donner !!

    L'avez-vous fait ?



  • Oui oui j'ai refait l'ensemble des règles que j'avais et surtout ai enlevé les règles inutiles, je n'ai plus aucun problème avec les règles existantes ;) .
    C'est avec ma nouvelle problématique que je ne trouve pas de solution.

    PS: j'ai rechargé le PJ de mon post précédent.



  • La copie d'écran est présente. Rien de plus. Méthode, organisation, rigueur … où sont les données du problème ?



  • 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.0

    Il 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 ?



  • @ccnet:

    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.0

    Il 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



  • @ccnet:

    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/tcp

    Merci 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.



  • @ccnet:

    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.

    Concernant les ports, je viens de comprendre là où je me suis mélangé les pinceaux, merci du rappel ;)
    A propos des lectures, je suis en effet en train de m'informer via ce site (que vous m'aviez conseillé dans un autre sujet je crois) http://irp.nain-t.net/doku.php ! Mais je fais ça en dehors du travail avec le peu de temps que j'ai.

    Si je comprend bien, concernant mon histoire d'accès distant, c'est grâce à la règle générée par le NAT que cela fonctionne, et non pas par le NAT en lui-même ?

    Être débutant ne me dispense aucunement de méthode ou de rigueur, mais être un petit peu livré à moi-même dans un service info m'oblige à agir sans forcément connaitre tous les pré-requis, aussi indispensables soient-ils… vous en conviendrez, j'espère.
    Par ailleurs, je fais mon maximum pour appliquer les conseils que vous me donnez, si c'est à cela que vous faites allusion.
    Je dois par ailleurs jongler avec mon collègue et mon responsable qui, par exemple, ont modifié de nouveau les règles du PFSense que j'avais changé suite à vos conseil et où j'avais indiqué les sources comme vous me l'aviez indiqué. En effet concernant celle du ping (icmp), il n'était plus possible d'effectuer certains ping. De ce fait, repasser la règle en "full 'any'" a permis de résoudre le problème, sans en comprendre le sens... Je ne peux rien faire contre cela.
    Cela s'explique aussi par le fait que les examens approchent et par conséquent les plateformes des étudiants en informatique doivent être assez "libres" sinon on remet sans cesse la faute sur le PFSense.
    Après les examens, je pourrai normalement retravailler les règles du PFSense mais en attendant je dois me plier aux exigences et attentes de chacun, c'est légitime et je les comprend dans un sens.

    En effet, ce n'est pas de mon ressort, il y a d'autres avantages à cette situation mais je vous accorde tout à fait que l'absence de ce que j'aurais aimé appelé un "mentor" est largement préjudiciable.
    Pour sa défense, je précise tout de même que c'est la gestion d'un firewall affecté à un réseau étudiant (et par conséquent ne détenant pas de données extrêmement sensibles) qui m'a été attribué.

    Bien cordialement,

    Loïc ;)

    EDIT : sous vos conseils, j'ai donc supprimé le NAT (inutile voir dangereux selon vos propos), et recréé une règle sous le modèle de celle qui avait été générée automatique à la mise en place de la règle du NAT. J'ai juste du rajouter la source et tout semble fonctionner. Merci ;) (Cf. screenshot en PJ)




  • Si je comprend bien, concernant mon histoire d'accès distant, c'est grâce à la règle générée par le NAT que cela fonctionne, et non pas par le NAT en lui-même ?

    Oui. Dans Pfsense (et sur d'autres firewall mais pas toujours) les règles de nat et les règles d'accès sont deux choses différentes.
    1 La règle de nat réalise la translattion telle que spécifiée. Et rien d'autre.
    2 La règle (autorisation ou interdiction) est la seule à autoriser ou interdire un flux.
    3 Se souvenir que les règles de filtrage s'appliquent après les règles de translation.
    Ce fonctionnement est celui de Pfsense. Ne rien en déduire de plus. Chaque produit a son approche, même si il y a des points communs, il y a des différences sensibles. En sécurité, le diable est dans les détails.

    J'ai peu de temps pour commenter le reste plus en détail.



  • Comme je l'avais édité plus haut :

    sous vos conseils, j'ai donc supprimé le NAT (inutile voir dangereux selon vos propos), et recréé une règle sous le modèle de celle qui avait été générée automatique à la mise en place de la règle du NAT. J'ai juste du rajouter la source et tout semble fonctionner. Merci ;) (Cf. screenshot en PJ)

    Merci pour vos informations ;)

    Pas de soucis quant à votre manque de temps, vous m'avez déjà beaucoup aidé, merci ! ;)



  • bonjour . je suis un debutant . jaimerai solliter votre aide pour la comprenhension du fonctionnement des regles de filtrage de pfsense . en supposant que j'ai deux interfaces (lan et wan)
    comment je gere les paquet entrant et sortant sur ces interfaces. si quelque peut me proposée des docs, ou site ca va beaucoup maider puisque je beaucoup fouiller sur le net, les docs que je retrouve explique simplement comment definir une regle mai ne m'explique pas le fonctionnement de pfsense . merci d'avance



  • Sur les forums, il est généralement d'usage d'ouvrir un nouveau fil lorsqu'il y a une nouvelle question. Ce n'est pas très grave mais juste pour ton information.

    le fonctionnement de pfSense, ce ce point de vue, est très simple.
    La règle s'applique, comme pour beaucoup de firewall, sur l'interface entrante.

    Par exemple, pour autoriser les utilisateurs sur le LAN à effectuer des requêtes DNS sur un serveur DNS sur internet, il faut, sur l'interface LAN de pfSense, autoriser pour les adresse sources de type "LAN address" (si tu veux autoriser tout le LAN), pour n'importe quel port source, en destination adresse "any" (sauf si tu veux limiter précisément le serveur DNS cible), en TCP & UDP et un port destination "53".

    Les règles sur l'interface WAN vont permettre de contrôler les flux "entrants" depuis internet vers des réseaux protégés par le FW (comme le LAN par exemple)


Log in to reply