CARP VIP sur interface Vlan (vmWare)

Barikad

Bonjour,
Dans mon organisation, nous avons plusieurs dizaine de pfSense (appliances Netgate ou virtualisés), dont plusieurs cluster CARP virtualisés (VMware vSphere).
Le HA fonctionne bien sur ces clusters, sauf qu'a force de rajoutter des interfaces nous sommes arrivés à la limite de 10 interfaces par VM (limite vSphere).
Nous avons donc crée une interface en trunk et des interfaces Vlan sur cette interface dans les pfSense.
Le soucis est que pour les interfaces taggués, el CARP dysfonctionne completement (et que pour ces interfaces là!), chaque FW se voit comme master.
Je n'arrive pas à m'expliquer pourquoi.

ccnet

Vous ne dites rien, ou presque, des configurations mises en œuvre. Plusieurs dizaines de Pfsense ... intéressant ou inquiétant. Les structures que je connais qui comptent un tel nombre de firewalls ont des volumes d'activités qui avoisinent ou dépassent 100 milliards d'euros. Je suis dubitatif.
Impossible de dépasser les généralité sur votre problème compte tenu des informations communiquées très générales.
Cela dit problème connu :
https://forum.netgate.com/topic/101920/vlan-on-lagg-with-ha-carp-both-nodes-show-master-for-each-vlan/4

Barikad

Désolé, je n'ai certainement pas été clair.
Lorsque je disais que l'on avait plusieurs dizaines de pfSense, c’était surtout pour illustrer que nous connaissions le produit depuis de nombreuse années. La plupart de ceux ci sont des appliance servant à monter des tunnels depuis nos différents sites. Mais nous avons aussi des clusters, 4 au total.
Chacun de ces clusters et composé de deux appliance virtualisées avec vmWare.
Chacun utilise donc pfsync, et des VIP CARP.
Le HA fonctionne parfaitement bien sur chacun.
Sauf, qu'il existe une limite de 10 interfaces par machine virtuelle chez vmWare. Et pour un des ces clusters, nous avons besoin de plus d'interfaces.
Nous avons donc 9 interfaces, chacune dans un vlan différents, et une interface en trunk (qui laisse passer tous les vlans).
Dans pfSense nous créon donc des interfaces vlan sur cette dixième interface. Tout fonctionne bien, sauf CARP, les deux firewall se trouvant comme master, et ce, uniquement pour les interfaces vlans.
Par ailleurs, j'avais fait une recherche dans le forum avant de poster, et j’étais tombé sur le thread que vous citez. J'ai peut être raté quelque chose, mais dans le cas de figure, mes interfaces vlans se voient bien entre elle (ping depuis un firewall vers le second), donc il n'y a pas de pb de connectivité

ccnet

Nous avons donc 9 interfaces, chacune dans un vlan différents, et une interface en trunk (qui laisse passer tous les vlans).
Dans pfSense nous créon donc des interfaces vlan sur cette dixième interface.

Je ne comprend pas.
On ne sait toujours pas comment cela est configuré.

Barikad

voilà un schema sommaire de l'architecture: https://pastebin.com/dkqSwB5W

chaque interface dispose de son adresse ip dans son reseau, et il y a une VIP CARP par reseau
dans le schema les VIP des vlans 10 et 11 sont bien redirigées vers les interfaces d'un seul master (pfsense1) et bascule sur le second lorsque c'est necessaire
les VIP CARP des interfaces vlan 12 et 13 sont par contre master sur les deux.

Pour etre encore plus précis, prenons le cas du vlan13.
L'interface vlan13 sur pfsense 1 dispose de l'adresse 10.104.155.252
L'interface vlan13 sur pfsense 2 dispose de l'adresse 10.104.155.253
Une VIP CARP est crée avec un ID CARP unique et une adresse en 10.104.155.254

Le status CARP va m'indiquer systematiquement MASTER pour cette interface sur les deux pfsense.

Dans le cas des interfaces en "mode access" (vlan 10 et 11 sur le schema) je n'ai pas ce comportement.

Est-ce plus clair ?

awebster

Barikad,
J'ai déjà passé par ce chemin, donc c'est avec un bon niveau de confiance que je te dis que le problème que chaque FW se voit comme master sur les interfaces taggués est fort probablement due aux permissions attribués aux VLANs ou à la vSwitch dans VMWare...
Pour que CARP fonctionne correctement, il faut permettre le VLAN ou la vSwitch d'opérer en mode de promiscuité, accepter les changements d'adresse MAC et de permettre les transmissions forgées. Et de bien comprendre les implications vis-à-vis la sécurité du réseau, lorsqu'on active ces paramètres!

0_1532371295553_744014a0-c77a-4ade-a9f5-780a1d40a673-image.png

Barikad

@awebster et bien c'est déjà le cas, sinon ça ne marcherait pas sûr les autres interfaces (celle en mode access). Le problème existe uniquement avec les interfaces vlans

awebster

Autres choses à vérifier:

Qu'il n'y a pas de switch utilisant HSRP, VRRP ou XRRP sur le VLAN, ou si oui que ton choix de VHID n'entre pas en collision avec.
Qu'il n'y a pas de filtrage multicast dans ton réseau qui pourrait empêcher le flux des paquets CARP.
Que le VLAN trunk sur VMWare indique le VLAN 4095 pour que tous les VLANs connus par la vSwitch sont livrés à l'instance.
Que les mêmes configs (promiscuité, changements d'adresse MAC et permettre les transmissions forgées) sont appliqués au VLAN trunk.
Que l'interface au niveau pfSense est la même des deux cotés (ex: vmx1 des deux cotés).
Que les VLANs sont mappés 1 pour 1 (c-a-d VLAN 10 sur l'instance primaire = VLAN 10 sur l'instance backup).
Que chaque VLAN utilise un VHID unique, ainsi que des VHID unique pour IPv4 et IPv6 si les deux sont présents dans un même VLAN.

Après toutes les vérifs ci-haut, sur l'instance qui devrait être backup, fermer le HA et ensuite en SSH faire:
tcpdump -e -n -i <interface> -s 0 -T carp multicast et voir si tu reçois les paquets VRRPv2 en provenance de l'instance primaire.
Ça devrait ressembler à ceci:

09:04:00.077221 00:00:5e:00:01:f6 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: xxx.xxx.176.43 > 224.0.0.18: CARPv2-advertise 36: vhid=246 advbase=1 advskew=0 authlen=7 counter=11725467964364491931
09:04:01.089294 00:00:5e:00:01:f6 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: xxx.xxx.176.43 > 224.0.0.18: CARPv2-advertise 36: vhid=246 advbase=1 advskew=0 authlen=7 counter=11725467964364491931

Bref la fin de l'adresse MAC source correspond au VHID, dans mon cas 246 = 0xf6, et l'adresse IP source xxx.xxx.176.43 correspond à mon instance primaire.

Si tu vois les paquets arriver, vérifie les valeurs Advertising frequency et Skew au niveau de l'adresse virtuelle CARP sur l'instance backup.
Personnellement, je trouve que ADV FREQ=10 et SKEW=100 sur l'instance backup marche mieux que les valeurs par défaut.

Finalement, si tu ne vois pas les paquets arriver, le problème est dans ton infra VMWare ou réseau, donc faire du sondage de la source jusqu'à la destination pour voir où ça drop.

Je te confirme que ce que tu veux faire marche, j'ai plusieurs paires en VMWare montés en HA qui marchent A-1.
Bon courage!