L'éditeur français DynFi®, spécialiste des firewalls Open Source, lance la version 3.0 de son pare-feu DynFi Firewall. Celui-ci s'enrichit d'un filtrage DNS de type RPZ, gagne en stabilité, incorpore la version noyau de Wireguard et dispose de nombreux nouveaux packages.
Amélioration de la stabilité
Avec plusieurs milliers de patches appliqués sur cette version, nous avons fait un effort particulier pour la stabilité du firewall et corrigé de nombreux bugs notamment dans la section d'assignation des interfaces, des VLANs, du NAT et d'une façon générale sur les tests appliqués à tous les packages disposant d'une interface graphique.
Filtrage DNS RPZ avec Unbound
L'équipe de DynFi a développé un système de filtrage DNS basé sur le protocole RPZ, directement appliqué grâce à Unbound.
En plus des développements de la partie front-end, DynFi propose aussi gratuitement l'accès à plus de 60 listes de filtrage issues d'une compilation de listes en libre accès (liste de l'université de Toulouse, shalalist…).
Le tout est agrémenté d'une interface graphique qui permet l'activation des listes et l'accès à des statistiques par thématique.
Des nouveaux packages
Parmi les packages disposant d'une interface graphique, on pourra citer FreeRadius et Wireguard.
Version de Wireguard
La version de Wireguard est celle directement compilée dans le noyau FreeBSD qui offre des performances excellentes et implémente les meilleurs algo de chiffrement (Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF).
Mise à jour de FreeRadius
La version de FreeRadius dispose maintenant d'une nouvelle interface qui simplifie sa mise en œuvre au sein du pare-feu.
Les autres packages sans interface
De nombreux autres packages sont dores et déjà disponibles au sein du pare-feu et disposeront prochainement d'une interface eux aussi.
On pourra citer : ha-proxy, FRR, named, siproxd, bgpd, VBoxControl entre autres.
DynFi cherche à améliorer la documentation de son pare-feu
Si certain d'entre vous souhaitent apporter leur contribution au projet, nous cherchons des personnes avec un bon niveau capable de nous aider dans la rédaction de notre documentation.
N'hésitez pas à nous contacter via notre formulaire.
DynFi est le seul firewall Open Source listé dans le Catalogue GouvTech des solutions numériques proposées par les entreprises aux services publics.
Aller plus loin
- Télécharger la v.3 de DynFi Firewall (192 clics)
- Code source (62 clics)
- Guide de l'utilisateur DynFi Firewall (127 clics)
- Forum en ligne (30 clics)
# S'approprier le travail d'autrui
Posté par Andre Rodier (site web personnel) . Évalué à 7. Dernière modification le 13 avril 2023 à 20:17.
Première remarque, l'auteur de la dépêche n'en a posté que deux, sur ce même projet.
Sur le produit en lui même, cela ressemble plus à une appropriation de projet libre qu'à une participation active.
De ce que je vois, les seules contribution à OpnSense consistent en un patch d'une ligne (voire d'un caractère) et l'ouverture d'un bug:
https://github.com/search?q=org%3Aopnsense+dynfi&type=issues
D'ailleurs, la page github du projet n'est pas reprise comme un fork, mais un projet à part entière.
Il me semble que le mérite du système de filtrage reviens plutôt aux équipes de BSD, de pfSense et d'OpnSense. Aussi, je crois que l'inclusion de wireguard dans le noyau BSD est toujours expérimentale, non ? Quelqu'un peut confirmer.
La liste shalalist est éteinte depuis longtemps.
À part un "rebranding" (changement de marque), je ne vois aucun apport.
PS: Le formulaire de contact, il faut écrire “Merci d’avoir renseigné ce formulaire”, et non “Merci d’avoir renseigner ce formulaire”.
[^] # Re: S'approprier le travail d'autrui
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 7.
Comme il n'y pas un BSD et même si le site d'OpnSense indique "OPNsense is an open source, easy-to-use and easy-to-build FreeBSD based firewall and routing platform.", je vais répondre pour les 3 principaux, cela peut intéresser.
Pour FreeBSD Wireguard est rentré officiellement dans l'arbre des sources avec https://cgit.freebsd.org/src/commit/?id=5ae69e2f10da, comme indiqué sur les notes de version de la 13.2 (https://www.freebsd.org/releases/13.2R/relnotes/ section General Network).
Concernant NetBSD il est entré dans les source pour la version 10.0 (https://man.netbsd.org/wg.4) et pour OpenBSD en version 6.8 (https://man.openbsd.org/wg).
Dans tous les cas, ce n'est plus expérimental pour les 3, en tout cas rien ne semble indiquer que ça soit encore le cas.
[^] # Re: S'approprier le travail d'autrui
Posté par moulator42 . Évalué à 0.
On voit également "Proxmox" dans les produits : à part fournir des appliances avec Proxmox installé et du service, je ne vois pas en quoi est le "produit"…
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . Évalué à 8.
Nous sommes partenaires silver de Proxmox - revendons les abonnements proxmox-VE prix coûtant et contribuons ainsi au projet que nous connaissons très bien et apprécions particulièrement.
Où est le problème ?
[^] # Re: S'approprier le travail d'autrui
Posté par orfenor . Évalué à 7.
C'est une pratique assez courante. On peut voir plus loin et lire leur page sur le code source de Dynfi firewall : la procédure de construction et compilation y est complètement détaillée ; Opnsense est installé avec poudrière pour que ce soit plus simple. Fournir les scripts et la doc dénote une bonne pratique vis à vis du libre, c'est aussi une forme de retour et c'est assez rare (puisque pas obligé) pour être souligné.
Par contre j'ignorais que l'interface n'était pas libre. Tu en es certain ?
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . Évalué à 10.
Sommaire
Je n'ai posté que deux dépêches sur le sujet car nous sommes une petite structure et que nous n'avons que peu de temps à consacrer à la communication. C'est probablement une faute et nous posterons donc plus régulièrement, c'est promis !
Notre objectif n'est pas de "contribuer au projet OPNsense", nous publions notre code et les équipes d'OPNsense peuvent le consulter et le ré-utiliser si besoin est.
Il y a une équipe de quatre développeurs qui travaille sur le projet à titre d'information, nous avons :
Nous travaillons en ce moment même sur une modification substantielle du package Suricata ainsi que sur un renforcement de l'intégration du filtrage L7 issue d'une coopération avec les équipes de ntop.
Je vous renvoie à un thread assez récent dans lequel j'explique qui nous sommes, d'où nous venons et pourquoi nous avons forké le projet OPNsense. Cela me semble intéressant de préciser cela ici. Sinon tout est mélangé et nous passons pour des imposteurs.
https://forum.opnsense.org/index.php?topic=33414.0
Pour ceux qui ne parle pas Anglais, je vais le traduire:
Bref historique
ToDoo (aujourd'hui DynFi) a été l'un des principaux distributeurs de pfSense en France de 2008 à 2014, à l'époque où OPNsense n'existait pas. Nous avons donc des racines communes avec OPNsense.
DynFi a été l'une des principales sociétés à l'origine de la divulgation de l'escroquerie OPNsense.com organisée par les propriétaires de Netgate. Grâce à notre connaissance approfondie du DNS (nous maintenons le DNS primaire pour un pays) et à notre avocat spécialisé dans les marques et l'OMPI, nous avons aidé Deciso (propriétaire d'OPNsense) à débloquer le verrou "Domain by Proxy" et à récupérer ce nom de domaine. Ce fut une grande victoire pour l'équipe d'OPNsense. Nous avons obtenu deux lignes de crédits dans un obscur billet publié à l'époque.
En 2015 / 2016, alors que nous étions les premiers partenaires (et sponsors) du projet OPNsense, nous sommes venus rendre visite à l'équipe de Deciso en Hollande pour discuter de notre volonté de développer une "solution de gestion centrale" qui n'existait pas à l'époque et nous avons été froidement accueillis avec un "nous ne voulons pas qu'un partenaire développe cela". Pendant les quatre années qui ont suivi la sortie de notre logiciel et dans une certaine mesure jusqu'à aujourd'hui, il n'y a pas de solution de gestion centralisée sur site (On Premise) en dehors de notre propre DynFi Manager.
Compte tenu de cette volonté de ne rien partager avec aucun "partenaire" en ce qui concerne le développement, quels choix s'offraient à nous ?
Développement de DynFi Manager
Ainsi, en 2017, ce qui aurait pu être un beau travail d'équipe, est clairement devenu la fin d'un partenariat.
Nous avons tiré les conséquences du refus de coopération sur le Manager et avons commencé le développement de notre DynFi Manager. La première version a été officiellement lancée en 2018.
Il y a eu plus de 60 versions et correctifs depuis le lancement du DynFi Manager en 2018.
Développement du pare-feu DynFi
Nous avons commencé à développer le DynFi Firewall en 2019 parce que nous pensions qu'il serait intéressant d'avoir une plateforme distincte sans HardenedBSD, mais plutôt directement basée sur le noyau FreeBSD. Il s'avère que nous avions raison car quelques mois après avoir finalisé notre fork, OPNsense est revenu au noyau FreeBSD et a abandonné HardenedBSD.
Je dois ajouter que nous avons notre propre plateforme de compilation et que nous avons fait un peu d'upstream du code d'OPNsense au début (mais Deciso n'a-t-il pas fait exactement la même chose avec pfSense en 2015 ?), plus nous avançons et moins nous faisons d'upstream. […].
Suite de la réponse au flame
Je vais essayer de rester courtois, mais cela frise le n'importe quoi. Avez-vous été voir le code que nous avons produit avant de vous lancer dans ces envolés lyriques ?
Nous avons passé plus de huit mois à mettre au point un filtrage DNS très efficace qui s'appuie sur Unbound. J'ai effectué une vidéo qui explique comment cela fonctionne ici et 100% du code vient de chez nous.
Le système de filtrage DNS RPZ utilise Unbound et permet un filtrage hyper efficace sur plus de 20 millions de sites Internet classés par thèmes (60 thématique de filtrage). A la différence de OPNsense, nous produisons et offrons gratuitement les listes compilées d'URL issues d'un traitement de plusieurs différentes listes ouvertes disponibles sur le Net.
Nous avons en plus ajouté l'exposition de graphiques qui permettent de se rendre compte en temps réel de l'impact des filtrages sur un réseau.
Enfin, sachez que parmi nos équipes, nous avons compté ou comptons toujours :
Ces personnes qui sont des contributeurs BSD de haut niveau vivent ou ont pu être financés sur des années grâce à notre projet et au financement que DynFi leur a apporté.
Les développements que nous avons effectués sur la mise au point de notre système de paquetage ont pu contribuer au projet pkgbase directement utilisé dans FreeBSD.
Donc oui, nous sommes légitimes pour faire un fork de OPNsense, non nous ne sommes pas des imposteurs et j'espère que ce post vous fera changer d'avis sur notre projet.
C'est la seconde fois que vous tentez de descendre notre projet, je ne vois pas vraiment l'intérêt de faire cela ?
Last but not least : vous pourrez apprécier notref vision de l'Open Source dans un article rédigé et publié dans le revue Télécom des anciens de Télécom Paristech qui se trouve ici.
[^] # Re: S'approprier le travail d'autrui
Posté par orfenor . Évalué à 7.
N'y voit pas de complot, il y a souvent des commentaires avec des questions dont la réponse se trouve dans la doc, le forum, l'historique du développement, etc. Maintenant qu'on ne peut plus répliquer RTFM, "les gens" sont devenus feignant et ne vont pas fouiller bien loin.
[^] # Re: S'approprier le travail d'autrui
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 14 avril 2023 à 20:50.
Ne le prend pas contre toi, beaucoup ici ont beaucoup de mal à faire la différence entre leur fantasme sur un open source / libre qui correspondraient à leurs idées (souvent pas très compatibles avec le libre) et la réalité de l'open source / libre (rappel : l'open source / libre n'a absolument rien à faire de l'upstream, du moment où on respecte la licence).
Et pour ces personnes, si tu ne fais pas comme eux veulent de manière arbitraire, tu es forcément dans le camp des méchants.
Que ce soit dit, répété : le libre n'a absolument rien à faire de l'upstream car il s’intéresse à et uniquement à celui qui reçoit (voir la définition de libre par la FSF elle-même, si celle de l'OSI ou DFSG ne vous plaît pas), et le rebranding est autorisé par le libre. Si ça ne vous plaît pas, pas de soucis, faite vos définitions et licences correspondantes (mais soyez conscients que ça sera sans doute non libre…)
Perso, je réagirai encore plus fort :
Que l'auteur de ce commentaire (et ceux qui plussent, nombreux) pointe les changements illégaux de copyright pour argumenter ça, sinon l'open source / libre n'interdit absolument pas le rebranding (et la licence libre l'autorise même, le nom des auteurs de code pris ailleurs doit être dans la documentation et pas besoin de mettre ailleurs, même si c'est que du rebranding), ni le packaging, ni du packaging + code perso, etc, c'est explicitement autorisé par les auteurs upstream, et ça n'a absolument rien à voir avec une appropriation, mot à consonance négative qui fait penser alors à du dénigrement, qui est un délit, mais plutôt à un usage dans le respect de la volonté des auteurs upstreams.
D'ailleurs, il est étonnant (non, car eux sont subjectivement vu comme "biens" par opposition à un upstream vu comme "pas bien") que par exemple Rocky Linux ne soit pas accusé de la sorte alors que bon, ils cachent bien leur upstream sans faire aucune autre modification que le rebranding.
[^] # Re: S'approprier le travail d'autrui
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tu parles de toi ? (moi je suis dehors, en apéro)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: S'approprier le travail d'autrui
Posté par C. OB (site web personnel) . Évalué à 3.
Bonjour .
Je découvre ce projet (que je n'utiliserais pas , car je suis en train de passer de OPNSense à une solution maison sous linux).
Je ne connaissait pas le terme de RPZ, mais après avoir regardé les docs ceci me fait furieusement penser à un DNS Menteur. Dans le cas de DynFi il me semble que votre implémentation autour de Unbound permet de belles performances et serait presque utilisable par un FAI.
Je dois avouer que ceci me rends assez mal à l'aise même si j'en comprends la finalité. Et le fait que ce soit par listes , même si ces listes sont publiques, me dérange d'autant plus par le manque de contrôle que ça implique.
Néanmoins je vous remercie, car ceci justifie d'autant plus de pousser DoH (pas dans son déploiement actuel j'en convient) sur les terminaux personnels.
[^] # Re: S'approprier le travail d'autrui
Posté par orfenor . Évalué à 6.
RPZ ce n'est pas tout à fait ça, c'est un protocole pour mettre à jour les DNS menteur avec des listes (en simplifiant). Comme d'habitude, Stéphane Bortzmeyer explique RPZ avec beaucoup de clarté.
Tu fais allusion au problème politique que peut poser RPZ en facilitant la mise en place de censures, problème qui semble-t-il empêche sa normalisation (cf Bortzmeyer). Sans rentrer dans le débat de la neutralité de la technique, on peut noter que RPZ est déjà utilisé par de gros services, qui n'ont pas eu besoin de DynFI pour le mettre en place. Je vois mal les États être incapables de faire de même.
[^] # Re: S'approprier le travail d'autrui
Posté par gregober . Évalué à 8.
L'idée est d'utiliser cela pour des lycées, des écoles ou des université et des entreprises. Ils ont depuis des années des problématiques de filtrage des sites pour adultes et avec nos 14 millions d'URL notre solution est assez efficace.
Mais effectivement le RPZ neutralise les requêtes DNS et par conséquent fausse le fonctionnement d'un internet transparent.
C'était d'ailleurs un argument de ceux qui n'apprécient pas ces technologies.
D'un point de vue technique on pourra se reporter à l'article de Stéphane Bortzmeyer une référence en matière de technologies liées aux DNS.
Cela a été un argument pour les grosses sociétés qui ont poussé les technos du type DoH (DNS over HTTPS) comme cloudflare, google… Là on ne voit plus rien, les requêtes DNS sont transmises à Cloudflare ou Google et eux ré-utilisent les données de millions d'utilisateurs pour faire un peu tout et n'importe quoi.
Personnellement je suis favorable à :
Le problème de toute technologie de filtrage réside dans son bon usage par ceux qui vont l'utiliser.
# Quelles sont les diffrences avec OPNSense ?
Posté par Astaoth . Évalué à 4.
Comme la dernière fois, même question : quelles sont les différences avec une OpnSense, à part un manager proprio pas très intéressant ?
En un an et demi cette question n'a jamais été répondue de façon claire et détaillée.
Emacs le fait depuis 30 ans.
[^] # Re: Quelles sont les diffrences avec OPNSense ?
Posté par gregober . Évalué à 3. Dernière modification le 14 avril 2023 à 16:59.
La plupart des développements sont détaillés ici :
https://dynfi.com/produits-dynfi/firewall/releases-dynfi-firewall/
Et les release de nos produits exposées ici:
https://dynfi.com/forum/viewforum.php?f=3&sid=8c345fffe9466b83429af57abde3807e
[^] # Re: Quelles sont les diffrences avec OPNSense ?
Posté par Astaoth . Évalué à 3.
Le premier lien d'indique pas les différences avec les Opn/Pf/Sense. Egalement, les vidéos/audio qui se lancent en auto sur les pages webs c'est particulièrement agaçant et ne donne pas envie de continuer la navigation.
Dans le second lien, je ne vais honnêtement pas me taper la lecture des 95 annonces pour enfin avoir la réponse à ma question. À ma connaissance, c'est pas moi qui cherche à vendre un firewall, je ne vois pas pourquoi je devrais lutter pour trouver ces infos demandées depuis 1 an et demi.
Ce qui démarque ce fork par rapport aux logiciels d'origine n'est toujours pas indiqué dans les pubs lancées sur LinuxFR, donc pour le commun des mortels ca reste juste un gros repompage d'Opn/Pf/Sense avec un manageur proprio en plus.
Emacs le fait depuis 30 ans.
# Dommage...
Posté par Kptainflintt . Évalué à 3.
A la lecture de ce post, je me suis précipité sur le téléchargement de la v3 mais malheureusement, installation toujours impossible (au mieux fastidieuse) sur des appliances là où OPNSense s'installe en 5 minutes sans avoir à débugger…
Reste à voir si en VM la stabilité a été améliorée par rapport à la dernière version mais ça part mal.
J'ai réellement envie de donner une chance à ce projet mais pour l'instant, hors de question de le mettre en production
[^] # Re: Dommage...
Posté par gregober . Évalué à 5. Dernière modification le 15 avril 2023 à 23:55.
Sur quel type d'appliance / ordi avez-vous peiné à l'installer ?
Normalement cela fonctionne très bien.
Plusieurs posts peuvent vous aider dans la phase d'installation :
- notre documentation sur DynFi Firewall qui précise la façon d'installer l'OS
- le tuto Youtube post sur la façon de créer une clé bootable
- ce second tuto YouTube sur la façon d'installer DynFi Firewall sur une VM
Enfin si vous avez un retour à nous faire ou des remarques qui peuvent nous être utiles, ou des questions, n'hésitez pas à utiliser notre forum. Nous répondons rapidement et efficacement.
Un point à noter, DynFi Firewall embarque tous les programmes dans son installeur, le volume de données à installer est donc plus important.
D'une façon générale, il faut prévoir un minimum de 2GB (4GB ou + c'est mieux) de RAM et une appliance type APU au minimum (avec un proc dual ou quad core même de petite taille et un min de 1GHz).
Vous aurez de toute façon besoin de puissance pour exploiter pleinement certaines des fonctions du pare-feu (filtrage RPZ, Proxy, Ntop et Nprobe, …).
[^] # Re: Dommage...
Posté par gregober . Évalué à 4. Dernière modification le 16 avril 2023 à 00:19.
Vous dites "impossible", est-ce que vous pensez que nous publions une troisième version après trois années de développement et que l'installation du système est "impossible" ?
Essayez de donner plus de contexte.
Pour le moment vous n'êtes pas parvenu à installer le logiciel ou vous avez eu du mal à l'installer.
La plupart du temps ces problèmes proviennent de clé USB de mauvaise qualité, de corruption de l'image au niveau du transport ou de problèmes de cette nature.
Je vous garantie que l'installeur fonctionne.
Il vous faut une clé avec 2GO de stockage minimum, je vous recommande les clés Corsair Voyager. Après plusieurs milliers de gravures, ce sont les seules qui tiennent vraiment la route.
Sur des médias lents, vous pouvez avoir un peu de latence au niveau de la détection des disque et des instructions "camcontrol" de FreeBSD.
[^] # Re: Dommage...
Posté par Kptainflintt . Évalué à 0.
Bonjour,
Autant votre première réponse est acceptable, autant je trouve la deuxième très agressive et condescendante!
Donc puisque vous insistez, je vais vous donner plus de contexte :
Installation d'un cluster Vsphere chez un client, je lui propose d'utiliser DynFi pour protéger l'infrastructure que je présente comme une excellente solution. Installation d'une VM sur le cluster.
Résultat : impossible de se connecter à l'interface Web, débit de l'infra plafonné à 10mb/s.
Après 1h de recherches, je décide d'installer à la place OPNSense : plus aucun problème.
Tentatives d'installation sur trois types d'appliances différentes que j'utilise régulièrement avec OPNSense sans rencontrer de problèmes. Avec de la patience car j'ai réellement envie de donner une chance à votre projet, je trouve deux modèles qui acceptent l'installation de DynFi. Pour un modèle en revanche impossible (sûrement un problème de matériel non reconnu).
Bien entendu j'ai utilisé deux clés USB différentes et téléchargé deux fois l'ISO, j'en suis spas à mes premières installations.
Bref, j'ai toujours défendu votre projet et l'ai présenté sous un très bon jour aux personnes autour de moi mais je vous avoue que votre message me donne envie de ralentir franchement.
Comme indiqué je n'ai pas encore réessayé sur des environnements virtualisés mais là tout de suite j'ai plus envie.
A bon entendeur
[^] # Re: Dommage...
Posté par gregober . Évalué à 4.
Nous n'avons pas directement testé l'installation sous ESXi car nous utilisons Proxmox.
Cependant je vous garantie que cela fonctionne très bien sous KVM.
Tellement bien que nous avons fait une vidéo qui détaille étape par étape l'installation de DynFi Firewall sur un hyperviseur Open Source, en l'occurence Proxmox v.7.x
Par ailleurs nous utilisons Proxmox-VE comme plate-forme pour nos tests unitaire et debug.
Nous allons essayer de monter un PoC sous VMWare ESXi, juste pour pouvoir être précis dans nos réponses. Il serait particulièrement étonnant que cela fonctionne très bien sous KVM et pas sous ESXi…
Ok, c'est déjà assez différent de ce que vous exposiez initialement…
Donc deux devices sur trois fonctionnent.
Nous avons un forum DynFi ou vous pouvez poser vos questions et sur lequel nous essayons de vous répondre et vous aider.
Euh… Non vous n'avez pas du tout "toujours défendu notre projet", vous avez même fait un gros flame dans lequel vous indiquez que "rien ne fonctionne", sans aucun argumentaire.
On a apparement pas la même notion de ce que c'est de "défendre un projet" Open Source.
Ah là j'avoue ne plus vous suivre…
Vous indiquez que cela ne "fonctionne pas sous VMWare" et ici vous indiquez que vous n'avez pas encore "réessayé sur des environnements virtualisés" ??
Or il me semble que VMWare ESXi est un "environnement virtualisé"…
Franchement ce n'est pas très sérieux.
Pour une réponse claire, il est nécessaire de préciser :
- quelle version de DynFi Firewall avez-vous installé ?
- à partir de quelle média l'avez-vous installé (installation VGA ou Série) ?
- pour une installation sur un serveur virtualisé il faut utiliser une image VGA
- s'il y a des problèmes à l'installation (ce que nous n'avons pas constaté), remontez-les sur le forum
Le problème de fond vient de votre premier post où vous indiquez que "rien ne fonctionne" et en insistant un peu on s'aperçoit que :
Nous avons spécifiquement travaillé sur l'amélioration de la stabilité à tous les niveaux sur la v.3 qui s'installe très bien, sur les systèmes virtualisés ou sur des appliances i386 ou amd64, sauf exception.
[^] # Re: Dommage...
Posté par Kptainflintt . Évalué à 0.
Et ben, on peu dire que vous savez répondre aux gens avec tact et délicatesse vous…
Donc je fais une dernière réponse et après j'arrête, car entre le sentiment d'être pris pour une andouille ( pour une installation sur un serveur virtualisé il faut utiliser une image VGA, sans déconner?)
Donc :
Vous indiquez que cela ne "fonctionne pas sous VMWare" et ici vous indiquez que vous n'avez pas encore "réessayé sur des environnements virtualisés" ??
Oui, en fait en langue française on a l'habitude d'ajouter le préfixe "re" quand on veut signifier une répétition. Donc :
1. J'ai essayé et ça a été un vrai désastre
2. Je n'ai pas réessayé.
Je ne vois pas ce qu'il y a de compliqué à comprendre, mais comme vous êtes visiblement doté d'une intelligence supérieure à toutes les personnes ici, quelque chose doit surement m'échapper…
Comme je ne suis pas rancunier, j'ai tout de même, avant de récrire cette réponse, REtenté (notez bien le "RE") une installation, je vais donc détailler cette fois-ci l'environnement :
Autre test sur Workstation Pro (environnement virtualisé donc):
- VM avec 2 vCPU, 4 Go de RAM, 16 Go de disque
- Installation OK
- Assignement des interfaces : blocage sur "Starting router advertisement services…done"; au bout de 10 minutes (de 9h29 à 9h39 pour être précis), j'annule l'action
- Les modifications avaient bien été prises… bon d'accord, l'essentiel c'est le résultat comme on dit.
- J'assigne l'adresse IP de ma LAN : OK
- Je me connecte à l'interface Web : idem que sur le matériel physique… Page blanche qui tourne en boucle, puis page de login minimaliste, puis page blanche qui tourne en boucle.
Alors oui je sais j'aurais pu tester sur mon Proxmox, mais votre but n'est-il pas que votre solution soit la plus largement utilisée sur les environnements courants? Non? Ah bon…
Donc j'ai deux solutions qui fonctionne dans tous les cas de figure (pfSense et OPNSense) et une troisième quand elle veut. Je ne travaille pas dans la recherche, je n'ai donc pas le temps de faire du troubleshooting à chaque fois que je met en service un firewall, si j'ai deux solution qui fonctionnent et une qui ne marche qu'un coup sur deux et dont le DG m'envoie bouler à chaque fois en ne reconnaissant jamais qu'il est possible qu'il y ai un problème de leur côté, quel est mon intérêt?
Avoir des problèmes sur des projets opensource c'est normal, le problème n'est pas là. En revanche, refuser d'admettre que la cause peut se trouver chez vous et tout rejeter sur l'utilisateur en le prenant pour un débile démontre un certains mépris qui pour le coup me dérange beaucoup.
Et pour en revenir à la défense de votre projet, oui, je l'ai défendu plusieurs années, j'ai une vie en dehors d'Internet que vous résumez à un seul post sous un article, j'en ai parlé en bien à mes collègues Freelance, à mes clients, à mes partenaire et à la soixantaine d'élèves que je forme chaque année.
Pensez bien M. BERNARD que c'est désormais terminé.
Bon courage pour la suite, répondez ce que vous voulez, lâchez vous…
# Sympa :)
Posté par watchix . Évalué à 3.
ça fait plaisir de voir un autre éditeur FR sur la scène des firewalls.
Peut-être qu'avec votre label "Cybersecurity Made in Europe" nous pourrions enfin proposer a des clients une solution firewall libre…
Est-ce que vous avez des contacts avec l'ANSSI ?
Car hormis Stormshield en certifié ANSSI il n'y a personne… ce qui je pense ne les pousse pas à "innover" et restent dans leur zone de confort.
[^] # Re: Sympa :)
Posté par gregober . Évalué à 2.
Bonjour @watchix - merci pour votre message.
Nous avons été en relation avec l'ANSSI par la passé.
Mais le coût d'une certification est assez élevé, aux alentours de 50k€ pour une CSPN (Certification de Sécurité de Premier Niveau) (Critères communs) et au-delà des 100K€ pour une certification CC (Critères Communs). Il faut aussi compter ±30 jours/homme.
Il faut que nous regardions s'il est possible d'obtenir une aide pour passer ces certifications.
Mais oui, cela nous aiderait probablement.
# Guide d'installation DynFi Firewall pour ESXi
Posté par gregober . Évalué à 1.
Certaines personnes dans ce thread mentionnait "l'impossibilité d'installer DynFi Firewall sous VMWare ESXi"—nous avons donc créer un guide qui détaille comment installer DynFi Firewall sous ESXi >> https://dynfi.com/documentations/dynfi-firewall/how-to/guide_deploiement_DynFi_Firewall_ESXi.html
Et cela fonctionne très bien !
;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.