CARP IP LAN non Pingable
-
Bonjour,
Je viens de configuré CARP entre mes deux pfSenses sur un réseau OVH ( PrivateCloud ) en utilisant ce tutoriel :http://www.scribd.com/doc/78040600/15/LE-BASCULEMENT-FAILOVER
Mon pfsense Maître est bien définit en temps que MASTER et mon pfsense Esclave est bien définit en temps que BACKUP.
Cependant toutes mes machines virtuelle ayant comme Passerelle 192.168.0.254 ( IP LAN CARP ) n'arrivent pas à pinger cette IP.
Elles pingent correctement 192.168.0.253 IP LAN pfsense maitre et 192.168.0.252 IP LAN pfsense esclave.J'ai mis une règle de Firewall sur mon interface LAN qui autorise tout.
Voici des Screenshots de mes interfaces :
http://imageshack.us/photo/my-images/827/16246244.png/
http://imageshack.us/photo/my-images/35/11833375.png/
http://imageshack.us/photo/my-images/96/16125419.png/
Est-ce que vous avez une idée ?
Oni'
-
Problème résolu.
Il fallait activer le Prosmiscious mode sur le vSwitch de ESX
http://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)
-
La pertinence d'un cluster pfsense sur un esx est voisine de zéro. L'activation de cette option sur le switch virtuel est exactement le contraire de ce qui est recommandé par vmware en terme de sécurité. Les firewalls sur un seul esx et probablement toutes les vm dessus, ou comment avoir tout faux sur le plan sécurité en utilisant mal la virtualisation. Avec la complexité réseau induite, il y a fort à parier que les flux sont mélangés sur les interfaces. Une defaillance dans le stockage et tout saute.
Et pourquoi ne pas respecter les regles d'adressage sur les interfaces pfsync ? -
Notre environnement est hébergé chez OVH dans un PrivateCloud que l'on loue. Nous n'avons pas la main sur les machines bien entendu.
La pertinence d'un cluster pfsense sur un esx est voisine de zéro.
Je suis entièrement d'accord, mais comment protéger des machines virtuelles sans avoir de FW physique ?
Sachant que je pense que dans ce genre d'environnement notre ESX est protégé en amont.Les firewalls sur un seul esx et probablement toutes les vm dessus, ou comment avoir tout faux sur le plan sécurité en utilisant mal la virtualisation
Alors non toutes les VM ne sont pas sur un seul ESX, justement nous avons toutes les Licence VMotion etc. Les Hosts sont sur site distant, et dans des banques de données différentes.
Nous voulions simplement redonder le FW étant donné que les Esclaves et Maitre de l'ensemble de mon réseau sont hébergé sur deux Hyperviseurs distant.cette option sur le switch virtuel est exactement le contraire de ce qui est recommandé par vmware en terme de sécurité.
Quand tu souscris a une option PrivateCloudComputing, chez OVH et que tu prends un ESX.
Si tu n'actives pas cette option sur le vSwitch ( ceci dit en passant c'est à OVH de te l'activer car impossible de modifier la configuration réseau de l'hyperviseur ). Tes machines ne peuvent pas sortir via le parefeu.Exemple, j'ai configuré un CARP, et sans cette option la carte n'était pas pingable a l'intérieur de leur réseau. Pourquoi je ne sais pas …
Et pourquoi ne pas respecter les regles d'adressage sur les interfaces pfsync ?
Je ne vois pas de soucis. :/
Oni'
-
Je suis entièrement d'accord, mais comment protéger des machines virtuelles sans avoir de FW physique ?
Je ne vous comprend plus. Avez vous des firewalls physiques (la seule solution sérieuse) ou bien monté sur l'esx ?
Les machines virtuelles sont abrogeables comme les machines physiques. -
OVH protège les Hyperviseurs de leur clients avec des FW que personne en dehors de leurs techniciens ne peut administré.
OVH distribue a ces clients des pools d'adresse IP qui nous font penser quels sont publique alors qu'il s'agit en fait d'un immense réseau privé avec des VLAN taggué.Nos FW sont virtuelle, pour ajouté une sécurité supplémentaire.
Mais nous savons pertinemment que notre serveur ne sort pas sur internet comme ça. -
OVH protège les Hyperviseurs de leur clients avec des FW que personne en dehors de leurs techniciens ne peut administré.
Très flou. L'hyperviseur lui même ou bien les machines qui sont hébergées dessus (interfaces physiques et switchs virtuels différents si l'on fait les choses proprement c'est à dire comme le préconise Vmware) ? Ce n'est vraiment pas la même chose. Vous faites des demandes d'ouvertures de ports selon vos besoins ? Je ne le crois pas. C'est l'accès à l'hyperviseur qui est protégé, sans doute pas les vm qu'il est de votre responsabilité de protéger.
OVH distribue a ces clients des pools d'adresse IP qui nous font penser quels sont publique alors qu'il s'agit en fait d'un immense réseau privé avec des VLAN taggué.
Au premier coup d’œil on distingue une ip publique d'une ip privée ! Êtes vous bien certain que vous parlez à bon escient de Vlan taggé (comment ne le seraient ils pas !). C'est très loin d'être suffisant pour assurer le caractère privé d'un cloud.
Nos FW sont virtuelle, pour ajouté une sécurité supplémentaire.
Je n'y revient pas …
Mais nous savons pertinemment que notre serveur ne sort pas sur internet comme ça.
Sortir est une chose, entrer en est une autre … Il est souhaitable d'avoir un certain nombre d'assurances sur de tels points ...
-
Je suis conscient que notre niveau de sécurité est faible. Et j'aimerai bien mettre en oeuvre une architecture avec le moins de faille possible. Mais pour le moment nous n'avons pas d'autre alternative dans le sens ou, en dehors de mettre en ligne des machines virtuelles nous ne pouvons pas faire grand chose.
Actuellement mon soucis est, que ma Virtual IP n'est pas "pingable". Cela me bloque énormément, cependant
pfSync fonctionne correctement.Je peux rajouter plusieurs CARP sur le LAN qui sont détectée comme MASTER d'un cote et BACKUP de l'autre.
Cependant pas pour le WAN elles restent BACKUP des deux côtés. -
Je viens de résoudre le problème comme quoi l'IP Virtuelle ne répondait pas aux pings. C'était un soucis au niveau de mon hébergeur.
Cependant, désormais que je la ping, je n'ai pas accès a l'interface d'administration …
Et savez vous comment mettre l'interface d'administration en HTTPS a tout hazard.Oni'