Natage lan

madlcav

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

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

NAT

LAN 172.32.154.71 192.168.1.1 * nat livebox

LAN 172.32.154.70 10.0.1.105 * nat poste

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

ccnet

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.

jdh

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

madlcav

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

jdh

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

awebster

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

chris4916

@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 ;)

jdh

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

ccnet

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.

jdh

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, …