pfsense squid/squidguard dhcp pas d'accès internet pour poste windows



  • bonjour à tous

    Contexte : milieu pro, niveau expertise de l'administrateur avancé, age de la solution firewall c’est du nouveau
    Besoin : bloquer les utilisateurs à certains sites web et les empecher de contourner pfsense avec la mise en place de vlan gérés par switch au niveau du port
    Schéma :
    WAN (modem/routeur/box) : box sfr fibre, pour le moment avec sa conf d’origine donc en 192.168.1.1 avec un dhcp de 192.168.1.20 à 192.168.1.200 dans un vlan 400
    Cible : passer la box en 192.168.0.1 dans un vlan 520 en désactivant le dhcp
    LAN : vlan 400 géré par switch au niveau du port, dhcp pfsense 192.168.1.10 à 192.168.1.200, ip carte lan fixe en 192.168.1.1, tout le reste en paramétrage par défaut pfsense 2.4.4
    DMZ : aucune
    WIFI : aucun
    Autres interfaces : aucune
    Règles NAT : celles de pfsense 2.4.4 par défaut
    Règles Firewall : celles de pfsense 2.4.4 par défaut
    Packages ajoutés : squid, squidguard, lightsquid
    Autres fonctions assignées au pfSense : aucun
    Question : les postes windows n’ont pas accès à internet dès lors que le dhcp de pfsense est en fonction, message d’erreur : aucun dns, fonctionne sans problème pour les poste linux et smartphone android/ios
    Pistes imaginées :
    1- création de vlan dans pfsense avec lan vlan 400 et wan vlan 520, reconfiguration de l’adressage ip de la box sfr en 192.168.0.1 avec désactivation du dhcp
    rattachement de chaque vlan au carte physique du serveur pfsense
    ip fixe carte wan et vlan wan ainsi que carte lan et vlan lan
    aucun surf possible avec cette configuration, pfsense n’accède meme pas à internet
    2- rester full vlan 400 coté wan et lan
    carte wan en dhcp, ip attribuée par la box (192.168.1.15)
    ip box en 192.168.1.1
    dhcp box en 192.168.1.15 à 192.168.1.16
    ip lan en 192.168.1.10/24
    dhcp pfsense 192.168.1.10/24 à 192.168.1.200/24
    surf ok sur un poste linux avec toutes les stats dans lightquid + solution de blacklist ok …. Mais impossible avec windows, message d’erreur dns introuvable

    schéma du réseau cible ci dessous avec les copies d'écran de la conf pfsense



  • This post is deleted!


  • et dans l'idéale l'architecture souhaitée serait celle ci mais elle n'a jamais pu fonctionner...
    0_1539944701512_Dessin1.jpg



  • 0_1539958472421_certificats.png
    0_1539958483549_confgene1.png
    0_1539958494120_confgene2.png
    0_1539958500679_confgene3.png
    0_1539958508438_fwlan.png
    0_1539958515857_fwwan.png
    0_1539958522175_interfaces.png
    0_1539958528015_lan1.png
    0_1539958534275_lan2.png
    0_1539958540040_paquets.png
    0_1539958546326_routage.png
    0_1539958552354_wan1.png
    0_1539958557771_wan2.png
    0_1539958565549_wan3.png



  • complément config

    0_1540215345237_squid1.png
    0_1540215356194_squid2.png
    0_1540215364906_squid3.png
    0_1540215374144_squid4.png

    0_1540215383122_squidguard1.png
    0_1540215391122_squidguard2.png

    0_1540215399364_reports1.png
    0_1540215406228_reports2.png



  • personne n'a d'idée apparemment ...



  • Je ne sais pas si c'est un manque d'idée mais, en tous cas de mon pont de vue, c'est compliqué.
    Je ne suis pas arrivé à aller plus loin que ton premier poste que je ne comprends déjà pas, et lire la tonne de copie d'écran que tu fournis ne va probablement pas aider.
    Tn montage avec un switch entre la box et pfSense auquel sont connectés les utilisateurs me parait inutilement compliqué et je ne comprends les contraintes qui sont derrière et qui justifient ce design.
    Ensuite, le message d'erreur DNS introuvable signifie que ton proxy fonctionne en mode transparent, donc uniquement en HTTP et pas HTTPS sauf à faire du SSL Bump.

    Bref, il y a plein d'info, peut-être même trop, je ne sais pas trier mais en tous cas pas de quoi se faire, pour moi du moins, une idée simple de la problématique et des contraintes qui imposent un design si "surprenant".



  • @chris4916 c'est notre architecture d'entreprise qui veut cette architecture
    la présence d'un switch est d'une part plus souple pour faire les différent vlan défini sur chaque port du switch
    et d'autre part, la box et le serveur pfsense étant très éloigné l'un de l'autre il est difficile de tirer un cable direct

    nous souhaitons faire du proxy transparent car la box est en accès libre pour nos utilisateur via, pour 90% des cas, de leur propre devices personnel. Donc nous ne pouvons pas nous permettre une authentification proxy.

    ensuite l'accès libre à internet se fait par le vlan 400 exclusivement
    et pour renforcer la sécurité nous avons souhaiter mettre la box et la carte wan de pfsense dans un autre vlan 520
    d'autre vlan son défini pour le réseau d'entreprise ou l'accès à internet s'en trouve plus restreint

    merci tout de meme d'avoir apporté des éléments de réponse



  • 0_1540371213752_Présentation1.jpg





  • Votre architecture n'est pas adaptée pour fournir un niveau de sécurité acceptable. Une bonne pratique élémentaire, pour commencer, est qu'un équipement réseau (en dehors de ceux conçu pour cela : un firewall par exemple) ne doit pas traiter des flux ayant des niveaux de confiance différents. Ici c'est le grand écart. Finalement votre firewall ne sert à rien, votre protection périmétrique repose sur un Vlan. C'est mince.

    reconfiguration de l’adressage ip de la box sfr en 192.168.0.1

    C'est aussi plutôt une mauvaise idée, tout comme l'usage de 192.168.1.0/24.



  • bonjour à tous

    bon décidément je commence à m'y perdre en suivant tous les tutos que je trouve, il y a toujours certain qui coche des options d'autre pas...
    au final je ne vois meme plus les sites visités dans squid moniteur temps réel...

    j'ai refais une conf d'usine, la carte wan en dhcp (192.168.1.32), la carte lan en ip fixe (192.168.1.10)
    dhcp pfsense aucun
    squid, squidguard et lightsquid sont installés
    tout est configuré en standard

    avez vous un tuto pour me guider je commence à m'y perdre à force de jouer avec tous les paramètres

    merci d'avance



  • Et la carte WAN et la carte LAN dans le même réseau, ça ne vous dérange pas ?
    Pas mieux que ccnet !

    Si c'est un proxy que vous voulez, ce serait plus efficace de partir d'une simple Debian et de configurer les fichiers de conf à la mano (mais inspiré de ceux du pfsense !) ...

    Ce qui se conçoit bien, s'énonce clairement
    Et les mots pour le dire viennent aisément
    (Nicolas BOILEAU)

    Ce que l'on comprend bien, s'installe simplement
    Et les fichiers de conf s'écrivent aisément ...
    (version pour l'informatique ...)



  • si
    mais il faut impérativement garder l'adressage tel qu'il est coté lan car certain devices tel que des hotspots wifi ont des conf en ip fixe (meme pas de résa d'ip dans le dhcp)
    et que lorque je met une autre adresse pour la carte wan tel que 192.168.2.5 par exemple, et en modifiant l'ip de la box sfr en 192.168.2.1 pour que les deux puissent communiquer ça ne fonctionne pas
    pourquoi? car la box sfr est dans un vlan 400 et ce vlan se trouve en 192.168.1.x/24
    et qu'en définissant un nouveau vlan, 520 par exemple, plus rien ne fonctionne

    j'avais pensé à une debian avec squid
    mais pfsense avait l'air plus simple car moins de manip sur les fichiers de conf...

    donc pour faire déja au plus simple, on a gardé le vlan 400 partout



  • Je comprend mal cet entêtement avec une solution qui ne marche pas et qui n'est vraiment pas sûre.

    et pour renforcer la sécurité nous avons souhaiter mettre la box et la carte wan de pfsense dans un >autre vlan 520
    d'autre vlan son défini pour le réseau d'entreprise ou l'accès à internet s'en trouve plus restreint

    L’élément de base d'une segmentation réseau ne saurait être l'usage de Vlan. C'est d'abord une question d'architecture liée au firewall. Les Vlans ne venant qu'ensuite pour partager les supports physiques. Dans votre cas vous devriez ne pas avoir besoin de Vlan.

    nous souhaitons faire du proxy transparent car la box est en accès libre pour nos utilisateur via, pour 90% des cas, de leur propre devices personnel. Donc nous ne pouvons pas nous permettre une authentification proxy.

    Cette solution n'est pas défendable par rapport aux obligations réglementaires. En cas de problème, le représentant légal est pénalement responsable et le restera dans votre cas.