@ccnet:

Je voulais savoir comment faire un LAN géré par PF

Pfsense ne gère pas de réseau. C'est un firewall qui filtre le trafic.
Je ne sais pas si vous avez saisi la porté de la mise en garde de Cris :

Attention cependant: si cette approche va fonctionner, même si elle a peu de sens, pour les adresses "privées" (correspondant donc à ce que décrit la RFC1918), si ton netmask contient des adresses publiques, tu vas perturber le fonctionnement de ton accès internet puisque celles-ci seront considérées comme locales et donc plus routées.

Je pense que oui en disant ça :

Les machines ZZ ne sortent pas de la DMZ, et s'adresse uniquement à la machine A.
La machine A est uniquement adressée, elle ne fait aucun accès vers qui que se soit.
De mon PC, je dois pouvoir accéder à A et au machines ZZ.

J'ai raté quelque chose ?  :(

Cela étant c'est un besoin (encore que vous raisonnez d'emblée en solution technique) pour le moins curieux dont la logique profonde m'échappe.

Par rapport à ça :

il s'agit d'une plateforme de test.
Cette plateforme de test peut recevoir un nombre fini de machines (ZZ), et c'est ces machines qui ont des adresses IP fixes qu'on ne doit pas changer pour les tests.

Je précise que cette plateforme de test reçoit des machines ZZ pour les tester, qui sont remplacer par d'autres machines ZZ, etc…
Oui j'ai donné une solution technique à ce problème dans le but de voir si ça pouvait fonctionner. Mais si il y a d'autres solutions qui répondent à mes contraintes, je veux bien les connaitre pour comparer !

Bonjour,

Merci chris4916 ! C'est beaucoup plus clair maintenant. Et merci aussi pour le conseil sur le DNS. J'avais mis pfsense comme forwarder mais je pensais qu'il fallait au moins autoriser les machines à faire des requêtes sur le port du pfsense.
Encore merci.

@ccnet : Oui et j'avais bien lu la doc et fais des recherches sur le net, mais j'avais rien trouvé de clair. On explique beaucoup de chose quand on a 1 LAN 1 WAN et éventuellement une DMZ, mais rien quand on a plusieurs LANs.

Bonne journée.

Thomas

Regardez sur le forum US, je sujet de l'install de Pfsense sur différents Watchguard est traité.

Le raisonnement de Gertjan est limpide et tellement logique.

Car vouloir modifier les fichiers modèles proposés en standard suppose une certaine hauteur (et une certaine expertise) :

compréhension des mécanismes et successions d'étapes capacité à modifier les fichiers impliqués, avec leur langage (html, les formulaires sous html) capacité inscrire en log les informations reçues (php, syslog ?).

Ce n'est pas très complexe mais assez technique …

A minima la doc pfSense et la recherche dans le forum (toutes langues) sera nécessaire ...

Les débutants devraient lire A LIRE EN PREMIER …

WDS = Windows Deployement Services
En général, quand on veut faire du déploiement (ou masterisation), on dédie un réseau à cela, avec les serveurs PXE, DHCP, TFTP qui vont bien ...

Petit extrait de WDS par wikipedia :

Principe et fonctionnement :

Les services de déploiement Windows fonctionnent au moyen de la technologie PXE (Preboot Execution Environment) afin de lancer une version très minimaliste de Windows appelée Windows PE.

Ce système d'exploitation, une fois lancé, permet d'effectuer [] l'installation :

Installation

Une fois la version d'installation de Windows PE lancée sur un ordinateur, il est possible d'installer un système d'exploitation sur celui-ci à l'aide des images disponibles sur le serveur de déploiement.

Un nombre variable d'étapes est nécessaire lors de l'installation du système d'exploitation en fonction des configurations faites par l'administrateur du serveur de déploiement.

Petit extrait de PXE par wikipedia :

Pour activer le PXE, il faut auparavant le configurer dans le BIOS. L’option se trouve fréquemment dans un menu concernant la carte réseau.

L'amorce par PXE s'effectue en plusieurs étapes :

recherche d'une adresse IP sur un serveur DHCP/BOOTP ainsi que du fichier à amorcer ;
    téléchargement du fichier à amorcer depuis un serveur Trivial FTP ;
    exécution du fichier à amorcer.

La taille du fichier à amorcer ne permet pas de « booter » directement un noyau Linux, par exemple, mais il faut que le logiciel à amorcer le télécharge et l'exécute lui-même.

Ce minimum compris, on voit que le DHCP doit répondre de façon spéciale (et inhabituelle).
La question est donc : est ce que le DHCP fourni par pfSense est adapté ?
La réponse est : probablement pas !

(Si j'avais à faire cela, je me ferais un 'lab' et ce n'est surement pas pfSense qui fournirait un dhcp …)

J'ai eu le problème aussi il y a quelques semaines, du coup, j'ai laissé pfSense en anglais et ça me va bien …

Je ne suis pas certain de vous comprendre. ET cela n'a guère de rapport avec Pfsense. Une solution possible est d'ajouter sur le load balancer (il n'y en a qu'un seul ?) une interface supplémentaire qui traite les demande provenant du Lan. Votre LB pet gérer des interfaces multiples si c'est un produit un peu sérieux, qu'il soir virtualisé ou matériel. Avec un seul LB vous déplacez le problème de la haute disponibilité mais vous ne le traitez pas. Si le LB tombe même avec 12 serveurs derrière vous n'êtes pas plus avancé ! Un cluster pour le LB ?

Un truc que je trouve étrange :
Le certificat que tu utilise, "pro4545", est probablement ok, ça change de "blablabla.tld" d'habitude.
Sachant que le page d’authentification est passé par le https, ce certificat est valide pour les navigateurs (visiteurs) de ton portail ? Autrement dit, c'est un certificat vérifié et fabrique par un vrai autorité ?
C'est partie est ok :

This name will be used in the form action for the HTTPS POST and should match the Common Name (CN) in the certificate (otherwise, the client browser will most likely display a security warning). Make sure captive portal clients can resolve this name in DNS and verify on the client that the IP resolves to the correct interface IP on pfSense.

?

T'es au courant qu'un vrai certificat via Letenscrypt est possible avec le package "acme" ?

Un autre détail : Le LAN est normalement que pour les appareils de confiance, le portail captive se monte sur un interface dédié.

Effectivement si tu laisses "any to any", le FW ne sert pas à grand chose.
Mais d'un autre coté, tu n'es pas obligé de définir ET source ET destination pour chaque protocole.

Oui il va falloir identifier les ports utilisés par les différentes applications.
Mais ensuite, tu peux peut-être te contenter de d'autoriser, par exemple, un range source (celui que tu utilises pour DHCP) à accéder, pour un ensemble de ports correspondant à l'application, à l'IP du serveur qui la supporte.

Pense ici à utiliser la notion d'alias qui va te faciliter la vie dans la gestion des règles.

Pas simple à résoudre. Nous sommes dans le bricolage (que j'ai moi même pratiqué avec des Watchguard). Je dois dire que j'ai laissé tombé le problème de l’afficheur LCD. Je fonctionne très bien sans pour les Watchguard que j'ai en prod dans cette configuration.
Vous avez regardé le forum US ? En vous inspirant de ce qui est fait avec les Watchguard justement ? Résultat non garanti !

Pas de quoi c'est pour ça que j'étais revenu mettre la solution ici.

@chris4916:

@ccnet:

C'est quoi un parc énorme ? 30 postes, 50, 100, 200, 500, … ?

Tu fais bien de poser la question. Chez un de mes clients un parc énorme c'est >100 000 collaborateurs. Et pourtant il déploie une autorité de certification interne. Et il ne fait pas d'interception SSL.
Si parc énorme il y a, en général les moyens et les compétences sont disponibles en interne. Paradoxal tout cela …

"énorme" est proportionnel à la taille et aux compétences de l'équipe qui gère le parc.

Dans une entreprise qui n'a pas encore muri sa réflexion sur l’organisation de son service informatique, mais qui, parce que c'est facile de le faire sans vraies compétences, a déployé quelques serveurs et deux ou trois centaines de postes, les problématiques autours de l'administration de ces postes clients deviennent rapidement importantes. On a aussi les moyens de faire appel à des compétences externes sur les points difficiles.

Avec quelques centaines de postes il y a en général "quelques" ressources internes. Ou alors, ce qui est  toujours possible, des managers qui n'ont pas pris la mesure du problème.

Deux choses rapidement car j'ai peu de temps et peu d'expérience du trafic shaper.
Merci d'avoir pris le temps d'exposer votre besoin de façon détailler et claire.

tout les employés ouvrent 2/3 onglets sur les services de streaming (Youtube/dailymotion, spotify, etc…), les transfert ne sont pas optimaux car cela bouffe de la bande passante

Cela correspond bien à une besoin métiers et est un usage légitime dans l'entreprise ?

Est-il possible actuellement avec pfSense et la dernière version 2.4.2-RELEASE-p1 (amd64) de limiter la bande passante ?

Je ne sais pas sur quelle version vous êtes actuellement. Je me souviens que le trafic shaper a été totalement refondu il y a quelques versions de cela.  Vérifiez aussi si cela vous concerne ou non.

Ah le problème du déchiffrement des connexions sécurisées (HTTPS, TLS/SSL) …

Ccnet est un expert, donc vous pouvez lui faire confiance ... comme je lui fais confiance.

La loi du 23 janvier 2006 dite "loi anti-terroriste". 3 liens utiles :

https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000454124 (le texte de la loi) https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&categorieLien=id (le décret d'application) http://www.frameip.com/log-fai-isp-operateur/ (un bon résumé su un site de référence)
Les entreprises sont assimilés aux FAI et doivent enregistrer et conserver des traces des communications (de type HTTP).

Article 1384 alinéa 5 du Code civil : l’employeur est responsable de l’agissement de ses salariés, notamment sur les réseaux informatiques ! (Cité par l'ANSSI)

En 2018, les choses ont bien évoluées :

largement plus de 50% des sites web sont en HTTPS : exemple (janv 2017) https://www.wired.com/2017/01/half-web-now-encrypted-makes-everyone-safer/ les messageries cryptées se sont fortement développées : exemple Telegram, ...

Se pose la question du déchiffrement des sessions HTTPS.
Les bonnes recommandations (pour la France) :

CNIL : (mars 2015) https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions ANSSI : (juin 2012) https://www.ssi.gouv.fr/agence/publication/ssltls-etat-des-lieux-et-recommandations/ ANSSI : (octobre 2014) https://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/
Dans ce dernier document, l'aspect juridique est (esquissé) à partir de la page 26 ...

La diffusion automatique du certificat de remplacement est juste impossible, si on comprend un peu ce qu'on fait.
J'ai les mêmes étonnements que ccnet sur votre maîtrise du sujet ...

L'ajout d'un revers est une excellente chose que l'on ne peut que conseiller. J'ai testé assez abondement la solution Vulture il y a un peu plus d'un an. J'ai tenté une installation, dans le cadre d'un projet client, de deux clusters. Alors que j'avais de gros espoirs sur ce produit (j'attendais quelque chose avec la fiabilité et la robustesse de Pfsense) j'ai été contraint d'abandonner par manque de fiabilité, ne serait-ce que lors des installations. Chaque nouvelle version apportait des corrections aux bugs trouvés (j'en ai remonté plus d'un au support), des nouvelles fonctionnalités mais aussi ces nouveaux bugs. Vulture partage le même socle système que Pfsense (Free BSD), hélas pas la même stabilité.
Après quelques recherches j'ai testé les produits Kemp et en particulier Kemp FreeLoadMaster qui est une version gratuite bien complète. Sa principale limitation est la bande passante. Une appliance sous forme de vm. Nous avons finalement mis en prod les deux clusters avec des versons payantes. Depuis j'ai à nouveau déployé ces produits à plusieurs reprise avec la même satisfaction. Efficacité, configuration assez simple, les templates qui permettent des déploiements, pour certains service un peu complexes, très rapide. La fiabilité, la stabilité sont au rendez-vous.

Bonjour thérry

mais pour faire court comme vous

pas assez d'info ==> dur de comprendre pas de formulaire ==> …

Cordialement.

J'ai fini par trouver. Un alias avec un faute de frappe … ca fait 1h que je cherche lol

La migration est majeure car vous avez passé de 386 à amd64 !
Vous avez conservé une sauvegarde de la version précédente (fichier .xml).

Si la restauration de la sauvegarde ne fonctionne pas, il est possible de faire des 'restaurations partielles'.

L'idée est de partir du serveur fraichement installé avec la nouvelle version, donc config à 0.
On configure le LAN correctement et on fait une sauvegarde.
Dans le fichier .xml, on incorpore la sauvegarde originale par petit bout : la section <interfaces>, puis les <aliases>, puis les <rules>On peut voir ainsi si la config se reconstruit correctement.

Il est notable, que pour les interfaces, du fait de 386/amd64 ou pas, les interfaces physiques BSD peuvent changer …</rules></aliases></interfaces>

@chris4916:

Le lien que tu montres décris exactement la même chose que ce que je te dit, à savoir un serveur VPN qui écoute sur localhost avec un forward.

Une fois que tu as compris le principe, qu'est-ce qui t'empêche de faire un forward de la VIP plutôt qu'un forward de tes WAN ?
Rien…  ;)

Effectivement je n'avais pas bien compris le principe. Je te remercie tout fonctionne parfaitement  ;D

Les tenants et les aboutissants m’échappent. Snort sur Pfsense avec deux interfaces en bridge pourquoi pas. La management sur une des ces deux interfaces c'est une ineptie. Il y a bien d'autre solutions et façons de réaliser une plateforme de détection Snort.