WAN gateway sendto error: 64
-
Bonjour,
Avant tout voici un schéma de l'infrastructure, le tout sur un Proxmox.
Il y a deux pfSense en cluster et deux Virtuals IP :
- WAN 10.9.9.4
- LAN 10.0.0.4
Et la gateway pour le WAN est 10.9.9.1.
Par moment, le pfSense master perds le ping vers la gateway :
GW_WAN 10.9.9.1: sendto error: 64
GW_WAN 10.9.9.1: sendto error: 64
GW_WAN 10.9.9.1: sendto error: 64Et ce sans savoir pourquoi... Du coup les VM perdent l'accès à internet.
Quand je teste de pinger depuis le master la WAN gateway 10.9.9.1, ça ne fonctionne pas. Par contre depuis le slave, aucun problème. Sauf que le master est encore 'up', donc le slave ne prends pas le relais.La seule solution à ce jour est de redémarrer le pfSense master pour qu'il reping la passerelle.
Au niveau de la virtualisation, les cartes sont en E1000. J'ai bien tenté de les mettre en VirtIO mais je rencontre des problèmes de connexion même en activant "Disable hardware checksum offload". Parfois les cartes VirtIO ne sont même pas détectés par pfSense...
Du coup je suis complètement dans l'impasse, les logs ne me fournissent rien de probant, le problème semble à la fois extérieur à pfSense (problème de ping/connexion à la WAN gateway) mais quand je redémarre le master, cela reprends la main pour quelques heures.
Avez-vous une piste ?
Merci ! N'hésitez pas si vous avez besoin de plus d'informations.
-
Salut salut
Déjà pourquoi ne pas tester avec un seul pfsense avant de partir sur du cluster.
1 - Pour valider si c'est un paramètre de base qui n'est pas bon, faire avec un seul pfsense.
2 - un cluster de pf sur du virtuel, c'est moyen par si l'hyperviseur est bancal vous aurez des effets de bords que vous pourriez attribuer à la vm et non à l'hébergeur. (je peux comprendre l'impossibilité de faire autrement.
3 - nota que pour du HA c'est les hyperviseurs que j'aurais doublé et mis en place en basculement de vm, cela impact moins le SI.Bon courage
-
Hello,
Merci, en effet pour ton point 1. c'est ce que nous comptons faire histoire d'éliminer un vecteur.
Pour les points 2/3, grosso modo : projet d'études de master, obligation de remplir certains critères coté infra, sys, dev... Avec les moyens financiers d'étudiants. Donc pas le choix, bien que je sois largement d'accord avec toi...
-
Bravo pour le schéma ...
La virtualisation, c'est intéressant pour économiser du hardware.
Mais cela a des contraintes ...
En particulier, il faut maitriser l'aspect réseau de la virtualisation pour l'hôte choisi.
(Je n'ai rien contre Proxmox, bien au contraire, mais un esx, même gratuit, c'est très bien aussi ...)Premier principe : éviter de virtualiser un firewall (même si des solutions pro le proposent) : une bonne séparation physique est toujours plus sûre
Deuxième principe : séparer firewall et VM. Idéalement il faudrait séparer chaque hôte en fonction des VM, mais ça un coût, et il faut faire confiance aux VLAN.
A partir d'un PC avec 2 cartes ethernet (WAN/LAN), 4 G de mémoire.
Question : quel config est plus fiable ?- pfSense installé depuis cd ou usb
- proxmox ou esxi installé, puis une VM pfSense
- proxmox ou esxii installé, puis 2 VM pfSense en mode cluster
AMHA la première config sera certainement la plus fiable, puis la 2 et enfin la 3.
Fondamentalement 2 VM pfSense en cluster ne seront pas mieux qu'une seule VM, et ne peut être mieux qu pfSense sans virtualisation.(Tatave apporte une réflexion intéressante, que je ne fais que compléter ...)
-
Bien d'accord, sachant que dans ce cas-là le Proxmox est un gros Point of Failure.
Notre projet nous impose de faire une infrastructure avec un peu de tolérance à la panne, un peu de base de données, et de dev, histoire qu'on touche à plusieurs aspects.
Si je pouvais laisser un seul pfSense dans cette configuration, je le ferai bien...
Clairement j'en ai bien ch** pour gérer le flux Proxmox -> firewall. Tout le traffic est automatiquement redirigé via iptables vers le pfSense histoire d'avoir un seul FW à gérer, pour éviter un 'double-firewall'.
Hormis ce problème de gateway qui se perds, ça fonctionne plutôt bien.
Je vais m'atteler à retirer le slave et voir si le problème se reproduit puis je vous fais un retour !
-
Je ne vois pas bien le rôle du pavé 'iptables proxmox'.
Normalement, avec un VM firewall (ou un cluster de 2), le flux de WAN est directement dans la VM.
Si on a un iptables sur le Proxmox, c'est à dire l'hôte de virtualisation, c'est pour éviter un accès à IHM de l'hôte = le https d'admin de proxmox. Au pire on pourrait assurer que des VM ne se cause pas entre-être.
Mais, les VM firewall doivent récupérer la totalité du flux WAN en particulier.
Ou alors vous avez ainsi un double firewall : les règles iptables du proxmox et le pfSense (ou 2 pfsense). -
J'ai réglé mon iptables pour qu'il réponde a la logique suivante :
- Tout les flux UDP entrant sur l'interface publique vont sur le pfSense, qui autorisera certains si nécessaire
- Tout les flux TCP entrant sur l'interface publique vont sur le pfSense, qui autorisera certains si nécessaires. SAUF 8006 (Webui proxmox) et 22 (SSH proxmox) qui ne sont pas redirigé
-
Bon je reviens avec aucune nouvelles, ce qui veut dire que tout fonctionne depuis environ 20 heures. Ce qui n'arrivait pas avant... En général la passerelle WAN n'était plus pinguée/accessible pour le master en environ 3/4 heures.
Du coup j'ai suivi les conseils de Tatave :
- Désactivé la synchro HA
- "Supprimé" la carte dans les assignations de pfSense
Mes Virtuals IP fonctionnent toujours, aucun soucis sur la trafic, accès externe OK, accès interne OK... Tout roule. Mais pourquoi est-ce-que le fait de retirer la sync HA ne pose plus de soucis vis-à-vis de mon problème ? Je vois pas du tout comment résoudre ça.
Je résume ce qui se passe au bout de quelques heures :
-
pfsense-master :
- Interface WAN 10.9.9.2
- Passerelle WAN 10.9.9.1
- Ne route plus le trafic vers la passerelle WAN car inaccessible pour lui (ping NOK)
- Ne donne pas le relais au slave (normal car le master, en soi, va bien) -
pfsense-slave :
- Interface WAN 10.9.9.3
- Passerelle WAN 10.9.9.1
- Ping sans soucis la passerelle WAN -
pfsense-master + slave :
- Partagnte une Virtual IP coté WAN 10.9.9.4 commune
J'ai l'habitude et n'ai pas peur de fouiller les logs, mais là rien du tout à part :
- gateway sendto error: 64
- Message gateway alarm (je ne me souviens plus exactement)
J'ai également regardé du coté Proxmox au cas où, mais nada dans les logs.
-
salut salut
Bien que pas ressent lisez ce tuto
https://forum.netgate.com/topic/110706/tuto-cluster
Adaptez le en plus à votre sauce, il y a la cerise sur le gateau avec du multi wan.Cela fonctionne depuis la V2.0.0
Pour ma part je suis avec un archi physique comme cela depuis plusieurs années.
Je n'ai eu qu'un gros soucis hardware en 10 ans ou presque.Si vous respecter les actions et paramétage cela devrait fonctionner, comme déjà évoqué si cela ne fonctionne pas cela pourrait bien venir de votre hyperviseur.
Sur esxi j'avais fait un maquettage de full HA avec du pf en front head, juste un soucis avec nic promiscuité qu'il fallait on ou off je ne sais plus cela date pour moi.Bon courage