FW transparent - Bridge WAN / LAN - hyper-V
-
Bonjour
Je suis en train de tester pfsense version 2.6.0.
je ne pense pas être novice en pare-feu, mais la pour le coup je sèche.l'idée de base est de créer un pare-feu transparent sur un LAN "public" vers un autre LAN "sécure".
En VM pour qu'il suive ces camarades dans le PRA, Transparent pour éviter de changer toutes les IP de l'existantes.- bridge sur WAN / OPT1
- Bridge activé avec IP du WAN (interne)
- WAN protection IP privé et bogon désactivé.
- NAT désactivé
- net.link.bridge.pfil_bridge = 1
- net.link.bridge.pfil_member =0
- règle open sur toutes les interfaces, bridge compris
Pas de ping dans n'importe quel sens; si je désactive le bridge et que j'attribue une IP au WAN ou au OPT1 c'est OK.
Sur l'hyper-v avec powershell Get-VMNetworkAdapter * je constate qu'il persiste une IPV6 même lorsqu'aucune IP n'est défini dans pfSense. (sur toutes les interfaces, pas le cas avec d'autre VM)
pfsense est-il compatible bridge avec hyper-v ?
J'ai loupé une étape ?Merci par avance,
Guillaume -
Vous n'exposez qu'une partie de vos objectifs.
De plus, vous faites des choix : bref, vous pensez solution avant de penser besoin. (Enfin AMHA)Question virtualisation, il y a des solutions plus légères (centaines de Mo contre plusieurs Go), plus simples et plus fiables : VMware (en pro ou esxi), KVM (Proxmox par exemple) ...
Bridge ??? Pourquoi ? Que voulez vous dire par 'pare-feu transparent' ? Est ce qu'un PRA impose de rester sur le même adressage ? Est ce que un client ne devrait pas être toujours en DHCP pour s'adapter au réseau sur lequel il se connecte ?
Intrinsèquement le bridge me parait toujours très délicat. Par contre on gagne à séparer les réseaux (clients versus serveurs, ...) et donc à router. Probablement si on route déjà naturellement, le PRA est peut-être plus facile ?
-
@jdh Bonjour,
Merci pour votre réponse,Je voie que vous semblez expert; pourquoi hyper-v tout simplement car il correspond a nos besoins de plus pour être homogène sans multiplier les solutions.
Nos outils métier enregistre les IP dans une multitude d'emplacement ce qui complique grandement la mise en place d'un PRA, mais ce n'est pas le sujet.
Je souhaite un pare-feu virtuel contre de physique pour qu'il suive le PRA ce qui est différent.
J'entends par pare-feu Transparent un pare-feu ayant sur le WAN et OPT1 les mêmes plan d'adressage. (évidement pas si transparent, car je compte bien créer les règles de filtrage.)Pour moi la partie Bridge est la première étape et normalement la plu simple de notre sécurisation infra versus VPN / clients.
Je suis conscient que ce n'est pas la plu pertinente, mais c'est la plu simple.
Par la suite évidement sur plusieurs autre réseau routé dans les règles de l'art je corrigerai au fur et a mesure des migrations.Merci,
Guillaume -
Hyper-V ? Vous n'avez pas essayé VMware ou KVM : essayer donc Proxmox et vous comprendrez pourquoi c'est ce qu'il faut ...
Votre retour est très net : la solution est avant le besoin !
Je ne comprends pas votre 'solution' de PRA ...
-
@supportgti La solution n'est pas forcément avant le besoin si pfsense est incompatible avec hyper-v en bridge je chercherai un concurrent.
La partie HV/PRA est hors sujet je peut répliquer une VM sur le site secondaire, pas besoin de proxmox ou vmware pour ça; le besoin colle avec la solution.
Je vais suivre votre station d'alert, la question de base qui me semble simple :
pfsense est-il compatible avec hyper-v en bridge WAN / OPT1 ? car dans mon cas ça ne fonctionne pas
si je désactive le bridge mes interfaces et que j'y ajoute une IP, elle sont joignable WAN / OPT1, en powershell je voie bien les adresse IPV4 depuis l'hyperviseur.
si j'active le bridge avec une IP et que j'enlève les IP des interfaces WAN /OPT1, l'IPV4 disparaît des interfaces en powershell HV ce qui est logique, puisque cette carte réseau bridge est virtuelle avec une MAC différente.
Par contre le flux semble ne pas passer sur hyper-v, je vais creuser de ce coté là.Merci,
Guillaume -
Trouvé il faut cocher la case activer l'usurpations d'adresse MAC dans les interfaces bridgé dans hyper-v
-
Visiblement, vous ne comprenez pas ce que j'écris ...
Si j'écris 'il ne faut pas penser solution avant besoin', cela veut dire qu'il est TRES important de définir un besoin avant de définir une solution. A un moment, si vous définissez une solution, si brillante soit elle, elle risque de ne pas répondre au besoin.
Un PRA peut être très variable parce que les situations qui amènent à mettre en oeuvre un PRA sont variables.
Exemple vécu en 1999 :
- je travaillais à l'informatique comme systèmes et réseaux dans une usine de 700 personnes,
- on apprend, le mardi, que les syndicats veulent bloquer l'usine = plus d'entrée = soudage du portail d'entrée,
- or la Direction veut continuer à faire travailler 70 cadres notamment au Bureau d'Etudes, à la Compta, l'Informatique, ...
- 1er point : les personnes concernées rentrent leur voiture et embarquent leur PC dans leur coffre (discrètement),
- 2me point : mon collègue, qui avait prévu le coup, avait stocké un routeur Numeris (identique à d'autres sites), des switchs, des cables réseaux et électriques de différentes tailles,
- quelques personnes s'installent dans les locaux d'une direction régionale à 10 km : ils ont accès aux serveurs sans difficulté,
- le reste va aller jeudi dans un hotel,
- le mercredi Orange livre une ligne Numeris en urgence dans l'hôtel, j'installe le routeur, les switchs, les câbles,
- dans l'hotel, une cinquantaine de cadres ont pu brancher leur PC et travailler du jeudi au jeudi/vendredi suivant.
Là, il s'agissait d'un PRA d'accès, sans aucune dégâts aux serveurs.
Mais il y a beaucoup de situations possibles.
La plus grave étant le cryptage de tous les serveurs ...Je présume que vous êtes jeune : Il n'y a pas que Microsoft; j'utilise Windows dès que c'est le meilleur produit (pour le besoin prévu), et d'autres solutions dès que c'est le meilleur produit.
Il y a plein de domaines où Microsoft n'est pas la meilleure solution : la virtualisation, les firewalls, les routeurs, les serveurs web, les serveurs de bases de données, ...
-
@jdh Votre expérience semble très intéressante mais hors sujet ici.
Je respecte vos idées merci de respecter les miennes.
Merci de m'avoir rajeuni ! ;-)
-
Une solution se construit après avoir défini un usage, un besoin.
Vous faites ce que vous voulez.
Mais je ne comprends rien à votre solution de bridge et de VM qui 'suit' votre PRA. (Et je ne crois pas être seul ...)(Un jour vous comprendrez ...)