RULES & NAT - SITEWEB



  • Bonjour,

    Je recontre actuellement des problemes sur l'acces des serveurs distants à mon siteintranet via mon Pfsense.

    Pour resumer ci-dessous les @IP publiques et intranet de ma configuration.:

    Site Distant @IP PUBLIQUE / MASK

    81.200.30.1/25
    81.201.30.1/26
    81.202.30.1/27
    81.203.30.1/28

    Pfsense
    @IP PUBLIQUE 81.240.20.20
    @IP INTRANET  192.168.1.253

    Site Web intranet @IP INTRANET  192.168.1.200

    Le but est permettre au site distant de communiquer directement avec mon siteweb intranet via des rules et nat sur le Pfsense.

    J'ai crée une regle qui autorise sur le WAN de mon Pfsense qui autorise toutes les acces des 4 adresses publiques de mon site distant à savoir

    81.200.30.1/25
    81.201.30.1/26
    81.202.30.1/27
    81.203.30.1/28

    Et en parralele, j'ai crée un NAT de tout ce qui arrive sur le WAN en redirection vers mon adresse @IP INTRANET  192.168.1.200.

    Mes sites distants n'arrivent pas à pinger sur l'adresse @IP PUBLIQUE 81.240.20.20 de mon Pfsense alors que j'ai créé une rules.

    Qu'en pensez vous ? Je ne vois pas ou est le probleme.



  • Le ping n'est pas le bon outil de contrôle si en même temps tu ne dit pas si ICMP est autorisé  ;)
    Il faut aussi décrire (au moins un peu) comment tu passe de internet à pfSense.
    Quel est ton accès internet ? un routeur, un "modem" xDSL, FTTH ou autre ? en bridge ?

    Ensuite, avant de regarder le ping, regarde plutôt les logs des composants impliqués.

    ps: c'est très difficile à lire lorsque tout est souligné. je me doute bien que c'est un typo mais… pfff :-)



  • Desolé pour le texte souligne c'est corrigé.

    L'acces Internet en mode bridge via un modem ADSL

    Pour le passage de internet à pFsense je vois pas la question ? Peux tu detailler la question ?



  • @Pfense85:

    Pour le passage de internet à pFsense je vois pas la question ? Peux tu detailler la question ?

    Ta réponse suffit: c'est un mode bridge donc ton pfSense à l'adresse IP publique  ;)
    Donc c'est facile: tu peux regarder directement dans les logs pfSense pour voir où arrive ta demande connexion et qu'est-ce qui l'empêche d'aboutir.
    A la limite, tu peux activer les fonctions de log au niveau des règles FW.



  • Je viens de regarder les logs STATUS puis SYTEMS LOGS puis FIREWALL, les adresses IP PUBLIQUES du site distant sont bloqués.



  • Donc ta/tes règle qui autorise les accès n'est probablement pas la bonne.
    Un truc simple pour tester: le log de pfSense permet d'ajouter très facilement une règle pour un flux bloqué (via l'interface log)
    Tu peux ajouter cette règle "automatique" puis comparer dans l'interface "rules" à la tienne pour voir la différence si celle-ci ne te saute pas aux yeux.

    Attention, ce n'est pas LA bonne réponse à ton besoin, c'est vraiment juste si tu ne comprends pas pourquoi ça ne passe pas avec ta règle est que tu veux voir une syntaxe qui fonctionne. Par la suite, il faut très certainement adapter (voire supprimer) cette règle automatique.



  • salut salut

    vous serait il possible de nous mettre clairement la/les règles que vous avez mis en place, ainsi que les éléments sur le nat ;

    • sur le Wan

    • sur la DMZ

    S'il vous plait merci.



  • Que tout cela est confus !
    Merci de noter WAN au lieu de PUBLIQUE et LAN au lieu d'INTRANET : les noms de ces interfaces sont usuels, et sauf à compliquer, je ne vois pas l'intérêt …

    Mes sites distants n'arrivent pas à pinger sur l'adresse @IP PUBLIQUE 81.240.20.20 de mon Pfsense alors que j'ai créé une rules.

    Il faut, en effet, pour avoir une réponse à un test de ping, une règle dans l'onglet WAN. Quelle règle avez vous créée (qui ne fonctionnerait pas) ?

    81.200.30.1/25  …  81.201.30.1/26  ...  81.202.30.1/27  ...  81.203.30.1/28

    Ce ne serait pas plutôt 81.200.20.1/32 pour votre 2ième adresse ip publique (présente sur WAN) ? J'aimerais bien savoir comment vous feriez la différence entre vos écritures …

    Le but est permettre au site distant de communiquer directement avec mon siteweb intranet via des rules et nat sur le Pfsense.

    Cette phrase est incorrecte.

    La bonne version :

    On crée une règle NAT (de type 'port forward') pour permettre l'accès depuis Internet à un serveur web interne.
    (La règle NAT crée automatiquement une règle dans l'onglet WAN.)

    J'ajoute : il ne faut surtout pas s'amuser à modifier la règle créé de l'onglet WAN.



  • Salut salut,

    Je suis personnellement sur une conf en double box (orange/free) je n'ai pas de soucis de redirection vers mes machines ou services en arrière de mon cluster pfsense.
    en résumé que cela soit avec un cluster ou un simple pare feu PF.

    Le wan écoute toutes les requêtes sur un port déterminé venant de toutes sources ip à destination d'une ip dans un segment réseau derrière votre PF sur un port défini.
    Mais il faut avoir au préalable paramétré dans le NAT onglet outbount en "manual outbount". (il y a suffisamment de tuto sur le web pour cela)

    Pour une simplicité de relecture des regles, pensez à mettre en place des alias pour les ip_machines / ports_machines

    Pensez simples == pensez efficace.

    Cordialement.



  • @jdh:

    81.200.30.1/25
    81.201.30.1/26
    81.202.30.1/27
    81.203.30.1/28

    Ce ne serait pas plutôt 81.200.20.1/32 pour votre 2ième adresse ip publique (présente sur WAN) ? J'aimerais bien savoir comment vous feriez la différence entre vos écritures …

    Je n'avais pas fait attention aux (fausses) adresses IP  ;D ;D
    ça sent le copier/coller dans un tableur  ;)



  • Les adresses IP PUBLIQUES cités sont des exemples c'est pour le principe.  J'ai créé un ALIAS regroupant les IP PUBLIQUES que j'ai besoin.



  • J'ai créé un RULE

    Proto Source Port Destination Port Gateway           Queue Schedule
                    IPv4 * IP PUBLIQUES * WAN address     *         * none



  • J'ai créé un rule sur les adresses ip avec l'alias IP PUBLIQUES

    Proto Source     Port Destination Port Gateway Queue
    IPv4 * IP PUBLIQUES * WAN address * *         none

    Et ensuite une NAT

    If         Proto Src. addr         Src. ports Dest. addr Dest. ports NAT IP                 NAT Ports
    WAN TCP         IP PUBLIQUES *                 LAN address 443 (HTTPS) 192.168.1.200 443 (HTTPS)

    Je viens de regarder mes logs et les adresses IP PUBLIQUES ne sont pas bloques sur le firewall.



  • Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
    Ma remarque est sur ce masque !

    Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
    (Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)

    EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !

    Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.

    Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
    La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
    L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.

    Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).



  • @jdh:

    Il n'empêche que l'exemple est particulièrement mal choisi puisque c'est la même adresse avec des masques différents !
    Ma remarque est sur ce masque !

    Le mieux est TOUJOURS d'indiquer une adresse publique de la forme 81.xx.xx.1, 81.xx.xx.2 et ainsi de suite …
    (Cette notation permet de bien mentionner le côté 'je n'ai pas mis les vraies adresses'.)

    EDIT : J'ai commencé à écrire avant les 2 post supplémentaires !

    Si vous souhaitez avoir des avis, il serait judicieux de mettre une copie d'écran de vos règles.

    Je mentionne qu'une seule règle est nécessaire pour donner un accès à un serveur Intranet via une adresse publiques (c'est dire la difficulté).
    La seul règle nécessaire est bien évidemment un NAT port forward : je l'ai décrit le 8/1.
    L'utilisation d'alias dans une règle NAT ne me parait pas judicieux mais je peux me tromper.

    Par ailleurs, et c'est le principe de la mutualisation en http, la logique est plutôt d'avoir une seule ip publique et un serveur web capable de pousser plusieurs sites web (avec des noms différents).

    Site Distant @IP PUBLIQUE / MASK

    81.XXX.XX.6/25
    83.XXX.XX.8/26
    94.XXX.XX.2/27
    87.XXX.XX.4/28

    Pfsense
    @IP PUBLIQUE 81.240.20.20
    @IP INTRANET  192.168.1.253

    Site Web intranet @IP INTRANET  192.168.1.200



  • Bon, puisque vous ne semblez pas comprendre, expliquez comment, depuis Internet, accédez vous à 81.XXX.XX.6/25 ? (sous-entendu différemment de 81.xx.xx.6/32 ou /26)

    La règle NAT est correcte et indique une cible claire.
    Si cela pouvait vous inspirez …



  • Depuis internet, les sites distants avec les adresses publiques ennoncées dans le topic doivent pouvoir communiquer avec le serveur de mon reseau informatique.

    C'est pour cette raison que je pensais créer une rule autorisant ces sites à communiquer avec le wan de mon pfsense et ensuite une nat qui redirige les communication vers mon ip lan 192.168.1.200

    Je suis perdu dans les solutions entre une NAT outbound, 1:1 et port forward.



  • En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
    Tu utilises bien ce concept pour ta règle de NAT.
    Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
    Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT  ;)

    Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN



  • @chris4916:

    En terme de règle sur le FW, il faut autoriser les adresses externes à accéder… à l'interface WAN.
    Tu utilises bien ce concept pour ta règle de NAT.
    Le sigle "∞" à gauche de ta règle de NAT signifie qu'il y a une règle de FW automatiquement créée avec cette règle de NAT.
    Tu peux y accéder lorsque tu es en mode édition sur la règle de NAT  ;)

    Et à l'occasion, tu constateras que la règle du tu crées manuellement ne marche pas car tu autorises à accès à l'IP de ton adresse LAN... sur l'adresse WAN

    Si je resume la situation le NAT que j'ai créé est fonctionnel car tout ce qui arrive sur le wan avec le port 443 est redirigé vers mon lan.

    Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.



  • @Pfense85:

    Mais ma rule est n'est pas operationnelle je dois crée un rule sur le wan qui autorise les adresses IP PUBLIQUES.

    …. si tu continues ta phrase jusqu'au bout:

    une règle sur le WAN qui autorise les adresses publiques à accéder à l'adresse IP WAN (et pas LAN)  :P



  • Je vois que vous ne comprenez vraiment pas beaucoup !

    1ère erreur :
    Vos adresses 81.XXX.XX.6/25 sont stupides ! Si vous voulez ajouter des adresses virtuelles, elles seront /32, que l'on note sans le /32 par convention.

    J'ai eu beau l'écrire plusieurs fois, posez plusieurs fois la question 'comment on fait', vous passez sur ces âneries sans comprendre …

    2ième erreur :
    J'écris que la règle NAT est correcte (et qu'elle génère automatiquement une règle liée dans l'onglet WAN).
    J'écris les mot 'cible claire', et vous ne comprenez pas la suite logique

    Il faut 1 règle NAT identique pour chaque ip virtuelle !
    C'est quand même pas grand chose ...

    Ce qui aurait été intelligent, c'est de créer des règles WAN pour accepter le ping sur les ip publiques. Mais ça, vous avez oublié en route.
    Perso c'est ce que je commence par faire parce que cela permet de vérifier que les ip virtuelles sont bien 'présentes' et 'actives' au niveau du WAN.

    En fait c'est souvent bien plus simple mais il faut juste faire ce qui est nécessaire.
    Quand quelqu'un répète quelque chose, il faudrait comprendre que cela veut dire des choses ... Mais non ...


Log in to reply