ben par exemple, tu essaie de faire passer des icmp dans un vpn, un coup ça marche un coup ça ne marche pas ...
autre exemple: tu essaie de nater des icmp ... a ben non, l'interface ne "veut" pas, on ne peux nater que du tcp ou de l'udp mais pas de l'icmp ???? (ou alors il faut TOUT nater). Cet exemple de nat me semble démontrer que l'implémentation de ce bordel est pour le moins bizarre: le NAT ca se fait au niveau IP, puis de temps en temps avec des astuces dans les couches supérieures, mais rien ne devrait empecher de le faire au niveau IP (donc en dessous de icmp ...).
ce n'est pas parce que l'interface est graphique que ce sont des couillons qui l'utilisent
je ne pense pas avoir écrit cela. Quand on me dit "l'interface graphique permet a tout le monde de comprendre les règles", cela ne me rassure pas. Je ne veux pas que "tout le monde" comprenne les règles, mais seulement les experts ... les autres n'ont rien a foutre devant la console.
Sinon, il est possible (et simple) de gerer plein de firewall en parallele avec des scripts et du ssh, pas besoin de console sous windows lennnnte a mourrir (lecture du log ... ouarf, inutilisable sauf a acheter un produit checkpoint dédié supplémentaire !!!)
Je connais pas mal les nokia, effectivement il y a tcpdump mais aucune solution pour sniffer dans les tunnels par exemple (alors que "tcpdump -n -i ipsec0" le fait bien). Quand a faire tourner checkpoint sur une redhat, la cela me depasse carément vu que iptables est déja la.
honnetement, j'ai pas mal l'habitude de checkpoint, des pix (pas si cher que ca pour les pix 515 et tellement beau comme méthode de clustering), et de iptables.
checkpoint est "beau" au départ, et puis viens le problème des upgrades, des sauvegardes, de la restauration, de la duplication de configuration.... rien ne marche comme prévu (ou logique). Par exemple, il te manque un node a ton cluster checkpoint (il est physiquement en panne), impossible de changer les règles sur le "cluster", message d'erreur a cause du node manquant et hop abandon....
les pix ont leur soucis également (nat pas simple, voir impossible dans certains cas ou la "grammaire" du pix ne permet pas d'exprimer ce que l'on veut faire), mais au moins tout ce qui est prévu fonctionne normalement !!
un bémol cependant, quand je parles de checkpoint, c'est la v4.x la migration vers NG était tellement chère qu'on s'est abstenu et avons jeté l'ensemble des nokia+checkpoint lors de la dernière faille de sécurité. OUF !!
[^] # Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG . En réponse à la dépêche Article sur la haute-disponibilité de firewalls sur OpenBSD. Évalué à 2.
ben par exemple, tu essaie de faire passer des icmp dans un vpn, un coup ça marche un coup ça ne marche pas ...
autre exemple: tu essaie de nater des icmp ... a ben non, l'interface ne "veut" pas, on ne peux nater que du tcp ou de l'udp mais pas de l'icmp ???? (ou alors il faut TOUT nater). Cet exemple de nat me semble démontrer que l'implémentation de ce bordel est pour le moins bizarre: le NAT ca se fait au niveau IP, puis de temps en temps avec des astuces dans les couches supérieures, mais rien ne devrait empecher de le faire au niveau IP (donc en dessous de icmp ...).
ce n'est pas parce que l'interface est graphique que ce sont des couillons qui l'utilisent
je ne pense pas avoir écrit cela. Quand on me dit "l'interface graphique permet a tout le monde de comprendre les règles", cela ne me rassure pas. Je ne veux pas que "tout le monde" comprenne les règles, mais seulement les experts ... les autres n'ont rien a foutre devant la console.
Sinon, il est possible (et simple) de gerer plein de firewall en parallele avec des scripts et du ssh, pas besoin de console sous windows lennnnte a mourrir (lecture du log ... ouarf, inutilisable sauf a acheter un produit checkpoint dédié supplémentaire !!!)
Je connais pas mal les nokia, effectivement il y a tcpdump mais aucune solution pour sniffer dans les tunnels par exemple (alors que "tcpdump -n -i ipsec0" le fait bien). Quand a faire tourner checkpoint sur une redhat, la cela me depasse carément vu que iptables est déja la.
honnetement, j'ai pas mal l'habitude de checkpoint, des pix (pas si cher que ca pour les pix 515 et tellement beau comme méthode de clustering), et de iptables.
checkpoint est "beau" au départ, et puis viens le problème des upgrades, des sauvegardes, de la restauration, de la duplication de configuration.... rien ne marche comme prévu (ou logique). Par exemple, il te manque un node a ton cluster checkpoint (il est physiquement en panne), impossible de changer les règles sur le "cluster", message d'erreur a cause du node manquant et hop abandon....
les pix ont leur soucis également (nat pas simple, voir impossible dans certains cas ou la "grammaire" du pix ne permet pas d'exprimer ce que l'on veut faire), mais au moins tout ce qui est prévu fonctionne normalement !!
un bémol cependant, quand je parles de checkpoint, c'est la v4.x la migration vers NG était tellement chère qu'on s'est abstenu et avons jeté l'ensemble des nokia+checkpoint lors de la dernière faille de sécurité. OUF !!