Les offres ne manquent par sur A, AE, BG, ... et G permet de trouver encore d'autres distributeurs ... Les fabricants indiquent bien souvent que la distribution est supportée ...

Prenez vous par la main :

le modérateur (absent) du forum français gère un tel site ... ou, sélectionnez un produit ou une marque, indiquez la référence et demandez si quelqu'un a de l'expérience avec ...
(il y a eu de tels fils par le passé !)

@awebster Salut et merci pour ton retour,

J'en était arriver a la même conclusion que toi.

@jdh said in PFsense avec samba 4:

Je n'ai pas la réponse

A défaut de connaitre la réponse, je donne des idées qui, normalement, permettent d'atteindre une solution.

C'est mieux que de ne pas répondre, non ?
C'est mieux que d'être ironique, non ?

Le boot, ce n'est pas le menu du tout début ?

Encore une fois, le 1er lien de 'freebsd boot' donne le message exact (mais pas la solution). (Le 3ième lien c'est en français).

Mais la recherche 'pfsense boot menu' donne la réponse dans le groupe de 2ième lien. Quelle surprise, c'est ce forum, certes en anglais mais ...

Il faudrait vraiment que vous changiez de méthode : la recherche par soi-même est IMPORTANTE.

(Ou alors il faut que vous coupiez ce que vous avez dans la main ...)

Votre question était résolue ... avec le 1er lien de la recherche G 'pfsense documentation dhcp'. (pas le 5ième lien de la 3ième page !)

Plutôt que faire des commentaires sur les autres, vous pourriez reconnaitre que, franchement, vous vous y êtes pris TOUT SEUL 'comme un gland', parce qu'il n'y avait pas lieu DU TOUT à créer un fil. (Ca demande beaucoup de reconnaitre ...)

NB : Knight, que vous remerciez, vous a donné une réponse 'partielle', mais avez vous saisi la subtilité ?

Seneque a écrit (vers 65) : Il n'y a pas de vents favorables pour celui qui ne sait pas où il va.
Peut-être que, demain, votre premier (nouveau) réflexe sera 'la doc' ...

@free4 Merci pour ces précieux renseignements.
J'ai contacté le support, nous verrons, bien.
Je vais faire une installation sur une machine.

Concernant le portail captif, le freeradius est bien évidemment sur une vm distincte. Sa connexion avec une bdd mysql fonctionne plutôt pas mal. J'ai esayé Daloradius mais ce me semble trop lourd pour l'utilisation que je veux en faire. Nous avons déjà une bdd avec les personnes qui utiliseront les postes publics. Évitons au maximum les saisies inutiles. J'adapterai les requêtes freeradius<>mysql.

C'est une excellente idée d'utiliser les logs dns pour le rgpd.
Les postes qui vont se connectés au portail captif sont des postes utilisés par des personnes différentes. Ils sont mis à disposition. Ce qui m’embête le plus c'est de faire le lien entre qui se connecte et où il se connecte , sans devoir utiliser deux tableaux de logs. Et tous çà dans 20 lieux différents, et dont certains lieux ne sont pas sur notre vpn et donc pas dans un sous réseau sur lequel nous avons la main. :)

Face à un tel problème, il y a 2 façons de le résoudre : la documentation et la réflexion.

Pour la documentation,

on cherche 'pfsense documentation' : le premier lien est bien sûr vers docs.netgate, ce qui est correct, parmi la liste des chapitres, on trouve 'Multiple WAN connections', click, et dans la liste de (sous-)chapitres, on trouve 'Terminology and Concepts', click, dans ce chapitre, on a les éléments de compréhension.

Pour la réflexion,
par exemple, on se dit le flux http via une sortie Wan donnée,

Dans Firewall > Rules, on créé une règle, on indique la source, par exemple le LAN subnet, on indique le protocole, par exemple http, on voit un champ 'Gateway', qui est une liste de noms définis lors de la création des interfaces WAN.

A ce point, on doit se poser la question

je suis en train de définir une règle de flux, qui concerne le LAN, et je peux choisir une 'gateway' qui est définie pour une interface WAN, pourquoi ?

Ne serait ce pas le moyen de choisir par quelle interface (WAN) ce flux passe ?

Evidemment Oui ! Et c'est trouvé juste par la réflexion d'un élément présent dans l'interface, sans même lire la doc ! (Bien sûr la doc confirme et détaille, forcément.)

Chaque démarche prend combien de temps ? Assez peu. Parce que le multi-WAN est assez fréquent et donc banal.

(Bien évidemment, je préconise de toujours bien lire la doc dans tous les cas, même si la démarche de réflexion permet d'aller vite à la mise en oeuvre.)

Un forum c'est de l'entraide, oui MAIS après la recherche de la doc, sinon c'est un forum d'assistés total. (On en est là : je suis presque seul, et sans doute le dernier, à encore répondre, car, vous et vos semblables ont fini par lasser les plus tenaces !)

Et un forum sans aucun respect tant pour les sachants que pour les ignorants, n'est pas un forum ! (idem à plus haut)

Maintenant, il y a 2 choix :

soit vous continuez dans votre attitude lamentable et irrespectueuse, soit vous reconnaissez que vous n'avez ni cherché ni réfléchi.

J'ai fait l'effort de montrer la démarche, pourtant peu difficile, et j'avais laissé un peu de temps avant de réponde, tellement c'était prévisible que vous êtes toc ...

@yazur
Merci de votre retour,

NB :
sur un PC (Windows) qui se connecte en 'roadwarrior' via OpenVPN (en 'client-to-site'), on installe un client OpenVPN et le driver 'TAP' (fourni par OpenVPN.net). MAIS la config (le fichier .ovpn) indique comment ce driver est utilisé : typiquement : client, dev tun , proto udp, port 1194, remote (SERVER), ...

Il est clair que selon 'dev TUN' ou 'dev TAP', le fonctionnement n'est pas le même, et OpenVPN recommande (fortement) le mode routé = dev TUN. (La formule est 'quand vous ne savez pas, utiliser TUN' !)

Ce fil est ce qu'il ne faut pas faire :

TRES peu d'information : le tuto suivi n'est même pas indiqué, aucun réglage n'est indiqué, le formulaire de présentation de A LIRE EN PREMIER n'est pas indiqué : c'est utile pour les lecteurs ... comme pour le rédacteur, un réaction qui relève ces faiblesses avec une réponse limite insultante, un retour qui rappelle les éléments clés, un post qui montre que, oui, le tuto n'a pas été bien suivi et adapté (c'est rare de le reconnaitre), un humour inutile et déplacé/exagéré.

Plus d'informations (beaucoup plus), plus de vérifications, plus de recherches préalable (toujours beaucoup), un profil plus modeste, et moins de polémique, tout cela aurait permis un fil plus léger, plus agréable, ...

NB : j'ai installé et configuré des Stormshield dans une vie antérieure, et le VPN SSL de ces matériels est juste un OpenVPN moins finement configurable ...

Brute, la réponse est non.

Pendant quelques années, j'ai géré, pour une entreprise PME, des pfsense (que j'avais choisi). Il y a eu des questions que je n'avais aucunement préparé lors de la mise en place: j'en fait part parce que cela peut être utile ...

La gestion de certificats de pfSense est simple et facile à utiliser, mais incomplète. Si elle a le mérite d'être là, il y a des choses à savoir pour bien la faire fonctionner ...

La gestion de certificats c'est

un certificat AC = Authorité de Certification = signature des certificats des certificats pour serveurs, des certificats pour utilisateurs, des listes de révocation de certificats (CRL).

Les questions majeures sont

le renouvellement, la révocation.

En fixant 3650 jours (option par défaut) pour un certificat, on ne pense pas au renouvellement : on voit la révocation avant bien souvent !

Première chose à BIEN comprendre : ne JAMAIS supprimer un certificat !! Cela ne révoque pas celui-ci et empêche de créer une liste de révocation correcte (un certificat supprimé ne peut apparaitre dedans) : le certificat continuera à fonctionner !!! Grave erreur. (Je ne supprime même pas ceux expirés ou renouvellés.)

Deuxième chose : si on révoque un certificat, recréer DE SUITE la liste de révocation (et redémarrer OpenVPN) car c'est elle qui indique au serveur OpenVPN que le certificat est révoqué. La liste devient de plus en plus grande à chaque révocation !

Troisième chose : le renouvellement est juste un nouveau certificat qui se créé assez automatiquement (il faut demander 'Renew'), et il faudra le fournir à l'utilisateur 'comme le certificat initial'.

Mon conseil : si la AC doit avoir une durée longue (10 ans), les certificats serveurs devraient être moins longs (p.e. 4 ans), et les certificats utilisateurs devraient être court (1 ou 2 ans).

En fait, pour la AC, il serait mieux que la durée soit plus courte (2 ans) et que ce soit même un certificat importé = acheté pour l'occasion, ce qui peut éviter la diffusion de la clé publique, mais dans une PME ...

Comprenez moi bien clairement : vos certificats utilisateurs créés pour 10 ans doivent être conservés jusqu'au bout !

Ce qui manque à cette interface :

un bouton pour cacher/montrer les certificats révoqués : ne donnerait pas la tentation de les supprimer ! un serveur web OCSP pour la diffusion de la CRL

NB : j'ignore comment on renouvelle la AC ...