Multi-LAN et Multi-WAN avec transparance partielle

ccnet

Il y a au moins deux choses que je ne comprend pas. Vous parlez du lan, du Wan et d'une dmz. Or je ne vois que deux interfaces sur les firewalls pfsense.
Ensuite je ne comprend pas pourquoi les mêmes Vlans sont connectés des deux côtés des firewalls.

SAS110

Ce que j'appelle DMZ c'est la partie située entre les deux firewall PfSense et les deux proxy/firewall Forefront TMG. Cette zone qui est ni lan ni wan est appellée réseau de périmètre dans le jargon de Frorefront TMG. Dans ce jargon les PfSense sont appellés pare-feu avant et les Forefront TMG sont des pare-feu arrière.
C'est dans cette zone que l'on place les services accessibles de l'internet afin d'offrir au lan une sécurité supplémentaire par l'intermédiaire des pare-feu arrière en cas de compromission des serveurs de périmètre (FTP dans notre cas).

Notre souhait dans un premier temps est de "diffuser" les vlans A,B,C,..,Z jusqu'au LAN de desserte en traversant simplement les PfSense comme on diffuse des vlan d'une interface trunk d'un switch vers une autre interface trunk. Ceci tout en assurant un filtrage sur le vlan @ pour permettre la publication du serveur FTP et l'accès des clients @ a intenet.

Est-ce que c'est possible et comment proceder ?

ccnet

Je comprend votre explication pour le premier point, même si je ne partage pas du tout cette conception en terme d'architecture.

Pour le second je ne comprend toujours pas ce que vous voulez faire. Que font les Vlans A-Z dans le wan ?? Surtout pour ensuite aller dans le Lan ??
Ensuite un point me chagrine dans votre conception. Un vlan est défini, et donc n'a d'existence, que sur un même domaine de braodcast de niveau 2 (couche de liaison). En d'autres termes le vlan ne peut pas être le même de part et d'autre d'un routeur. Même si on utilise un tag identique de chaque côté, la trame Ethernet n'est pas la même, les entêtes sont différentes. Je vois des solutions mais je ne comprend pas votre besoin, autant dire que mes solutions ne valent pas grand chose. Peut être les choses seraient plus claires si vous exposiez ce besoin sous l'angle fonctionnel. Pour l'instant, ce que je comprend, c'est que vous souhaitez maintenir des vlans de part et d'autres de deux firewalls (en série et de plus différents !). Or, par définition, ce n'est pas conçu pour. On peut toujours mettre une interface en bridge sur Pfsense … mais ensuite avec les Vlans et forefront ...

lufyx

Hello

Donc pour répondre a vos questions ?
Tous d'abord le choix d'une architecture à 2 firwall
Un frontal (sur internet)
Un interne

Est t'un tres bon choix car
1- Augmentation de la securité du faite que si un Firwall est corrompu il reste une 2 eme barrière
2- Le faite D'utiliser deux technologie différente ( pfsense / TMG ) est un très bon point car on augmente la sécurité et diminuons le nombres de failles possibles

Pour répondre à ta question si elle est toujours d'actualité :
Ton problème n'est pas vraiment un plrobleme de Multi Wan ( ~~oui et non~~ pas faillover ..) mais plus de redirection de trafic

Donc Je pense qu'il faut que tu crée des vlan dans pfsense pour chaque sous réseaux
et que par la suite du redirige le trafic provenant de chaque VLAN vers chaque Routeur Correspondant
Pour cela crée les NAT ET RULES qu'il faut ^^

Le seul soucis sera peut être de faire transiter les Vlan entre le Lan et la DMZ VIA TMG
en espérant avoir était claire
Cdlt
Pour Info Pour retrouverai Biento de nombreux Tuto Pfsense J'attend la V2 final
Mon Site www.adminreso.fr

ccnet

Tous d'abord le choix d'une architecture à 2 firwall
Un frontal (sur internet)
Un interne

Est t'un tres bon choix car
1- Augmentation de la securité du faite que si un Firwall est corrompu il reste une 2 eme barrière
2- Le faite D'utiliser deux technologie différente ( pfsense / TMG ) est un très bon point car on augmente la sécurité et diminuons le nombres de failles possibles

Je ne partage pas du tout votre avis. Je m'en suis déjà expliqué dans un message précédent (http://forum.pfsense.org/index.php/topic,29117.0.html) sur le même sujet.

Même dans les très grosses structures c'est rarement ce que je vois, même si c'est parfois le cas.

La difficulté, la complexité 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 n'est pas non plus ces deux firewalls qui pourraient régler les problèmes connus dans le passé 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, impératif.

L'ensemble de ces risques est infiniment supérieur à une faille dans l'efficacité du filtrage réseau des firewall actuels.

Augmentation de la securité du faite que si un Firwall est corrompu il reste une 2 eme barrière

Le concept est connu sous le nom de défense en profondeur. Mais ce n'est pas ainsi que l'on obtient des résultats. J'observe que les machines en dmz sont derrière un seul firewall donc l'argument ne tient pas pour cette zone du réseau. Il préférable de suivre quelques règles dans l'organisation des flux.

Utiliser des vlans pour éviter la communication, si elle n'est pas nécessaire, entre des machines de la même zone.
"Firewalliser" chaque serveur ou équipement (filtrage des ports, des adresses sources, gestion précise des commutateurs, routeurs etc .. ).
Authentification et chiffrement entre les serveurs qui communiquent.
Ne pas créer de zone où l'on accepte à la fois du trafic entrant et du trafic sortant.
Utiliser un firewall applicatif.

2- Le faite D'utiliser deux technologie différente ( pfsense / TMG ) est un très bon point car on augmente la sécurité et diminuons le nombres de failles possibles

La première assertion est gratuite (on augmente la sécurité). Ce qu'on augmente surtout c'est la probabilité d'une erreur de configuration. Le facteur humain est bien plus faible que la technologie. C'est majoritairement la mise en œuvre qui pêche. Ignorer les facteurs organisationnels est une erreur majeure et ce n'est pas un hasard si les méthodes d'analyse des risques font une grande place aux aspect organisationnels.
La seconde (diminuons le nombres de failles possibles) est … une erreur de calcul. Le nombre de failles s'additionne. La probabilité de failles, liées aux erreurs commises lors du développement, est directement proportionnelle au nombre de ligne de code mise en jeux. Ici le nombre de lignes de code augmente mathématiquement puisque vous ajouter un système différent. Je vous recommande la lecture des ouvrages de Bruce Schneier. Ils sont tout à fait édifiants.

Voilà pourquoi cette croyance selon laquelle deux firewalls sont plus sûr qu'un seul me semble tout à fait nuisible sur le plan de l'efficacité. Rien à voir évidement avec un cluster de firewall où l'on adresse un autre aspect de la sécurité : la disponibilité des systèmes.

SAS110

Merci pour toutes ces précisions qui sont toutes pleines de bon sens.
Le seul problèmme c'est que cette architecture m'est imposée par ma hiérarchie. Je ne suis chargé que de la mise en pratique de la solution.
Pour l'instant ça progresse même si d'autres tâches m'ont éloigné un peu du sujet…
J'ai réussi à créer un bridge wan-dmz pour chacun des vlans coté pfsense. Je me heurte maintenant à réaliser la même chose coté TMG(ISA) mais windows ne semble gérer qu'un seul et unique bridge. Ce qui m'arrange finallement car TMG est plutot un firewall applicatif et que je n'ai pas connaissance des flux qui transitent dans ses vlans, je suis juste chargé de les transporter. Je vais donc shunter ces vlans de la dmz directement dans le lan et utiliser TMG pour filtrer le trafic du vlan@ (vers et depuis le FAI).

PS:

Lors de la création d'un bridge entre deux interfaces (Opt1 et Opt2) doit-on obligatoirement bridger Opt1 sur Opt2 ET Opt2 sur Opt1? ou peut-on se contenter d'en bridger une seule? ou ne doit-on en bridger qu'une seule?
De même pour ce qui est du filtrage dans un bridge, est-il passant ou bloquant par défaut?

ccnet

doit-on obligatoirement bridger Opt1 sur Opt2 ET Opt2 sur Opt1? ou peut-on se contenter d'en bridger une seule? ou ne doit-on en bridger qu'une seule?

On ne bridge qu'une seul interface. L'une porte une adresse ip et l'autre est accessible comme au travers d'un pont ethernet.

De même pour ce qui est du filtrage dans un bridge, est-il passant ou bloquant par défaut

A ma connaissance le fonctionnement de base de Pfsense n'est pas modifié par la présence d'un bridge en matière de filtrage.

Quelques précautions cependant.
Le portail captif et le dual wan se sont pas compatibles avec une interface en bridge impliquée dans la fonctionnalité.
Si vous utilisez un serveur dhcp il n'est pas nécessaire (dangereux en fait) d'en activer deux mais bien un seul pour les deux interfaces. Il faut ajouter la règle sur l'interface en bridge, en gros ip 0.0.0.0 / udp / 68 vers 255.255.255 / udp / 67.

SAS110

@ccnet:

L'une porte une adresse ip et l'autre est accessible comme au travers d'un pont ethernet.

Je n'ai configuré aucune adresse ip sur aucune des interfaces qui constitue le bridge.
Je souhaite néanmoins dans un premier temps que l'interface d'un coté du pont accepte tous le trafic venant de l'interface de l'autre coté du pont et vice-versa, et bien sur sans accepter aucun autre trafic que celui-là.
En gros je souhaite que mon bridge soit transparent tout en me permettant de logger le traffic qui transite au travers…
Quelle règle doit-je mettre en place pour parvenir à ce résultat ?

ccnet

La règle est assez simple non ? Cf copie d'écran. Vous pouvez ajouter dans "source" et "destination" le nom du réseau connecté aux interfaces (ex : Lan net). Les valeurs sont fournies par la liste déroulante. Votre architecture étant passablement tarabiscotée, je ne sais pas où il y a du nat, ni comment, il n'est pas dit que cette seule règle soit pertinente. (Ce qui nous ramène à la discussion sur la complexité induite pas la présence de deux firewalls, mais passons, ce n'est pas le sujet).

Pensez à activer les logs. Et à un serveur syslog pour stocker tout cela.
Enfin n'oubliez pas : Pfsense filtre le trafic qui se présente sur l'interface depuis l'extérieur.

Image1.gif_thumb

SAS110

C'est donc bien ce que j'avais fait! Merci pour la confirmation je vais pouvoir passer à une autre étape.

Je désire dissocier l'interface d'administration web de celle de mes clients LAN. Ma question est, peut-on acceder à l'interface web via une interface optionnelle sans configuration particulière?

Autre point bloquant, lors d'une fausse manip je me suis bloqué l'accès à l'interface web et je ne pouvais plus rien configurer ni revenir en arrière. J'ai donc pris une de mes clé USB formatée en FAT32 sur laquelle j'ai créé le dossier conf et dans lequel j'ai copié mon dernier fichier de sauvegarde que j'ai renommé en config.xml puis j'ai booté mon serveur avec la clé branchée, mais la config ne s'est pas appliquée, j'ai donc fait un "Restore to factory settings" puis redémmaré mais ça n'a rien changé, j'ai du recréer une config minimale pour pouvoir uploader la conf via l'interface web puis redémmarrer pour pouvoir enfin revenir à un état antérieur.
Je me demmande si j'ai bien compris le processus ou si ma clé n'a pas un problèmme.
Dans ce cas comment lever le doute sur ma clé?
Y-a-t-il un menu via la console qui permette de faire un backup/restore à partir d'un média ammovible?

SAS110

Je relance le topic suite aux récentes évolutions du projet.

J'ai réussi à tout configurer et tout fonctionne comme je veux sauf au niveau des bridges.
Le fait de configurer mes bridges de façon redondante entre les deux PfSense cause un disfonctionnement au niveau du spanning tree ce qui engendre une tempête de broadcast qui me plante tout le réseau.
Je ne connais pas grand chose au fonctionnement du STP mais je pense que les paquets BPDU servant au spanning tree ne sont pas acheminés de bout en bout.
Je crois que ça communique en multicast mais je ne sais pas du tout quelle règle mettre en place ???
Cela viens-t-il du fait que le vlan 1 n'est pas bridgé ???

Juve

Deux noeuds en cluster avec interfaces en bridge = boucle réseau….!!!!

Seule pfSense 2.0 gère STP ou RSTP et permet ainsi de filtrer ou amender les BPDU le traversant.

SAS110

Merci pour ces précisions…
Donc si je comprends bien ça sert à rien que j'essai de configurer les switchs pour le STP puisque PfSense ne laisse pas passer les paquets servant à gérér le STP.

Et la version 2.0 finale c'est pour quand ?

SAS110

Ayant implémenté la version 2.0 sur le second "serveur" pfsense, je désire maintenant activer le spanning tree.
Comme mes 2 switchs et les 2 pfsense gère le RSTP (802.1w), j'ai configuré ce mode sur mes deux switchs et j'ai désigné un des deux comme root et lui mettant la priorité la plus basse (1000 en hexa).
Maintenant, en ce qui concerne la configuration du RSTP sur mes interfaces de bridge je suis un peu déconcerté car quand j'affiche les paramètres avancés de mes interfaces de bridge, les paramètres STP semblent être a la foi des paramètres généraux de configuration et à la foi des paramètres propres au bridge en question; sauf que ces paramètres généraux ne sont pas recopiés d'un bridge à l'autre.

Je m'explique:
Petit rappel:
J'ai deux pfsense en paralèle (voir shéma plus haut)
Sur chacun d'eux, j'ai 2 cartes réseau (une coté LAN (em0) une coté WAN (em1))
sur em0 j'ai créé 7 vlan que j'ai nommé LAN,LAN2,SYNC,LanA,LanB,LanC,et LanD
sur em1 j'ai créé 6 vlan que j'ai nommé WAN,WAN2,WanA,WanB,WanC, et WanD
j'ai créé 4 bridges A,B,C,D composés respectivement de l'interface Lan et Wan correspondant à chaque lettre.
SYNC sert à gérér le cluster.
J'utilise LAN uniquement pour administrer PfSense.
LAN2 est configurée en failover entre les deux pfsense via carp et une IP virtuelle.
WAN, et WAN2, sont aussi en failover sur deux FAI.
Chacun des bridges est configuré pour laisser tout passer dans les deux sens et aucune ip n'est implémenté.
Afin d'éviter les boucles j'ai configuré mes switchs pour transporter les Vlans A,B,C et D uniquement sur mon master pfsense encore en version 1.2.3.

Sur le backup en version 2.0 RC1, quand je configure mon bridge A, je clique sur [Show Advanced Options], je coche 'Enable spanning tree options for this bridge.' je selectionne [RSTP] et je choisis mes interfaces STP dans la liste c'est à dire LanA,LanB,LanC,LanD,WanA,WanB,WanC, et WanD qui correspondent aux interfaces qui composent tous mes bridges. Je ne modifie rien d'autre et valide mes modifications. Je m'attends donc à retrouver ces paramètres généraux préconfigurés sur le bridge B sauf que ce n'est pas le cas. Ce n'est pas le seul paramètre dans ce cas, beaucoup d'autres paramètres énumèrent des interfaces qui ne sont pas "concernées" par le bridge que l'on est en train de configurer.

Je pense que cette partie de la version 2.0 n'est pas encore finalisée peut-être par manque de retour d'experience???

Je ne sais pas vraiment comment configurer tout ça… Si quelqu'un a plus d'expérience dans ce domaine, son aide me serait fort utile.