pfSense - Multiwan et accès d'un wan à un autre

[nmaupu]

Bonjour,

j'ai récemment mis en place une box fpSense avec 3 wan (freebox). J'ai de multiple machines en DMZ avec des routes statiques en sorties. J'aimerai accéder depuis une machine de la DMZ vers une autre machine du LAN ou de la DMZ en passant par internet. Le but est de monitorer un réseau avec Nagios; il serait donc judicieux que les connexions effectuées passent par le réseau internet plutôt que par le réseau local ...

Code: Tout sélectionner


        WAN2     WAN3
          \      /
           pfSense
          /      \
        /          \
      /              \
    /                  \
DMZ M1              LAN  M2



La Machine M1 passe en sortie par la connexion WAN2, la Machine M2 par le WAN3.
Le port X est NATé sur la machine M2 depuis l'adresse du WAN3.
Le but est de me connecter depuis M1 via l'adresse publique WAN3 et d'arriver sur la machine M2.

En gros :
M1 $> telnet @WAN3 X

doit répondre.

J'ai créé plusieurs règles de firewall afin d'essayer d'y parvenir :
- Autorisation de la DMZ à sortir (avec la gateway du WAN2) - onglet DMZ
- Autorisation en entrée du port X (source : any, destination : M2) - onglet WAN3
- Création d'une règle NAT afin de rediriger le port X de l'interface WAN3 vers la machine M2 (NAT > port forward)

J'ai également activé les logs sur les 2 règles firewall afin de mieux comprendre pourquoi la connexion ne se fait pas.
Résultat d'une tentative :

Code: Tout sélectionner

   >   Sep 1 16:07:34     WAN3    @WAN2:57485             M2:22     TCP
   >   Sep 1 16:07:34     DMZ     192.168.200.2:35105     @WAN3:22  TCP


Les 2 règles laissent bien passer les paquets, pourtant la connexion ne se fait pas (timeout au bout d'un certain temps).

Note : Pour les râleurs, le serveur SSH dans le LAN n'est là que temporairement, il sera déplacé en DMZ très bientôt.
Note2 : L'accès au serveur SSH se fait correctement depuis n'importe quel autre machine externe.
Note3 : Dans la partie NAT > Outbound, j'ai créé les règles AON suivantes (correspondante au WAN2 et WAN3) :

Code: Tout sélectionner

Iface    Source          Src_Port Dest  Dest_Port  NAT_Adr  NAT_Port  Static_Port  Description
WAN2     192.168.10.0/24     *     *      *           *       *         NO         LAN -> WAN2
WAN2     192.168.200.0/24    *     *      *           *       *         NO         DMZ -> WAN2     
WAN3     192.168.10.0/24     *     *      *           *       *         NO         LAN -> WAN3
WAN3     192.168.200.0/24    *     *      *           *       *         NO         DMZ -> WAN3


Quelqu'un aurait-il une idée sur la manière de procéder si toutefois c'est possible
Merci

[jdh]

Il me semble peu vraisemblable que cela fonctionne de cette façon là !


En effet, je ne vois pas comment pfSense pourrait aiguiller un trafic
- partant de l'interne (DMZ ou LAN),
- destiné à une adresse ip externe,
- devant être envoyé vers l'interne !

Cela me parait tomber sous le sens, mais ...

La raison est que le trafic naté est, par essence, un trafic entrant externe.


Ne serait-il pas plus simple d'avoir une gestion locale de nom dns qui pourrait simplifier la vie ?

On peut aisément définir localement un nom dns associé à une adresse interne alors que sur internet ce même nom est associé à l'adresse publique externe. Cela s'appelle faire du "split dns".

Cela est important par exemple avec un serveur web qui mutualise plusieurs sites web avec plusieurs nom dns. On peut ainsi le tester en interne avec les noms "externes !

[nmaupu]

Oui et je le fais déjà pour certaines application hebergées sur le réseau.
Le souci c'est que je souhaite sortir afin de forcer l'utilisation du réseau externe. En effet, s'agissant d'un nagios (application de monitoring réseau), les résultats observés seront éronnés si le traffic passe par le réseau local ! Si une panne survient sur réseau du FAI, le réseau local, fonctionnera toujours et les services seront indiqués comme opérationnels alors qu'en réalité, ils étaient inaccessibles ...

J'ai bien compris qu'il y avait un problème de NAT mais je ne comprends pas où exactement.

J'ai pensé à configurer mon réseau un peu différemment du coup :
- Je mets en NAT une des box
- Je mets la machine Nagios sur la DMZ de la box.
- Je branche également la box sur son WAN avec la conf qui va bien et les routes qui vont bien pour accéder à la machine nagios depuis le réseau local.

Ainsi, lorsque j'accède à l'ip publique de la box en question, ce sera la même box qui s'occupera du NAT et non pas pfsense.
Je vais tester et je reviens vers vous.

[jdh]

NON !


Je donne une explication claire du phénomène : il n'est pas possible AMHA de faire transiter des paquets de cette façon !

Ce n'est pas à proprement parler un problème de NAT mais je dirais qu'il s'agit plutôt d'un problème d'aiguillage de paquet au sein du firewall.


De plus, cela ne répond pas à ta question : tu veux savoir de l'extérieur si la machine est accessible. Et bien, ce test, il faut le faire de l'extérieur ! Et surement pas de façon "pseudo" extérieure !

Par contre avec Nagios, tu fourniras une info de disponibilité interne.
Eventuellement, il pourrait être malin de tracer en parallèle la disponibilité d'Internet. Parce si Internet n'est pas disponible, il est presque sur que l'inverse est aussi vrai !

(Bien sur avec un autre accès adsl, cela fonctionnerait ! Faut-il payer 30€/mois pour avoir cette info !)

[nmaupu]

NON !


Je donne une explication claire du phénomène : il n'est pas possible AMHA de faire transiter des paquets de cette façon !

Ce n'est pas à proprement parler un problème de NAT mais je dirais qu'il s'agit plutôt d'un problème d'aiguillage de paquet au sein du firewall.

Ok, tu veux dire un problème de route utilisé donc ?

De plus, cela ne répond pas à ta question : tu veux savoir de l'extérieur si la machine est accessible. Et bien, ce test, il faut le faire de l'extérieur ! Et surement pas de façon "pseudo" extérieure !

Finalement, la machine en question possèdant 2 NICs, j'ai relié un des NICs sur la DMZ du pfSense et l'autre sur la freebox en mode routeur, freebox elle-même branché sur l'un des WANs du pfSense
Résultat, le nagios accède aux autres WANs via sa freebox dédiée et non plus en local. Ce qui est le résultat escompté.
Un petit schéma vaut mieux qu'un long discours :

Code: Tout sélectionner

                fbx2 (routeur)
                 |        |   DMZ
                 |         \_________eth0_ Machine Nagios
                 |                                 |
                 |                                eth1
                 |                                 |
    fbx1         |       fbx3       fbx4           |
    @pub1        |       @pub3      @pub4          |
      |          |         |          |            |
WAN1 |     WAN2 |    WAN3 |     WAN4 |            |
      |          |         |          |            |
    ------------------------------------           |
                   pfSense                         |
                  |       |                        |
             LAN /         \ DMZ                   |
                /           \______________________|


Par contre avec Nagios, tu fourniras une info de disponibilité interne.
Eventuellement, il pourrait être malin de tracer en parallèle la disponibilité d'Internet. Parce si Internet n'est pas disponible, il est presque sur que l'inverse est aussi vrai !

(Bien sur avec un autre accès adsl, cela fonctionnerait ! Faut-il payer 30€/mois pour avoir cette info !)

Pour la disponibilité interne, je dois pouvoir utiliser le NIC connecté à la DMZ du pfSense.
Il est vrai qu'en cas de coupure de connexion à internet, les services associés ne seraient plus disponibles également ...

[jdh]

NON !


J'ai du mal écrire pour ne pas être compris !

Par ailleurs, le nouveau schéma fourni donne un bel exemple de court-circuit annulant presque toute sécurité !


* traversée du firewall :

Soit un firewall avec 3 pattes : Red - adresse internet, Orange - adresse privée en dmz, Green - adresse privée en réseau local.
Soit un serveur "nag" en dmz et un serveur "srv" en réseau local. Soit "ippub" l'adresse publique.
On suppose qu'il y a un renvoi de ports vers le serveur "srv" pour le port "port".

A ma connaissance, et à peu près quel que soit le firewall (ipcop, pfsense, ...), il n'est pas possible de faire "nag" -> "ippub"/"port" pour accéder au serveur "srv" !

Pourquoi ?

- le paquet est identifié pour faire "interface dmz" vers "interface public" en raison des adresses ip (et de l'interface d'arrivée),
- puis le paquet, en raison du port, doit être envoyé sur "interface green" avec changement d'adresse destination ("ippub" remplacé par "srv"),
- enfin le paquet doit être transmis au serveur "srv",
- au final le paquet aura fait "interface dmz" vers "interface green" !

Cela me parait évident que cela ne peut DONC pas fonctionner mais, visiblement, tu ne comprends pas la difficulté ...


* court-circuit :

Le fait d'installer un Nagios pour montrer la dispo d'un serveur est un besoin utile.

MAIS tester la disponibilité de l'extérieur se fait DEPUIS l'extérieur. C'est à dire à partir d'Internet, et pas entre le routeur et la patte Wan d'un firewall (j'appelle cela un "pseudo" extérieur).

Encore une fois cela me parait évident mais ... Donc je répète "cela ne répond pas au besoin" !

Le schéma indiqué est un bel exemple de court-circuit : il existe un lien passant outre les pattes du firewall ce qui est TOTALEMENT insecure comme approche !

Il me semble évident que SI le serveur Nagios est compromis, la dmz (derrière pfSense) LE SERA !

Je suis surpris que cela ne saute pas au yeux !

[ccnet]

Par ailleurs, le nouveau schéma fourni donne un bel exemple de court-circuit annulant presque toute sécurité !

Houla, oui, redoutable ! Ou comment remplacer son firewall par un cable RJ45 !

[nmaupu]

Merci pour tous ces éclaircissements.

NON !


J'ai du mal écrire pour ne pas être compris !

Par ailleurs, le nouveau schéma fourni donne un bel exemple de court-circuit annulant presque toute sécurité !


* traversée du firewall :

Soit un firewall avec 3 pattes : Red - adresse internet, Orange - adresse privée en dmz, Green - adresse privée en réseau local.
Soit un serveur "nag" en dmz et un serveur "srv" en réseau local. Soit "ippub" l'adresse publique.
On suppose qu'il y a un renvoi de ports vers le serveur "srv" pour le port "port".

A ma connaissance, et à peu près quel que soit le firewall (ipcop, pfsense, ...), il n'est pas possible de faire "nag" -> "ippub"/"port" pour accéder au serveur "srv" !

Pourquoi ?

- le paquet est identifié pour faire "interface dmz" vers "interface public" en raison des adresses ip (et de l'interface d'arrivée),
- puis le paquet, en raison du port, doit être envoyé sur "interface green" avec changement d'adresse destination ("ippub" remplacé par "srv"),
- enfin le paquet doit être transmis au serveur "srv",
- au final le paquet aura fait "interface dmz" vers "interface green" !

Oui, je comprends bien que si DMZ -> LAN est interdit, ca ne peut pas passer. Dès le départ, je suis mal parti en essayant d'accéder un serveur dans le LAN ...

Effectivement, j'ai tester la même chose en passant de LAN vers DMZ en passant par l'ip publique du serveur en DMZ et ça passe sans problème (il faut évidemment configurer la route statique qui va bien afin de forcer le traffic sortant à passer par le bon wan) ! J'avais cru essayer cette possibilité mais une erreur de config m'avait amener à conclure hâtivement que mon problème était le même ...

Cela me parait évident que cela ne peut DONC pas fonctionner mais, visiblement, tu ne comprends pas la difficulté ...

Personnellement je comprends très vite, mais il faut m'expliquer longtemps

* court-circuit :

Le fait d'installer un Nagios pour montrer la dispo d'un serveur est un besoin utile.

MAIS tester la disponibilité de l'extérieur se fait DEPUIS l'extérieur. C'est à dire à partir d'Internet, et pas entre le routeur et la patte Wan d'un firewall (j'appelle cela un "pseudo" extérieur).

Encore une fois cela me parait évident mais ... Donc je répète "cela ne répond pas au besoin" !

Le schéma indiqué est un bel exemple de court-circuit : il existe un lien passant outre les pattes du firewall ce qui est TOTALEMENT insecure comme approche !

Il me semble évident que SI le serveur Nagios est compromis, la dmz (derrière pfSense) LE SERA !

Je suis surpris que cela ne saute pas au yeux !

Oui, je m'en suis rendu compte après avoir posté ma bêtise.
J'ai gardé la même idée, mais je n'ai pas branché la DMZ. Ainsi, je peux tout de même utiliser la connexion en sortie.

J'ai donc :

Code: Tout sélectionner


                fbx2 (routeur)
                 |        |   DMZ
                 |         \_________eth0_ Machine Nagios
                 |                                 
                 |                               
                 |                               
    fbx1         |       fbx3       fbx4           
    @pub1        |       @pub3      @pub4         
      |          |         |          |           
WAN1 |     WAN2 |    WAN3 |     WAN4             
      |          |         |          |           
    ------------------------------------           
                   pfSense                         
                  |       |                       
             LAN /         \ DMZ                   
                /           \


Quel serait la différence entre cette configuration et une configuration ou la fbx2 serait complètement à part ? (non utilisé par WAN2 en sortie) ?

[jdh]

Bien, il y a des progrès ...


* problème de NAT :

Ce que j'explique est le résultat de l'expérimentation et de la réflexion.

Il n'est pas possible d'accéder à un serveur interne depuis un autre serveur interne via l'adresse publique.

C'est une réalité ! Et c'est un problème d'aiguillage interne au firewall. Ce n'est pas vraiment une question de règle car cela va plutôt contre la logique standard :

- le paquet, d'après les adresses ip, doit aller de l'interface dmz vers l'interface publique,
- après analyse, le paquet doit aller de l'interface dmz vers l'interface réseau interne.

C'est un changement de logique ... plutôt subtil !


* court-circuit :

Au préalable, je voudrais être sur que tu as bien compris que tu NE PEUT PAS tester la disponibilité à partir d'Internet en étant dans un "pseudo extérieur".

Ceci dit, il me parait meilleur de placer Nagios en interne ... puisqu'on aura pas plus d'information en étant en "pseudo extérieur" : la seule information que cela apporterait, serait "j'ai bricolé la règle NAT et j'ai plus accès". Cela n'apporte rien, bien évidemment !

Cela dit, placer un serveur en "pseudo extérieur" (entre le firewall et le routeur) n'est pas en soi mauvais. (A condition que l'on ne court-circuite pas le firewall).