@gilgil: Est-ce que le portail captif intercepte sur le 3128 ? De toute évidence non  :-\ A mon avis, le proxy installé, comme je le propose, avec iptables sur une machine entre ton routeur externe et pfSense ne risque pas grand chose car il n'expose basiquement qu'un service (à condition de faire un peu de hardening) et iptables fourni un bon moyen de limiter les accès aux IPs issues du LAN. Malgré ta limitation qui est de ne pas pouvoir créer de DMZ, il y a peut-être d'autres implémentations possibles avec par exemple des VLAN mais est-ce bien souhaitable ? Une des difficultés dans ton design, c'est qu'il faut que ce soit l'utilisateur (en fait son IP ou MAC) qui passe par l'interface contrôlée par le portail captif pour accéder au web. Si le proxy est à l'intérieur, ça ne fonctionne pas car en mode explicite, c'est le proxy qui fait la requête. Techniquement, une des solutions consisterait à mettre un proxy en mode transparent + MITM (pour HTTPS) en série avec pfSense mais c'est juste horrible et je ne suggèrerait jamais ce genre de chose  :o :o :o même si ça marche  >:( Une autre approche, à tester et à mettre en œuvre si, comme on l'évoquait au début de ce fil, uniquement si tu es à l'aise avec la surcharge générée par la duplication de la charge réseau sur m'interface LAN de pfSense consisterait à: 1 - créer une deuxième IP dans un autre plan d'adressage (par exemple 192.168.4.0/24) sur l'interface LAN. Je pense que ce n'est toujours pas possible via l'interface graphique mais c'est documenté ici  8) 2 - tu installes et configures ton proxy à une adresse sur ce subnet et change ton DNS ou ton proxy.pac en conséquence. 3 - tu crées une exception sur le portail captif pour autoriser cette adresse IP sans authentification. Dans ma compréhension, un fonctionnement "par zone" du portail n'est ici pas possible car la notion de zone est associée à celle d'interface. Possible avec du VLAN mais pas avec une autre IP Avec ce design, les utilisateurs passent par le portail captif pour accéder au proxy puisque pfSense est leur gateway et ton proxy est "à l'intérieur" ;-) au prix d'une charge supplémentaire sur l'interface LAN (mais cette charge devrait être faible car limitée par le débit du WAN). 4 - reste que l'accès au proxy ne déclenchera pas de redirection vers le portail captif car fait sur le port 3218 (le proxy sur le port 80 est une solution, mais je ne suis pas certain qu'il n'y ait pas d'effets de bord. Je n'y ai pas trop réfléchi à ce stade.  Avec ce nouveau design, si tu mets le proxy.pad sur la machine qui héberge le proxy, l'utilisateur va être intercepté par le portail captif pour accéder au proxy.pac et donc déclencher une règle de la part du portail captif, ce qui va libérer l'accès au port 3128. Effet de bord: à expiration du voucher, l'accès au port 3128 va expirer mais le navigateur risque de ne pas recharger le proxy.pac donc demander à nouveau une authentification au niveau du portail. mais je n'ai pas beaucoup plus d'idées que ça compte tenu des tes limitations hardware.

Le prix du câble devrait s'amortir sur le nombre d'appliance … Merci de l'info du nouveau fonctionnement : il est probable que les concepteurs ont préféré ce mode à une install déjà pré-définie. Merci de mettre [Resolu] dans le titre …

Quelle indigence ce message ! https://forum.pfsense.org/index.php?topic=79600.0

Désolé, Je crée donc un nouveau post pour ne pas déterrer de cadavres…. Cordialement,

mais tu n'a pas besoin de ça pour des règles en "entrée"  ??? le failover s'applique sur l'interface externe, celle qui pointe sur le groupe de gateways EDIT: enfin… quoique..  :-\  je comprends ce que tu as fait maintenant que je le lis mieux.  :-X

Le CPU est a 100%…mais dans quoi ? Kernel space (sys) ? User space (un programme) ? Irq ? Wait ? Ou est consommé le temp ?

42

bonsoir, Les ports de l'ESXi sont bien dans le bon VLAN. y compris celui de de l'interface physique du VLAN 35. La carte virtuelle de l'ESXi est bien dans le VLAN35.

Merci pour le feedback. Ce qui est intéressant, c'est que pfSense autorise la connexion LDAP avec un DN qui n'est pas un DN pour l'authentification  ;D ;D

@mickael62: Si je mets un switch après mon convertisseur, comment je fais pour que mes Pfsense puissent communiquer avec lui s'ils sont sur un réseau privé sur la partie Wan ? Tu oublies un tout petit détail  ;D Il n'y a qu'un seul pfSense qui communique avec  le convertisseur et donc internet, c'est celui qui supporte la VIP publique. Pour simplifier, en terme de routage, les pfSense sont sur un réseau privé. A un instant donné, un seul des deux a l'IP publique. Celle-ci est "flottante". A noter que le switch s'en moque complètement: les 2 pfSense peuvent se voir au travers du switch via le réseau privé sur l'interface WAN. Ce ne serait pas pareil si c'était un routeur n'est-ce pas  ;)

Pour aller dans le sens de ccnet, on sent que la solution précède le besoin … ce qui n'est jamais bon ! Un serveur de mail interne, c'est ok. Mais il doit communiquer avec l'extérieur ... normalement ... donc sur le port 25 et pas par un VPN (et sans doute sûrement via le smtp du FAI). Il peut aussi recevoir les mails de l'extérieur, et au moins ceux d'un logiciel de messagerie d'un utilisateur interne qui serait en déplacement. Ce dernier cas recommande le port 587 avec l'authentification qui va bien ... Quand on n'est pas spécialiste (et ce n'est pas une tare), on commence par exprimer un besoin (en français). Il vient alors une réponse technique ... Ca c'est la vie normale ...

Seul truc bizarre : On peut créer plusieurs portails captifs, mais on ne peut pas dire à squid l'intitulé du portail à utiliser… Non ce n'est pas bizarre … si on connait/comprend les 2 notions : un portail captif : c'est un 'interrupteur' de trafic : il autorise le trafic (=la traversée du firewall) si on s'identifie un proxy (http) (ici Squid) : c'est un intermédiaire entre le client et le serveur, pour le seul protocole prévu (http, https, ftp), avec contrôles possibles : authentification, date/heure, sites autorisés ou non, ... Il y a authentification, certes oui, ... mais pas sur le même référentiel ! D'où non bizarre !

Bonsoir Chris et merci beaucoup pour ta contribution. En effet, activer ou désactiver un règle est simple, mais ils y a trop de clics… ;-) Et il faut s'identifier sur la pfSense. Le plus rapide et le plus confortable est donc de le faire via un ordinateur. Comme évoqué plus haut, je souhaitais le faire via un simple bouton sur une page maison utilisable depuis un iDevice ou un Mac/PC comme qui rigole... En tous cas, je vous remercie beaucoup. Je vais quand même continué à chercher et vous tiendrai au jus. A+ Cyril

Bonsoir, Oui vous avez raison, je pensais qu'il y aurait pu avoir une configuration à faire spécifique sur OpenVpn, ou que ça aurait pu aussi arriver à quelqu’un d'autre !!!! Merci Laurent

@infopv: Avez vous une idée d'où cela peut venir ? Pourquoi Squid ne fait pas le basculement, surtout qu'il n'a rien à faire pour le coup selon moi… Le routage se fait après le Proxy. Certes mais tu es dans une situation un peu particulière car le proxy tourne précisément sur la machine qui est en charge du fail-over. Je pense, comme toi, que ça ne devrait pas avoir vraiment d'impact mais il faut probablement regarder de près (c'est à dire pas juste dans l'interface web) la configuration de Squid et ses logs pour comprendre la source de l'erreur. J'ai une config assez similaire à la tienne avec 2 WAN en fail-over et un proxy Squid (mais sur une autre machine) et ça fonctionne tout à fait normalement.

Hello, https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense Il faut regarder le champ "source" et ça devrait le faire. @+

Rapport de bug effectué : https://redmine.pfsense.org/issues/5136

Je suis bien d'accord, d'autant qu'il revient avec, plus ou  moins le même sujet, présenté un différemment mais tout aussi confus.