Nombreuses pertes de paquets sur RED

[Guigou]

Bonjour à tous,

Je rencontre quelques problèmes avec IPCop 2.0.3 que je viens d'installer. J'ai en effet de nombreuses pertes de paquets sur mon interface RED, lors de ping depuis l’extérieur par exemple.
J'ai fait une recherche sur le forum et sur le wiki avec les mots clés "perte paquets", sans succès.

Concernant l'infrastructure, je dispose d'un serveur dédié Kimsufi 24G de chez OVH (Core i7 Quad+HT, 24Go de RAM, 1x2To de disque dur, 1x1Gb Ethernet), j'y ai installé un ESXi version 5. J'ai pris une IP Failover (procédure OVH afin de disposer de plusieurs ip pour un même serveur) sur laquelle passera tout le transit vers les VM.
C'est pour ceci que j'ai besoin d'IPCop, qui fera office de passerelle entre internet et mon réseau virtuel.

A savoir que dans le cas d'une IP Failover, son masque de sous réseau est en /32 et elle est sur un sous réseau différent de celle de la passerelle qui doit être utilisée.
Du coup, j'ai du ajouter les routes suivantes à la main:
route add <ip passerelle>/32 dev wan-1
route add default gw <ip passerelle> wan-1

Mais, après avoir constaté que parfois mes machines virtuelles répondaient mal, ou mettaient du temps à répondre voir pas du tout, je me suis mis en quête du problème, et je constate énormément de pertes de paquets lorsque je fais un ping de mon IP publique (interface RED d'IPCop).
J'ai configuré une VM pour IPCop qui sera suffisante pour ce qu'il a à faire, 1 CPU, 256Mo de RAM et 1Go de disque dur.

Je peux tout de suite écarter les ressources matérielles, j'ai fait un test en coupant toutes les machines virtuelles (sauf IPCop bien entendu) du serveur, et j'ai essayé d'augmenter les ressources de la VM IPCop à 2CPU et 1Go de RAM, avec la même absence de résultats dans les 2 cas.
J'avais d'ailleurs vérifié les graphs systèmes générés par IPCop, sans constater aucune saturation des ressources matérielles.
De même, le problème ne vient pas de chez OVH, j'ai remplacé cet IPCop par une machine virtuelle Windows 2008 configurée de la même façon, et là, plus aucune perte de paquets.

Le problème vient donc bien d'IPCop.
Je n'ai fait aucune configuration particulière, c'est une installation vierge (sans importation de réglages antérieurs).

Que puis-je faire pour solutionner ce problème?

Merci d'avance.

[jdh]

Le problème vient donc bien d'IPCop.

ou de la ... virtualisation !

Il est à déconseiller de virtualiser un firewall si on n'a pas l'expertise nécessaire ...
Par exemple, on peut expérimenter localement pour acquérir l'expérience en lisant (relisant, rerelisant) les docs, réalisant moult tests avec le contrôle exacte de ce qui se passe (tcpdump obligatoire), ...

[ccnet]

[ ... ] 1x1Gb Ethernet), j'y ai installé un ESXi version 5

Rien que là vous êtes déjà totalement en dehors des spécifications d'utilisation d'ESX. Prétendre, à partir de là, qu'ipcop est la cause du problème est bien téméraire. J'y reviens pour la forme, comme mon camarade, un firewall virtualisé c'est exactement le contraire de ce qui est recherché : la sécurité. Je ne sache pas qu'ipcop soit certifié pour être utilisé de la sorte. Et ESX non plus. C'est se mettre en situation pour rencontrer un des problèmes incontrôlables simplement parce que l'on utilise pas les produits dans les conditions pour lesquelles ils sont prévus et ont été testé.

[Franck78]

A savoir que dans le cas d'une IP Failover, son masque de sous réseau est en /32 et elle est sur un sous réseau différent de celle de la passerelle qui doit être utilisée.
Du coup, j'ai du ajouter les routes suivantes à la main:
route add <ip passerelle>/32 dev wan-1
route add default gw <ip passerelle> wan-1

salut,

c'est vrai que c'est casse couille chez ovh cette manie de ne pas réserver une IP gateway valide dans la plage de la fail over...

Ce qui te laisse exactement deux causes :

soit malgré tes nombreuses lectures des 'guides ovh' tu n'as pas correctement transposé sur IPCop.
soit le driver réseau virtuel de esx ne plait pas à ipcop et c'est facile d'en changer.

Pour résoudre ce problème (ip gateway) sur un pfsense virtuel, j'ai effrontément spécifié l'IP x.x.x.1 de la plage de ma failover (enfin un truc pas permis dans le genre mais qui marche). Ne m'en demande pas plus, je ne suis plus chez cet utilisateur.

[Guigou]

Bonjour et merci pour vos réponses.

J'ignorais qu'une telle installation n'était pas recommandée, je prends bonne note. Je n'ai malheureusement que peu de liberté d'action de ce côté, je n'ai qu'une seule IP publique exploitable, et plusieurs serveurs à faire fonctionner dessus.
Je pourrais mettre un Linux et le configurer manuellement, mais n'ai nullement envie d'y passer du temps. Ce serveur me sert à faire quelques tests et n'est pas en production.
En soit donc, les pertes de paquets ne sont pas bien embêtantes, tout au plus un peu gênantes, mais j'aimerais tout de même trouver d'où vient le problème.
J'ai opté pour IPCop car j'ai déjà une installation similaire (sur un ESXi 4 et un IPCop 1.4) sans avoir eu de problèmes de pertes de paquets. Ce n'était pas le même hébergeur, et la configuration réseau était plus "classique".
Pour l'aspect sécuritaire, oui, ce n'est pas l'idéal, mais comme indiqué, je n'ai pas le choix de faire autrement.

J'implique IPCop, un peu facilement c'est vrai,car j'ai déjà fait une configuration semblable, sur d'anciennes versions (comme indiqué ci-dessus), sans rencontrer ces problèmes.

Je n'ai pas encore eu le temps de pousser mes tests plus avant, mais j'essaierai de remplacer le type de carte réseau et de monter une distribution Linux, voir même de tester l'ancienne version d'IPCop, qui avait parfaitement fonctionné à l'époque.

Sinon, peut-être avez-vous des recommandations d'autres distributions Unix clé en main me permettant de faire un simili-routeur/firewall/nat/pat afin d'accéder à mon laboratoire de tests virtualisé et remplaçant avantageusement IPCop?

Merci d'avance pour vos idées et suggestions

[Franck78]

pFsense, pour l'avoir fait.

[Guigou]

pFsense, pour l'avoir fait.

Merci Franck78, je vais regarder ça de plus près