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.

IMG_2388.JPG
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

;) ;)

Cette toute première étape est essentielle.
Cela dit une piste : Pfsense , box donc … dhcp probablement. Peut être que ...

Merci pour ces conseils

@+