Probleme de comprehension des alias ?



  • Bonjour à tous.

    Je dispose de PfSense Embedded 1.2.3 RC1 et teste actuellement les alias.
    Il se trouve que dans un alias nommé "services_autorises" avec les classique port 80,443,110,25, … j'ai des comportements étranges de PfSense. En fait cet alias se situe dans rules sur l'interface Lan afin de pouvoir autorisé quelques services vers le Wan.

    Proto          Source                      Port  Destination  Port  Gateway  Schedule  Description
    **TCP/UDP  services_autorises  *    *                    *      * **

    Je me demande si j'ai bien compris le fonctionnement des règles et plus particulièrement le rôle la colonne "Sources" qui elle accepte
    sans broncher l'option "Single host or alias" dans mon cas.

    PS : Si en dessous de cette règle je place une règle any to any c'est à dire plein pot du Lan -> Wan l'alias perturbe la règle any to any et là rien ne fonctionne vers le Wan. Les journaux m'indiquent Block on vr0 c'est à dire la patte Wan.

    Merci d'avance
    Mirfa



  • Je ne suis pas sûr que vous fassiez la différence entre "source" et "destination".
    Je pense certain que vous confondez les 2 !

    Un client dans le LAN s'il veut accéder au site web de google va créer un paquet vers @ip de www.google.fr avec le protocole tcp et sur le port 80 (=http).
    Donc la destination est "any" (ou *) et le port 80 (pour le protocole tcp) …

    Allez un petit tour chez Christian CALECA ...



  • Bonjour à tous

    Juste une question fondamentale.

    pourquoi les règles de NAT s'appliquent avant les règles de filtrage sur PFilter ? Cela me trouble beaucoup dans la conception des règles.

    Alors qu'a mon sens la logique voudrais un filtrage de "bas niveau" dans un 1er temps sur les IP.Address/Ports_Services et ensuite une translation éventuelle des IP.Address/Ports_Services vers les destinations. NAT 1 –> n

    Pour la formidable documentation de C. Caléca, je me replonge régulièrement dedans depuis 4 ans et je la conseille systématiquement aux jeunes étudiants voire à des professionnels réseau.

    PS: Je sort du monde Iptables/Netfilter avec fichiers à plat et travail sur NetASQ F200 et F500 mais là j'ai franchement du mal avec le GUI de PFsense  :)

    Cordialement
    Mirfa.



  • Cela fait pas mal d'années que j'ai appris netfilter/iptables.
    Des scripts complets (des centaines de lignes), on passe vite aux générateurs comme Shorewall (vingt ou trente lignes).

    pfSense, basé sur (Free)BSD et Packet Filter alias PF, inquiète initialement.

    Netfilter et PF savent gérer le suivi de connexion, donc on ne s'intéresse qu'à l'initialisation d'une session

    Mais, une fois bien regardé l'interface, une fois bien compris que les onglets de la pages "Rules" correspondent à l'interface d'arrivée, pfSense est un excellent produit.
    Il n'y a guère de difficultés quand on sait exactement ce qu'on veut faire.

    D'ailleurs, une fois bien compris les alias, on comprend que l'on écrira seulement une vingtaine de règles (par interface) (et pour des cas simples de petites PME).

    Quel que soit le produit, il faut comprendre comment cela fonctionne et prendre des dispositions pour bien traduire les règles voulues.
    Avec Shorewall, je regroupais les règles sous des commentaires : # net -> fw, # lan -> net, …
    On peut aussi tracer un tableau avec en lignes l'interfaces de départ et en colonnes l'interface d'arrivée, et dans chaque case la liste des protocoles autorisés.

    Le NAT n'est que la réécriture d'une adresse : que l'on filtre avant ou après ne change pas grand chose.

    Ce qui compte, c'est de ne pas confondre source et destination parce que là, les autres questions sont assez lointaines.



  • Bonjour JDH,

    Merci pour ces précisions.

    Afin de revenir sur le sujet de la source et de la destination, voici ma vision de la question.

    • La source est une adresse qui émet un paquet pour la 1ere fois au moment de la demande d'établissement de connexion.
    • La destination est l'adresse qui pourra recevoir ce paquet après l'établissement de la demande de connexion.

    Bien sûr entre la SRC et la DEST il y a un éventuel filtrage.

    Est-ce vrais ?

    Cordialement
    Mirfa



  • J'ai écrit l'"initialisation de la session".
    Cela signifie qu'un PC (la source) établit une session avec un serveur (la destination).
    Et là bien sur, on pense au port accédé sur la destination.



  • Béh Oui ! là si moi pas comprendre cela… béh... je change de métier  ;D

    Ok!  initialisation de session ou connexion c'est sensiblement la même chose sans faire d'abus de language.
    Au détail près que la session est la période durant laquelle on maintien la connexion.

    ...Mais bon nous nous éloignons du sujet initial, cette discussion est vaine

    Cordialement
    Mirfa


Log in to reply