Routage Multi Lan
-
Bonjour,
Je voudrais savoir si il est possible de raccorder ce genre de reseau selon le schema suivant :
INTERNET – FW -- switch (lan 192.168.100.x/28) -- pfsense -- (lan 128.1.0.0/24) -- switch -- multiples postes
Le firewall a deux cartes reseaux un pour le wan et un pour le lan qui a pour ip 192.168.100.254
J'ai branche l'autre pfsense pour ip 192.168.100.249 a partir de l'interface wan du pfsense je ping l'ip 192.168.100.254 et les autres postes du reseau sans probleme mais l'inverse ce n'est pas le cas. L'autre interface lan a pour ip 128.1.0.254.Le but est d'avoir le reseau dans les deux sens ainsi que internet. Quel est le meilleur moyen pour que tout fonctionne?
-
Quel est le meilleur moyen pour que tout fonctionne?
Avoir une architecture saine, avec un seul firewall !
Votre schéma peut fonctionner. Il n'y a pas de meilleur moyen, tout dépend des besoins. Cette architecture est absurde voire dangereuse du fait de l'inutile complexité de gestion qu'elle introduit. -
Bonjour,
Je voudrais savoir si il est possible de raccorder ce genre de reseau selon le schema suivant :
INTERNET – FW -- switch (lan 192.168.100.x/28) -- pfsense -- (lan 128.1.0.0/24) -- switch -- multiples postes
Le firewall a deux cartes reseaux un pour le wan et un pour le lan qui a pour ip 192.168.100.254
J'ai branche l'autre pfsense pour ip 192.168.100.249 a partir de l'interface wan du pfsense je ping l'ip 192.168.100.254 et les autres postes du reseau sans probleme mais l'inverse ce n'est pas le cas. L'autre interface lan a pour ip 128.1.0.254.Le but est d'avoir le reseau dans les deux sens ainsi que internet. Quel est le meilleur moyen pour que tout fonctionne?
Heuu…Bon... L'énoncé n'est pas très clair. Après avoir branché le décodeur, je pense avoir compris ce qui suit:
- Vous avez 2 firewalls "en cascade"
- Il y a des machines entre les 2 firewalls
- Il y a des machines "derrière" le pfSense.
- Vous arrivez à pinger les machines entre les 2 firewalls à partir du pfSense (et des machines situées derrière ce dernier?)
- Vous n'y arrivez pas à partir du LAN entre les 2 FW.
Si ce sont bien les problèmes que vous rencontrez, voici ce qui doit être fait:
- désactiver le NAT sur le pfSense afin que les machines situées derrière lui puissent être jointes via leur ip. Ca vous évitera de devoir faire des règles de redirections ou de NAT 1:1 pour chaque machine.
- Ajouter une route dans votre firewall "frontal" (qui est la passerelle par défaut du réseau 192.168.100.0/24 je suppose) qui indique que le réseau 128.1.0.0/24 est accessible via le pfSense (IP 192.168.100.249).
- Configurer le filtrage comme désiré en utilisant UNIQUEMENT les adresses privées des 2 côtés (192.168.100.x & 128.1.0.x)
ccnet, cette configuration est en effet un peu complexe mais de là a dire que c'est dangereux, je ne suis pas d'accord. Dans le monde de la sécurité, ça se fait plus que souvent d'avoir des firewalls de marque différente disposés de cette manière. Ca permet de se prémunir d'une faille chez un constructeur en sécurisant les flux au travers d'un autre constructeur... On est donc loint d'une configuration absurde & dangereuse...
Hope this helps.
-
ccnet, cette configuration est en effet un peu complexe mais de là a dire que c'est dangereux, je ne suis pas d'accord. Dans le monde de la sécurité, ça se fait plus que souvent d'avoir des firewalls de marque différente disposés de cette manière. Ca permet de se prémunir d'une faille chez un constructeur en sécurisant les flux au travers d'un autre constructeur… On est donc loint d'une configuration absurde & dangereuse...
Même dans les très grosses structures c'est rarement ce que je vois. Je maintiens que la difficulté et la lourdeur d'administration sont des facteurs de dégradation de la sécurité. Par ailleurs les failles réseaux sont devenues très minoritaires dans les intrusions réussies, le plus souvent ce sont des applicatifs qui sont à l'origine des failles de sécurité. Ce n'est pas la mise à la suite de deux firewalls (par exemple un pix et Pfsense) qui vont y changer quelque chose. Ce pas non plus ces deux firewalls qui pourraient régler les problèmes connus dans le passés avec les serveurs IIS. Ceux ci étaient entachés de lourds problèmes induits par leur conception elle même. Je pourrai multiplier les exemples à l'infini (php, MySQL, injection divers, mot de passe faible, mauvaise conf vpn, absence de chroot, etc …). Il est beaucoup plus pertinents lorsque l'on autorise des connexions externes en particulier d'avoir une protection fourni par une analyse des flux au delà de la couche 4. Une protection applicative est indispensable, le firewall applicatif est incontournable. L'ensemble de ces risques est infiniment supérieur à une faille dans l'efficacité du filtrage réseau des firewall actuels.
-
ccnet, cette configuration est en effet un peu complexe mais de là a dire que c'est dangereux, je ne suis pas d'accord. Dans le monde de la sécurité, ça se fait plus que souvent d'avoir des firewalls de marque différente disposés de cette manière. Ca permet de se prémunir d'une faille chez un constructeur en sécurisant les flux au travers d'un autre constructeur… On est donc loint d'une configuration absurde & dangereuse...
Même dans les très grosses structures c'est rarement ce que je vois. Je maintiens que la difficulté et la lourdeur d'administration sont des facteurs de dégradation de la sécurité. Par ailleurs les failles réseaux sont devenues très minoritaires dans les intrusions réussies, le plus souvent ce sont des applicatifs qui sont à l'origine des failles de sécurité. Ce n'est pas la mise à la suite de deux firewalls (par exemple un pix et Pfsense) qui vont y changer quelque chose. Ce pas non plus ces deux firewalls qui pourraient régler les problèmes connus dans le passés avec les serveurs IIS. Ceux ci étaient entachés de lourds problèmes induits par leur conception elle même. Je pourrai multiplier les exemples à l'infini (php, MySQL, injection divers, mot de passe faible, mauvaise conf vpn, absence de chroot, etc …). Il est beaucoup plus pertinents lorsque l'on autorise des connexions externes en particulier d'avoir une protection fourni par une analyse des flux au delà de la couche 4. Une protection applicative est indispensable, le firewall applicatif est incontournable. L'ensemble de ces risques est infiniment supérieur à une faille dans l'efficacité du filtrage réseau des firewall actuels.
Je suis d'accord avec vous sur le fait que ça alourdit la maintenance de la plate-forme. En effet, ça peut donc engendrer des erreurs de configuration et donc une dégradation de la sécurité… Je n'avais pas vu les choses sous cet angle. Par contre, je vois toujours ce type de configuration (Juniper/Checkpoint, ASA/Checkpoint, ASA/Juniper, etc...). Je vous rejoins aussi sur la nécessité à l'heure actuelle d'avoir un firewall applicatif afin de contrer les failles applicatives.
Cependant, ce n'était pas l'objet de la question dans ce post et je pense que ça valait la peine de fournir une solution avec l'architecture actuelle quitte à ajouter les autre remarques.
My 2 cents...
-
Bonjour,
ton architecture peut fonctionner mais tu vas être obligé de faire 2 NAT … sans compter comme le dis psylo du NAT 1:1 dans tous les sens.
Je rejoins donc ccnet sur le fait qu'il est préférable de simplifier ton architecture, celle-ci était valable il y a quelques années où la sécurité n'était pas encore le nerf de la guerre :)
1 seul firewall (cluster) suffit largement pour assurer la sécurité, une archi maitrisée = sécurité ^^ D'après ton poste, il ne me semble pas que tu maitrises réellement la chose. -
Bonjour,
ton architecture peut fonctionner mais tu vas être obligé de faire 2 NAT … sans compter comme le dis psylo du NAT 1:1 dans tous les sens.
Il n'est pas obligé de faire 2 NAT. S'il ne fait pas de NAT dans le pfSense, il doit:
- ajouter une route dans l'autre firewall pour indiquer où se trouve le réseau protégé
- configurer le NAT du réseau protégé par le pfSense dans l'autre firewall (j'avais oublié dans mon premier post je pense).