Natage lan



  • Bonjour,

    Je me permets de poster mon problème car je n'ai pas retrouvé de post similaire… mal cherché sans doute

    j'ai installé un pfsense avec :
    une interface WAN relié a une livebox, une interface prod avec des postes et une interface lan avec un nagios dessus

    interface WAN: 192.168.1.10 ------- 192.168.1.1 (INT WAN livebox) ----- interface internet livebox ---- INTERNET
    interface PROD (10.0.1.1)  reliée a un switch avec des postes  dont un avec une IP en 10.0.1.105
    interface LAN (172.32.154.69)  avec un serveur Nagios  172.32.154.50

    Au niveau du fonctionnement général tout va bien. Filtrage internet, OpenVPN etc...

    Mon but était de  surveiller avec NAGIOS le poste en 10.0.1.105 et l'interface wan de la live box (192.168.1.1).
    Le fonctionnement se fait par l'envoi de paquets ICMP

    Je voulais donc natter les deux IP (poste et livebox) sur des IP en 172.32.154.x pour cela j'ai fait des regle nat en me basant sur la doc pfsense

    1. Virtual IP address crées

    172.32.154.70/32 LAN  proxy arp virt poste
    172.32.154.71/32 LAN  proxy arp virt livebox

    1. NAT

    LAN 172.32.154.71 192.168.1.1 * nat livebox

    LAN 172.32.154.70 10.0.1.105 * nat  poste

    1. Regle Firewall

    tout est en permis en any

    Lorsque je lance les pings cela ne répond pas...
    En faisant un packet capture je vois bien les logs ICMP sur l'interface LAN mais rien sur l'interface prod ou wan

    Je vous remercie d'avance pour vos réponses

    Malcav



  • Merci pou ce post où il y a des infos pour comprendre.

    Je voulais donc natter les deux IP (poste et livebox) sur des IP en 172.32.154.x pour cela j'ai fait des regle nat en me basant sur la doc pfsense

    Pourquoi vouloir nater ? icmp étant routable cela ne me semble pas nécessaire.
    J'utilise Centreon pour des réseaux qui comportent de multiples zones. Je n'ai besoin d'aucune translation pour faire fonctionner correctement une sonde icmp vers un équipement situé dans une zone réseau différente de celle de Centreon.



  • Le formulaire n'est pas totalement respecté mais des infos suffisantes sont là et suffisamment claires. A continuer …

    Avec un routeur à 2 interfaces, le trafic entre client et serveur garde l'ip source d'origine.
    Avec un firewall, le trafic sortant par l'interface WAN est 'natté' : c'est à dire que l'ip source est remplacé par l'ip WAN du firewall.
    C'est d'autant plus nécessaire que, usuellement, les réseaux internes des entreprises utilisent des adresses 'privées' qui sont 'interdites' sur Internet.
    Il faut donc bien substituer par une adresse ip publique (normalement en WAN).

    Ici, avec pfSense avec 3 interfaces :
    Dans le sens LAN vers WAN, il faut 'natter' car on va vers Internet.
    Dans le sens PROD vers WAN, il faut 'natter' de façon identique.
    Mais dans le sens LAN vers PROD (ou l'inverse), le trafic est juste routé (par pfSense) et donc sans NAT.
    Il n'y a donc aucune difficulté à superviser depuis LAN une machine de PROD (sous réserves que le type de trafic soit bien autorisé : pfSense est un firewall !).
    Il suffit de vérifier que chaque machine peut pinguer l'autre.

    Pour compléter vos infos initiales, il aurait fallu penser à indiquer les règles (Firewall > Rules) des onglets LAN et PROD ...
    En autres, introduire une règle spécifique à ICMP (pour le ping) ou une règle étendue (*any) ...



  • Merci pour vos réponses précises
    Je voulais natter PROD vers LAN car premièrement je ne peux pas faire de route ( car l'adressage IP 10.0.1.x deja utilisé sur d'autre firewall) et surtout parce que je decouvre pfsense depuis quelques jours et je voulais justement m'entrainer sur le NAT car c'est un point que je n'arrive pas à faire fonctionner.

    Je travaille d'habitude sur checkpoint et asa cisco mais la du coup ca change un peu :)

    Pour compléter mon premier post je suis en version 2.2.4

    Mes regles firewall  tres anarchiques sont:

    WAN

    IPv4 TCP * * WAN address 443 (HTTPS) * none   OpenVPN VPN_Acces_Externe wizard

    LAN
    IPv4 * LAN net * * * * none  
    IPv4 ICMP echoreq * * 172.32.154.69 * * none
            IPv4 TCP * * 172.32.154.69 * * none
            IPv4 TCP 172.16.8.0/24 * 10.0.1.105 * * none 
            IPv4 ICMP echoreq * * 192.168.1.1 * * none
            IPv4 * * * 172.16.154.70 * * none
    IPv4 ICMP echoreq * * 172.16.154.71 * * none

    PROD

    IPv4 TCP PROD net * * http_https * none   navigation 
    IPv4 UDP PROD net * DNS 53 (DNS) * none   dns 
            IPv4 TCP PROD net * 127.0.0.1 3128 * none   flux proxy 
            IPv4 TCP * * * * * none   flux proxy

    en esperant que cela vous inspire

    Merci d'avance



  • Mes regles firewall  tres anarchiques sont:

    Yoda sort de ce corps !

    Il y a 3 principes essentiels avec pfSense :

    • les règles se placent par onglets selon l'interface d'arrivée sur pfSense : onglet LAN = toutes les règles concernant les flux depuis des machines connectées à l'interface LAN
    • les règles sont testées de haut en bas : toujours les règles d'interdiction AVANT les règles d'autorisation
    • une bonne lecture se fait grâce à l'utilisation d'alias : pas de '172.16.154.70' mais un 'ipServeur' ! pas de '172.32.154.0/24' mais un 'netLAN' ! …

    Je ne comprends pas l'argument pour forcer le NAT :
    au besoin, sur la machine cible (en PROD), créer une route qui passe par pfSense ...



  • @jdh:

    Je ne comprends pas l'argument pour forcer le NAT :
    au besoin, sur la machine cible (en PROD), créer une route qui passe par pfSense …

    Je mets la main au feu… je pense ce que madlcav essaye de faire c'est de contourner le fait qu'il y a déjà un pare-feu sur les réseaux LAN et PROD et qu'il se sert du pfSense afin de s’entraîner et d'y installer des fonctionnalités qui ne sont pas possibles avec ce qui est en place.
    Ceci étant dit, la fonction de NAT offre une possibilité intéressante de faire une traduction de l'adresse source, éliminant alors les problèmes de routage associés avec son scénario.
    Donc dans le cas d'un paquet ICMP envoyé depuis la machine LAN, le système sur le réseau PROD voit la source comme étant l'interface PROD de son pare-feu et non l'adresse IP de la machine sur le LAN.  Dans ce cas la réponse se fait simplement par la couche layer2, pas besoin de routes additionnelles.
    Ceci est essentiellement le fonctionnement décrit par le NAT usuel que l'on retrouve du coté WAN, que tu as très bien décrit d'ailleurs, mais parfois très pratique du coté interne aussi.



  • @awebster:

    Je mets la main au feu… je pense ce que madlcav essaye de faire c'est de contourner le fait qu'il y a déjà un pare-feu sur les réseaux LAN et PROD et qu'il se sert du pfSense afin de s’entraîner et d'y installer des fonctionnalités qui ne sont pas possibles avec ce qui est en place
    ..../...
    Ceci est essentiellement le fonctionnement décrit par le NAT usuel que l'on retrouve du coté WAN, que tu as très bien décrit d'ailleurs, mais parfois très pratique du coté interne aussi.

    Pas la peine de risquer de te bruler, ton analyse est très plausible  ;)



  • @awebster

    Il y a peut être un firewall autre déjà existant. Oui, et alors ?

    Dans le réseau PROD, il y a

    • un firewall qui est la passerelle par défaut,
    • un pfSense avec une patte dans un autre réseau.

    Il est extrêmement simple d'ajouter, sur le pc à tester, une route vers le lan via l'ip de pfSense : les paquets ip seront simplement routés sans difficulté (et ne passeront pas par le firewall).

    C'est bien plus simple que de créer un NAT (outbound) pour tout le trafic LAN du pfSense.



  • Si nous résumons :
    Hypothèse 1 : situation de travail normal, pfsense est le firewall du réseau. Dans ce cas aucun besoin de nat : Pfsense route automatiquement tous les paquets de et vers les réseaux connectés à ses interfaces.
    Hypothèse 2 : il veut contourner la politique de sécurité dans une situation où une machine Pfsense a une interface dans chacun des réseaux. Changer la passerelle par défaut du poste règle le problème mais la source est visible. Le nat permettrai le camouflage.



  • Je reprends :

    je ne vois aucun besoin de faire du NAT et des ip 'proxy-arp' : un serveur Nagios en LAN est parfaitement capable de surveiller une livebox situé en WAN et une machine dans un autre réseau (routé si besoin).

    De toute façon, il faut bien comprendre que si un ping, depuis Nagios, n'a pas de retour, il n'y aura pas de surveillance. Un point c'est tout.

    Encore une fois, il est ESSENTIEL de poser un besoin avant de poser une solution.

    Il serait judicieux de décrire un peu mieux le besoin, les contraintes réseaux, …


Log in to reply