Le pouvoir de sanction est quand même une modification substantielle non ? Sur le terrain on peut aussi constater qu'en 2014 la CNIL a condamné Google à 150 000 € d'amende. Mon avis est que c'est donc un peu plus "contrasté". Il y a, dans ces arrêtés du CE de 2009, une déception. Il y en aura d'autres mais il y aura aussi des succès. Dans ce domaine (droit et SI) nous avons régulièrement des "oscillations" d'un bord à l'autre. Voir par exemple l'évolution sur les messageries d'entreprises et leur consultation.

@ccnet: Dès qu'il y a des modifications de vlan, d'affectation de carte l'expérience m'a montré qu'il fallait relancer Pfsense en effet. Je ne l'ai pas précisé car à la lecture ça me semblait évident  :-[, c'est le modem TP LINK qu'il faut redémarrer. Pas besoin pour pfSense. [quote author=jdh link=topic=97593.msg543700#msg543700 date=1438781463] <mode a_coté="">Pourquoi utiliser ce type de matériel (avec partie Wifi) ? Pour éviter box ou modem FAI, j'utilise usuellement des modem ADSL classiques comme tplink td8616 ou td 8816 ou dlink dsl-320b. J'évite d'acheter un matériel avec une partie inutile comme le wifi.</mode> Car j'ai migré en VDSL donc ces modems de techno ADSL me sont inutiles  ;) Pas de modem VDSL non routeur, à ma connaissance. Je n'ai pas fouillé plus que LDLC ou materiel.net. Je désactive le wifi et ça me va. Un peu hors sujet mais si ça intéresse de futurs lecteurs, je trouve l'interface très bien : légère, pleins d'options. On peut avoir un aperçu depuis le site TP-Link, rubrique émulateur. A priori stable. La connexion est meilleure que la livebox (bon ça, il n'y a pas de mal  8))

D'accord, merci beaucoup pour vos précisions.

@ccnet: C'est un apprentissage artificiel, sans rapport avec la réalité du terrain @jdh: Une solution simple, efficace, peu contraignante et qui offre de nombreux plus : le proxy dédié et son complément naturel WPAD. Je vous remercie pour vos réponses et pour votre expertise. Je vois que vous poussez à chaque fois la réflexion plus loin pour trouvez la meilleur solution (même au delà de l'aspect technique). J'avais déjà lu le document sur les recommandations de l'ANSSI. Mais ici j'aimerais précisément faire fonctionner le MITM https depuis SQUID3 sur pfSense. D'autres l'ont déjà fait. Je cherche juste à comprendre pourquoi le MITM ne se fait pas malgré que tout semble bien paramétrer (voir ma config dans le premier post)

Besoin : Une connexion internet double Wan (Failover) pour 2 sous-réseau (Réseau admin + réseau poste clients).             Réseau admin : Vlan 10 (serveur DC) 192.168.0.x             Réseau client  : Vlan 20 (poste client) 192.168.1.x Une configuration plus simple, claire et que maitriseriez plus facilement serait l'usage de deux cartes physique au lieu de Vlan. Je confirme ce qu'indique Ballserv pour le lien entre le switch et Pfsense : celui ci doit être un trunk. Le montage de Vlan sur une crate physique de Pfsense a été décrit mainte fois sur ce forum. Notamment ne pas monter un Vlan directement sur la carte physique mais monter 2 Vlans, l'interface physique n'étant pas utilisé pour un sous réseau. Cela nécessite le plus souvent un redémarrage.

Bonjour, Une solution simple : travailler avec CBQ créer deux queues sur l'interface WAN : une pour le LAN1 et une pour le LAN2 et n'autoriser le partage de bande-passante que pour une seule (option "borrow from other queues when available") créer deux règles sur l'interface "floating" : une pour faire matcher le trafic LAN1 <-> WAN et l'assigner à la bonne queue ; une seconde pour matcher le trafic LAN2 <-> WAN et l'assigner à la bonne queue. That's all folks!

https://forum.pfsense.org/index.php?topic=69908.0

La demande a été faite au fabriquant, avant de passer commande, de nous recommander un produit compatible pfSense, FreeBSD. Je suppose donc que l'architecture est supportée par FreeBSD. pfSense 2.2.3 pour la version, dernière en date. Comme source d'inspiration, je me suis aidé de ce sujet https://forum.pfsense.org/index.php?topic=34799.0 Il est similaire à mon cas, même si l'appliance n'est pas la même.

@jdh: Je ferais d'abord l'essai avec une seule ligne WAN et aucun loadbalancing. le pfsense étant utilisé par l'entreprise en continue, je peux difficilement effectuer ce genre de tests actuellement…

sauf erreur de ma part, les pages que tu décris sont les pages que voient les utilisateurs qui passent par le portail captif. Celles-ci n'ont aucun impact sur le fonctionnement de ce dernier. Il faudrait donc commencer par vérifier la configuration du portail. J'intuite, de ta description, que tu utilises également un proxy HTTP ? une description plus détaillée de l'ensemble aiderait certainement notre compréhension  ;) quid des logs ?

Dans le même style que l'étiquette, la bande adhésive assortie à la couleur du câble du Vlan. [image: IMG_2388.JPG] [image: IMG_2388.JPG_thumb]

ou avec vous des pistes afin de corriger cette erreur. Dans le sens de ce qui est indiqué précédemment, une solution sûre est bien évidement d'externaliser les logs hors du firewall pour une exploitation un peu sérieuse. Il y a peu j'ai détaillé les risques qu'il y a à faire ce type de modification. Il n'y a que des inconvénients avec ce type de manipulation. A proscrire.

Dans une Rule, il faut indiquer le choix 'Protocole' avec une liste comprenant TCP, UDP, TCP/UDP, ICMP, ESP, … et any. (Ce sont des protocoles IP). En général, j'évite 'any' et préfère indiquer le bon protocole (le plus souvent TCP). Les protocoles autour de SIP utilisent soit des protocoles TCP ou UDP soit le protocole SCTP : il faut donc 'any' et non 'TCP/UDP' dans les règles du tunnel ! On ne peut se contenter de "Le trafic LAN A / LAN B est en * donc tous fonction ^L^." (8/7/15 16h25) d'où "Il serait peut-être temps d'avoir des infos ...". Par ailleurs, mettre en place une solution VoIP avec SIP et ne pas savoir qu'il y a besoin de proxy SIP en cas de multi-sites (et c'est à conseiller en mono-site), me gêne quelque peu. L'informatique, et particulièrement le réseau, ce n'est pas juste brancher le câble (et faire un ping) : il y a à comprendre les protocoles et leurs spécificités (à minima, routage et NAT). (C'est curieux : j'écris des choses simples et très générales, et je ne suis pas un grand spécialiste de VoIP, mais il y a toujours un lecteur qui lit de travers !)

Ce fil et sans conclusion sont un parfait exemple de ce qu'il faut ne pas faire et de la confusion qui règne dans l’esprit de son auteur.

as-tu essayé de te connecter à https://mail.google.com ?  ;)

“Error sending request : No RADIUS servers specified “ Je serai curieux de voir depuis quelle interface Pfsense tente de joindre votre Radius. Quelques captures de trames depuis Pfsense pourraient nous éclairer.

Il me semble que le projet est à l'abandon malheureusement… ou tout du moins, il stagne depuis un moment

;) ;)