PfSense avec proxy externe

obliging

Bonjour,

Je suis alternant (service info) dans une entreprise.

Mon projet est de mettre en place une connexion publique (flaire + wifi) avec portail captif et sauvegarde des logs (l'IP suffit, ce n'est pas pour l'admin réseau, seulement pour la législation française).

Sur le pfSense,

une carte réseau Wan qui reçoit en DHCP une adresse en 192.168.1.x/24
une carte réseau Lan qui distribue en DHCP la plage 192.168.10.x/24
une carte réseau WLan qui distribuera en DHCP la plage 192.168.20.x/24

Sur le réseau Lan, j'ai configuré sur une autre machine (debian 9), un squid pour la sauvegarde des logs (avec l'IP 192.168.10.2).

Celui-ci fonctionne très bien, seulement il n'est pas transparent, le but final est qu'il n'y est AUCUNE configuration à faire dans les navigateur clients, puisque ça sera un réseau publique. (Je cru comprendre que le proxy transparent n'était pas une bonne idée, seulement c'est obligatoire pour mon projet)

J'ai essayé de faire quelque chose avec "WPAD" ou du NAT sur mon pfSense, en suivant les conseils des autres topics du forum, mais mes connaissances sont limitées et je rame depuis près de deux semaines.

Comment dois-je configurer mon pfSense, le plus simplement possible svp, pour que http et https passe par mon squid transparent, et sorte normalement du réseau sur le Wan?

PS : J'ai une seule carte réseau sur mon debian 9 avec le squid, j'ai juste?

Merci bcp :)

chris4916

Le proxy en mode transparent sur le LAN avec une machine qui n'est pas la passerelle par défaut (ta conf donc) c'est assez tricky en terme de réseau car la réponse qui arrive de la défaut gateway arrive directement au client alors que le flux sortant était redirigé vers le proxy.
Pour rester en mode transparent, il est plus simple de mettre ton proxy dans un VLAN, d'un point de vue réseau.

Par ailleurs, en mode transparent, sauf à activer SSSBump et donc casser le tunnel HTTPS, le flux HTTPS ne passera pas par le proxy. L'alternative, c'est le proxy explicite, WPAD mais des devices comme Android qui ne vont pas le supporter.

obliging

Donc une solution serait le proxy dans un VLAN?
Mais je ne vois toujours pas comment configurer le pfSense…?
Les flux sortants et entrant passeraient par le proxy? N'y aurait t-il pas un problème de débit? Le SSSBump est-il compliqué à configurer pour un débutant et est-il obligatoire (juridiquement parlant) de loguer le flux HTTPS?

Les problèmes avec WPAD c'est que

il demande une première configuration de firefox, je crois, ce qui est embêtant puisque ma solution doit être déployée dans des dizaines de sites et que les clients ne seront pas forcément informés sur cette configuration (modifier "pas de proxy" par "détection auto" il me semble),
j'ai besoin que tous les devices puissent utiliser la connexion.

Merci bcp pour votre aide !

jdh

Les débutants devraient lire A LIRE EN PREMIER …
Toutefois votre question est assez claire ... mais votre compréhension, incomplète, est parfois erronée.

Un proxy transparent ne fonctionne (proprement) QUE pour HTTP : vous n'obtiendrez pas les logs du trafic HTTPS !
Donc un proxy explicite est nécessaire pour loguer HTTP et HTTPS !

WPAD permet à tous les navigateurs de trouver, grâce à DNS et DHCP, le proxy.
Vrai pour Internet Explorer, Edge, Google Chrome : c'est du au fait que Windows, par défaut, coche la case 'Détection auto' et que ces navigateurs utilisent ce réglage.
Faux pour Firefox qui n'a pas la bonne case sélectionnée par défaut ('Détection auto' au lieu du 'Utiliser les paramètres proxy du système' par défaut ... qui porte mal son nom !)
Faux pour une quantité impressionnante de logiciels qui ne savent pas détecter le proxy .... (la plupart n'ont même pas de zone de saisie !)
Eh bien, vous allez créer une petite note : Firefox : faites ceci ... / Autre logiciel : configurer le proxy avec ...
Et surtout la petite note devra préciser qu'il faut commencer par un trafic HTTP !!!

WPAD n'est que réglages DHCP, DNS et 3 fichiers dans un serveur web bien configuré :

le DHCP et le DNS sera fourni par pfSense, et il est aisé de le configurer. (Attention à bien fournir un DNS 'internet' et non celui de la zone LAN ...)
les 3 fichiers seront très simple (DIRECT x.x.x.x:y) mais nécessite une petite config du serveur web, cela sera fait simplement sur le proxy lui-même.

Dernier point, et non des moindres, la position du proxy :

il ne peut être dans le réseau WLAN, car WPAD s'appliquant, tout le trafic HTTP passera par lui et le portail captif ne fonctionnera pas alors !
il ne peut être sur le LAN = porte ouverte : conseil ne pas partager les proxy !
il devrait donc être 'en amont' : par exemple avoir sa zone réseau dédiée

Attention à ne pas rêver d'associer facilement un identifiant saisi sur le portail captif et les URL d'une ip !

Bref votre compréhension nécessite d'intégrer ces réflexions ...
(Il faut plus de 20' et une volonté d'aider pour rédiger ce que j'écris ...)

ccnet

Le SSSBump est-il compliqué à configurer pour un débutant et est-il obligatoire (juridiquement parlant) de loguer le flux HTTPS?

Non seulement le déchiffrement du trafic https sur un proxy sortant (c'est à dire pas un reverse où la problématique est toute autre) n'est pas juridiquement obligatoire, mais il est même quasiment à proscrire sauf contexte bien spécifique et information des utilisateurs.
Les meta-données produites (la commande connect) sont suffisantes pour répondre aux exigences du législateur. L'absence d'authentification de l'utilisateur, donc l'impossibilité de rattacher un trafic à un utilisateur, n'est pas vraiment ce qu'attend le législateur. A défaut il s'en accommode en faisant porter la responsabilité à l'entité qui met à disposition l'accès internet.

jdh

C'est TOUJOURS le même problème !

En réalité 'absolue', il est possible de faire fonctionner un proxy transparent pour HTTPS.
Mais cela induit d'énormes contraintes, techniques et juridiques :

juridique : a-t-on le droit de casser le cryptage ?
juridique : le certificat présenté n'est plus le certificat REEL du serveur
juridique : l'utilisateur est-il informé
technique : pour casser le cryptage, il faut de la technique et substituer le certificat
….
(Si cela vous intéresse, voyez Chris ...)

De facto, je refuse cette réalité 'absolue', et je préfère indiquer une vérité 'simple' et 'efficace' :

Un proxy transparent ne fonctionne QUE pour HTTP.
Et donc il faut utiliser un proxy (explicite) pour traiter HTTP et HTTPS. (et WPAD sera là pour configurer les navigateurs !)

Ceci permet de mettre en place simplement une solution efficace et juridiquement correcte.

Au lieu de ça, certain, au nom d'une vérité technique, et au mépris TRES CLAIR d'embrouiller le lecteur débutant, au mépris de signaler complètement les contraintes, préfère écrire 'oui mais non'.

Ras le bol des 'oui mais non' ! Je préfère une solution 'oui'.

Ce que j'écris est simple, direct, efficace, et … juridiquement correct (le certificat présenté est bien celui du serveur réel !).

chris4916

@jdh:

le DHCP et le DNS sera fourni par pfSense, et il est aisé de le configurer. (Attention à bien fournir un DNS 'internet' et non celui de la zone LAN …)

??? quel DNS"internet" ? pour quoi faire exactement et configuré sur quel équipement ?

jdh

Certains font sur le LAN du 'dns-split' : il s'agit de ne pas fournir des adresses internes inaccessibles (dans le LAN) à des clients d'un réseau WIFI 'Guest' !

chris4916

@jdh:

Certains font sur le LAN du 'dns-split' : il s'agit de ne pas fournir des adresses internes inaccessibles (dans le LAN) à des clients d'un réseau WIFI 'Guest' !

Assez souvent, le DNS des équipements sur un réseau connecté à pfSense, lorsque ce n'est pas un DNS "sur" le segment en question, c'est pfSense lui même, grâce à DNS forwarder ou resolver.

Si on s'en tient au proxy (le sujet de ce fil) en mode explicite, seule la résolution du nom du proxy importe(1) puisqu’en-suite les résolutions des fqdn des URL sont réalisées par le proxy lui-même. il faut donc fournir cette résolution (pfSense ?)

Pour les autres hosts, il est quand même, mais ce n'est que mon avis bien sûr ;) préférable de ne pas autoriser les requêtes directes depuis les LAN (Wifi ou autre) vers internet mais de bénéficier du relais de pfSense.

Voila pourquoi je ne comprenais pas cette référence à un DNS "internet" dont la logique m'échappe encore je dois dire.

(1) parce que bien sûr, le proxy n'est pas adressé par son IP mais par un fqdn

jdh

J'ai écrit 'DNS Internet' par opposition à un DNS interne au LAN qui pourrait faire du DNS-split.

Qu'on utilise le resolver ou forwarder de pfSense ou un serveur dns (Bind, Windows ou autre), peu importe, ce qui compte c'est qu'on ne fournisse pas de définitions spécifiques LAN à des 'guests' !
Cela parait assez évident …

Que l'on interdise, depuis un LAN, la sortie vers des serveurs DNS sur Internet (sauf aux serveurs DNS internes dûment référencés), est une règle de sécurité assez classique.
(Il me semble qu'il existe des vpn basés sur de 'faux' serveurs DNS ...)

ccnet

Il y a en effet au moins deux risques techniques à ne pas contrôler le trafic dns.
1 Le déni de service par amplification de trafic exploite le fait que les réponses dns sont d'une taille nettement supérieures aux requêtes.
2. Dns peut être utilisé pour acheminer un trafic qui ne devrait pas l'être. Citons dns2tcp http://www.hsc.fr/ressources/outils/dns2tcp/ et tous les outils qui permettent d'utiliser UDP DNS pour établir des connexions vpn. Par exemple :
https://www.splitbrain.org/blog/2008-11/02-dns_tunneling_made_simple

Il est donc tout à fait nécessaire de ne pas laisser sans contrôle le trafic entrant comme sortant qui utilise UDP 53 ne se faisant passer pour du trafic dns légitime.