Squid et HTTPS et Accès WAN



  • Bonjour,
    J'utilise pfSense 2.1 i386.
    J'ai 2 interfaces :
    LAN : 192.168.1.1
    WAN : 10.0.1.244

    Pb : dans les règles du firewall pour l'interface WAN, je n'ai aucune règle active. Je n'ai que la règle par défaut "Block bogon networks".
    Pour autant, les machines branchées côtés WAN on accès à Internet… Je ne vois pas d'où ça peut venir...
    J'ai également un proxy SQUIDv3 + SQUIDGUARD + LIGHTSQUID + portail captif

    D'où ma seconde question : sur l'interface LAN sur laquelle est branchée le portail captif, je peux surfer sans problème sur les HTTP et HTTPS.
    Par contre, depuis l'interface WAN, impossible d'accéder aux sites en HTTPS... Je ne comprends pas la logique malgré ce que j'ai déjà pu lire sur le MAN on the middle sur ce forum... ?

    Merci de vos lumières.



  • J'avoue avoir du mal à comprendre ton objectif et le design de ton infrastructure.
    Des machines sur l'interface WAN… pour quoi faire ? et pourquoi ne sont-elle pas coté LAN ?
    A supposé que tu sois bien dans le cas ou ce design est nécessaire, ces machines ne passent donc pas par pfSense pour accéder à internet...

    Comme tu le constates, il faut décrire de manière plus précise ton environnement sans quoi il va être difficile de te répondre  ;)



  • Ce n'est pas clair.

    A partir du moment où un ou plusieurs lecteurs ne comprennent pas, c'est qu'il manque le travail indispensable de rédaction du formulaire.
    Merci de vous poser la question : suis-je clair ?



  • Bonsoir
    Quand on est dedans, on en oublie parfois l'essentiel.
    Je vais tenter d'être le plus clair possible.
    Dans l'entreprise, nous avons un réseau Windows avec AD.
    Les utilisateurs peuvent se connecter à internet et sont authentifies par une solution de notre opérateur (un watchguard).
    Pour les autres machines (des VM Linux surtout), il n'est pas possible de les faire d'authentifier automatiquement sur le watchguard (dixit l'opérateur). La solution qu'il nous a donné à donc été de mettre en place un second fiées al que nous gérons avec nos maigres connaissances.
    Une adresse IP du réseau n'est pas filtrée et laisse passer tout utilisateur. Le pfSence est donc sur cette adresse IP et il se charge du filtrage. Ainsi, quand une machine Linux souhaite accéder à Internet, on lui comme passerelle le pfSense.
    Parallèlement, la direction a souhaité qu'on mette à la disposition de nos clients un réseau wifi.
    Donc sur l'interface LAN, on a branché un AP Wifi, pfSense se charge du DHCP, du portail captif, de l'authentification avec FreeRadius et MySQL + SQUID pour la conservation des sites visités.
    Sur l'interface WAN on donne accès à certains serveurs Linux qui ont besoin d'un accès à Internet.

    Voilà pour ce qui est de l'architecture. Je sais qu'il est préférable d'avoir une liaison Internet séparée pour le wifi client mais la direction ne l'a pas souhaité pour une question de coût par rapport à l'utilisation.

    J'espère avoir été plus clair et que fort de ces précisions vous pourrez m'éclairer sur ce qui ne va pas dans ma situation.

    Merci pour votre indulgence et votre pédagogie



  • un second fiées al

    Merci de retirer les moufles !
    En dehors de ce problème les solutions mise en œuvre n'offre pas de sécurité. N'importe qui peut usurper cette ip pour contourner le filtrage. C'est un beau réseau à trous que vous avez là !



  • Il y a du texte mais un petit schéma, des adressages, … ne serait pas de trop ! (D'où le formulaire !!!)

    Dans pfSense, les règles sont réparties par onglets : LAN, WAN, ...
    Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
    Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
    Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.

    Donc, vous n'avez sans doute rien à mettre dans l'onglet WAN !

    Visiblement, vous faites confiance à un prestataire mais il ne couvre pas complètement vos besoins (et ne remets pas en cause sa solution).

    D'après ce que je comprends, l'idéal serait d'avoir en interne un proxy dédié (et non d'en avoir 2 : un sur watchguard et un sur pfSense) dont vous maitriseriez la configuration (authentification AD sauf ...).

    Un autre idéal serait de n'avoir qu'un seul firewall avec plusieurs interfaces (dont une dédiée au wifi offert aux guests).

    Je ne suis pas convaincu que ce soit la bonne démarche : soit vous confiez la sécurité soit vous la pilotez vous-même.



  • @bennijamm:

    Donc sur l'interface LAN, on a branché un AP Wifi, pfSense se charge du DHCP, du portail captif, de l'authentification avec FreeRadius et MySQL + SQUID pour la conservation des sites visités.
    Sur l'interface WAN on donne accès à certains serveurs Linux qui ont besoin d'un accès à Internet.

    Voilà pour ce qui est de l'architecture. Je sais qu'il est préférable d'avoir une liaison Internet séparée pour le wifi client mais la direction ne l'a pas souhaité pour une question de coût par rapport à l'utilisation.

    Je n'y comprends toujours rien.
    Sur la base de tes explications, le provider contrôle et filtre l’accès internet et autorise un accès "non filtré" pour l'adresse 10.0.1.244, ce qui permet aux machines qui ont 192.168.1.1 comme route par défaut d'accéder à internet sans passer par le watchguard.

    Au delà des aspects "fiabilité d'une telle architecture" relevés par ccnet, je ne vois pas comment d'autres machines que celles passant par 192.168.1.1 (l'interface LAN de pfSense) pourraient avoir un accès.
    Et donc ces "machines sur le WAN", c'est un truc que je ne comprends toujours pas  :-[

    Pourquoi les machines linux ne sont-elles pas sur le LAN, sur le réseau 192.168.1.0/24 ?

    Par ailleurs, c'est quoi cette histoire de "[i]liaison internet séparée pour le wifi" ?
    Je n'ai jamais vu un truc comme ça.
    Comment ferais-tu si la moitié des employés de ta compagnie accédaient le réseau en wifi ?

    Le wifi n'est pas le vecteur d'accès à internet, c'est le vecteur d'accès au réseau, dont potentiellement le LAN. Il est donc très courant d'avoir sur le LAN à la fois un réseau filaire et un réseau wifi. En revanche, la nature "dématérialisée" du wifi implique des mesures spécifiques en terme d’authentification des machines et utilisateurs qui accèdent à ce réseau pour éviter d'ouvrir le LAN à des personnes / ressources non autorisées. C'est différent d'un wifi "invité" qui lui justifie un réseau à part (mais l'accès internet peut lui être commun, sans aucun risque si la bande passant est contrôlée.



  • Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
    Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
    Voilà ce que j'avais à dire.

    Pour la partie technique, je n'ai pas fait de formulaire puisque je sais pas comment faire mais vous allez certainement me renvoyer aimablement vers une page du forum qui l'explique... ! Bref...

    Côté LAN, l'AP wifi à l'IP 192.168.1.254. Les visiteurs qui s'y connectent obtiennent une IP de la part de pfSense en 192.168.1.100 à 192.168.1.200.
    Leur accès est filtré par le biais de pfSense par SQUID.

    Côté WAN, c'est le réseau de l'entreprise en 10.0.1.xxx. Les serveurs Wifi sont utilisés par les utilisateurs du WAN puisque ce sont des serveurs WEB, applicatifs...
    Le prestataire filtre les accès avec un watchguard mais chaque appel pour une modification du paramétrage nous coûte de l'argent. C'est pour cette raison que l'on a privilégié un firewall interne pour gérer notre soupe interne.

    Ce que je n'ai pas précisé, c'est que l'entreprise a 8 agences reliées par VPN MPLS. Le watchguard est en coeur de réseau et filtre donc toutes les agences.

    Pour l'accès Wifi que l'on réserve aux clients (les employés ne peuvent pas s'y connecter puisqu'il faut une autorisation donnée par le biais du portail captif), ce qu'on souhaite évidemment c'est qu'il n'ait pas d'accès à notre réseau interne. Je suppose évidemment que notre situation n'est pas idéale mais ce que l'on souhaite est-il possible ?
    Bref, comment faire au mieux ?

    Merci encore et désolé pour mon incompétence, mes approximations et tout le reste !



  • @bennijamm:

    Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
    Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
    Voilà ce que j'avais à dire.

    :-X

    Je comprends ce que tu veux dire. Tu peux cependant essayer d'ignorer ces commentaires et reformuler ce qui n'est pas clair.
    Je vais essayer de mon coté de préciser ce que je ne comprends pas.

    Ne pourrais pas tu faire un schéma si ça rend la description plus simple ?

    Côté LAN, l'AP wifi à l'IP 192.168.1.254. Les visiteurs qui s'y connectent obtiennent une IP de la part de pfSense en 192.168.1.100 à 192.168.1.200.
    Leur accès est filtré par le biais de pfSense par SQUID.

    Côté WAN, c'est le réseau de l'entreprise en 10.0.1.xxx. Les serveurs Wifi sont utilisés par les utilisateurs du WAN puisque ce sont des serveurs WEB, applicatifs…

    Serveur wifi ?  tu veux dire serveur web connecté sur le LAN et accédé en wifi par les utilisateurs qui sont de l'autre coté de pfSense?

    Le prestataire filtre les accès avec un watchguard mais chaque appel pour une modification du paramétrage nous coûte de l'argent. C'est pour cette raison que l'on a privilégié un firewall interne pour gérer notre soupe interne.

    Ce que je n'ai pas précisé, c'est que l'entreprise a 8 agences reliées par VPN MPLS. Le watchguard est en coeur de réseau et filtre donc toutes les agences.

    C'est une architecture très standard: réseau MPLS et accès internet filtré fourni part un prestataire.

    Pour l'accès Wifi que l'on réserve aux clients (les employés ne peuvent pas s'y connecter puisqu'il faut une autorisation donnée par le biais du portail captif), ce qu'on souhaite évidemment c'est qu'il n'ait pas d'accès à notre réseau interne. Je suppose évidemment que notre situation n'est pas idéale mais ce que l'on souhaite est-il possible ?

    ça me semble assez simple à réaliser: si les clients du réseau wifi n'ont, au travers du firewall (pfSense) accès qu'à la seule adresse IP permettant l'accès internet, ils ne peuvent pas accéder aux LAN de l'entreprise.

    mais du coup, je ne sais pas relier cette dernière question à tes premiers messages:

    Pour autant, les machines branchées côtés WAN on accès à Internet… Je ne vois pas d'où ça peut venir...

    ça n'a pas de rapport avec pfSense puisque dans ce que je comprends que tu décris, pfSense n'est pas entre ces serveurs et internet (le réseau MPLS)
    un dessin aiderait bien  ;)

    D'où ma seconde question : sur l'interface LAN sur laquelle est branchée le portail captif, je peux surfer sans problème sur les HTTP et HTTPS.
    Par contre, depuis l'interface WAN, impossible d'accéder aux sites en HTTPS… Je ne comprends pas la logique malgré ce que j'ai déjà pu lire sur le MAN on the middle sur ce forum... ?

    mais ces serveurs ne passent pas par pfSense n'est-ce pas ?



  • Je me pose à peu près les mêmes questions. Comme un problème bine posé et bien compris est à moitié résolu commençons par le début. Un schéma avec adressage serait un bon début.



  • Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
    Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
    Voilà ce que j'avais à dire.

    Ah non, cela est VOTRE point de vue !

    Le point de vue d'un certain nombre est la nécessité de remplir un formulaire avec des sections (simples).

    Où est la difficulté à découper en sections la présentation d'un problème ?
    Cela prend juste quelques minutes de plus, c'est tout ! Mais cela facilite la lecture par les autres … et cela fait toute la différence !
    Notamment, le manque de clarté entraine une mauvaise compréhension de la part des lecteurs et un aller-retour de question pour préciser.

    Exemple (sur les 15 derniers jours) :

    J'observe que ce sont toujours ceux qui refusent le formulaire qui pose des problèmes !
    Et à l'inverse, ceux qui acceptent le formulaire produisent des fils intéressants.

    Les exemples tout récents sont assez éclairants comme démonstration !

    Je repose la question : où est la difficulté ? (quelle est la contrainte ?)
    Si cela ne suffit pas : regardez l'efficacité !
    Ne dit-on pas : un problème bien posé est à moitié résolu !

    Je n'accepte donc pas votre réponse.
    J'en ai assez marre d'avoir à réécrire toujours cette même réflexion pourtant résultat de l'observation.



  • @jdh:

    Précise donc ta pensée  ;D

    J'observe que ce sont toujours ceux qui refusent le formulaire qui pose des problèmes !
    Et à l'inverse, ceux qui acceptent le formulaire produisent des fils intéressants.

    Tu as une manière assez particulière de présenter les choses.

    Il est évident que sur pratiquement chaque nouveau fil tu as une approche très manichéenne qui consiste soit à fustiger l'auteur si le formulaire est absent soit à le féliciter si celui-ci correspond à ton attente.
    ça en devient même risible.

    Ce qui rend un fil intéressant, ce n'est pas uniquement le premier message, même si celui-ci y participe fortement j'en conviens, mais également les réponses et les changes qui y sont fait.

    Bien sûr que les fils qui t'intéressent sont ceux dont la description rentre dans les cases du formulaire et la réponse tient en 2 lignes pour qu'ils n'y ait pas d'échanges inutiles que tu considères comme des digressions, mais comme le dit l'auteur de ce fil, si le sujet ou la forme ne t’intéressent pas, tu n'es pas obligé d'y participer. Et si ça pollue ta conception d'un forum bien propre, insiste pour avoir une section dédiée dans laquelle tu pourra faire régner ta conception de l'ordre bien établi.

    Il est évident que l'auteur de ce fil à un peu du mal à comprendre et décrire l'environnement, qu'il a besoin d'aide pour le faire et que cette aide ne viendra pas de toi. C'est ton choix, je le respecte mais tu devrais faire un effort pour comprendre sa position, même si tu n'acceptes pas celle-ci.



  • salut salut

    juste en passant, je suis perdu aussi dans les explications du requiérant, mais bon je n'ai plus de napalm à rajouter sur les braises

    pour chris

    ==> au coin NA

    ++



  • Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
    Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
    Voilà ce que j'avais à dire.

    Je vais répondre encore plus franchement.

    Ce forum est ouvert à tous.
    Il est destiné à échanger du savoir entre débutants et aguerris.
    C'est un endroit où on peut s'attendre à un minimum de respect entre membres et à un minimum de règles de 'vie'.
    S'il n'y a pas un minimum d'échanges respectueux, cela devient un espace foutoir, qui, immanquablement, ne va plus servir à rien.

    Parmi les règles 'standard' comme l'utilisation de la langue française, le refus du langage SMS, une certaine correction vis à vis d'autres membres,
    des 'anciens', contributeurs assidus, (offrant leur savoir gratuitement) ont proposé d'utiliser un 'formulaire' pour poser une question.

    L'intérêt de ce formulaire est de fournir dès le départ des informations découpés en sections simples et faciles à remplir.
    La proposition de ce formulaire a un but simple et pratique : accélérer la compréhension du problème.

    L'utilisation du formulaire ne prend que quelques minutes et fait gagner du temps aux lecteurs comme à l'initiateur.

    Je vous trouve donc très culotté

    • d'être un tout nouvel inscrit
    • qui commence par ne pas respecter le formulaire
    • et qui ajoute 'c'est très compliqué'.
      Faudrait arrêter de prendre les autres pour des imbéciles …
      Et c'est étrange de solliciter une aide sur un problème perso, et de commencer par écrire que l'on serait mal accueilli alors même que l'on commence par ne pas respecter les usages ?!

    Puisque il fallait un démonstration, j'ai pris quelques fils, parmi les plus récents, avec, aussi, de nouveaux inscrits.
    Pourquoi eux sont capables de faire ce petit effort ?

    Au lieu de récriminer, nous aimerions plutôt savoir ce qui vous a empêché de passer les quelques minutes nécessaires à la rédaction selon le formulaire, et en quoi cela est un contrainte pour vous alors qu'elle ne l'est pas pour d'autres.

    Je me doute qu'il n'y aura pas de réponses ...



  • Bonjour,
    Désolé si j'ai je vous ai vexé mais si c'est le cas, c'est que je ne devais pas être loin de la vérité…
    Bref, c'est pas grave.
    Pour me dépatouiller, j'ai essayé de faire un schéma qui explique ce que j'ai tenté de vous dire à l'écrit.
    Voir PJ.

    Je vais reprendre votre formulaire et je vais le remplir, comme ça je ne serai pas le méchant nouveau !




  • Contexte :

    • milieu pro
    • niveau expertise de l'administrateur : pas assez compétent dans ce domaine, une partie de notre sécurité est donc sous-traitée

    Besoin :

    • ce serveur a pour but d'être le barrage de sortie sur une adresse (10.0.1.244) qui n'est pas du tout filtrée par le firewall "général" (= watchguard situé chez notre hébergeur en coeur de réseau)
        => toutes les autres adresses sont filtrées : il faut être membre du domaine pour sortir
        => nous utilisons des serveurs Linux qui ne sont pas membre du domaine et qui doivent donc utiliser pfSense pour sortir sur Internet.
    • nous souhaitons également utiliser le portail captif pour fournir à nos clients un accès à Internet lors de leur venue dans l'entreprise. Nous souhaitons également respecter la loi en conservant les logs.

    Schéma : posté dans le message précédent

    WAN nombre : 1 , vlan : 0, autres réseaux accédés via routeurs : non, adressage : 10.0.1.0/24, dhcp : fourni par serveurs microsoft, dns local : oui

    LAN : (modem/routeur/box) : nombre : 1, type : ???, bridge/routeur : ???, nombre d'ip publique : 0,

    DMZ : non

    WIFI : adressage de la borne wifi : 192.168.1.254, dhcp fourni par pfSense, dns local, usage : visiteurs

    Autres interfaces : non

    Règles NAT : non je ne crois pas

    Règles Firewall : rien pour le moment

    Packages ajoutés : squid3, lightsquid, squidguaurd, freeradius

    Autres fonctions assignées au pfSense : Portail captif (sur quelle interface : LAN) et accès pour les serveurs Linux de la plage IP 10.0.1.x/24

    Question : comme je l'ai déjà indiqué, je souhaiterais tout simplement mettre ce schéma en oeuvre et que ça fonctionne. Aujourd'hui mes serveurs Linux n'ont pas d'accès à Internet (le ping marche mais une commande curl www.orange.fr par exemple).
    Je voudrais aussi savoir ce qui est le moins pire dans mon schéma et où se situent les points "dangereux" (sans être parano non plus).

    Recherches : j'ai fait des tests et suivi des tutos mais ça ne semble pas être concluant…

    Logs et tests : à votre demande, je peux fournir ce que vous souhaitez.

    Merci pour votre précieuse aide !



  • Ton schéma correspond à ce que j'ai compris de tes explications, donc celles-ci sont plutôt correctes mais, compte tenu de ce schéma, veux-tu bien reprendre tes questions initiales ?

    Pb : dans les règles du firewall pour l'interface WAN, je n'ai aucune règle active. Je n'ai que la règle par défaut "Block bogon networks".
    Pour autant, les machines branchées côtés WAN on accès à Internet… Je ne vois pas d'où ça peut venir...
    J'ai également un proxy SQUIDv3 + SQUIDGUARD + LIGHTSQUID + portail captif

    Les machines coté WAN n'accèdent jamais à pfSense donc quelles que soient les règles, portail captif, proxy etc… ça n'a aucun impact sur la manière dont ces machines "coté WAN" (coté WAN de pfSense mais sur la LAN de ton entreprise) accèdent à internet

    D'où ma seconde question : sur l'interface LAN sur laquelle est branchée le portail captif, je peux surfer sans problème sur les HTTP et HTTPS.
    Par contre, depuis l'interface WAN, impossible d'accéder aux sites en HTTPS… Je ne comprends pas la logique malgré ce que j'ai déjà pu lire sur le MAN on the middle sur ce forum... ?

    Je ne comprends pas ce que MITM vient faire là.
    D'après ce que tu décris, il doit y avoir un problème avec le service géré par ton provider : si il autorise une exception pour permettre 10.0.1.244, cette IP accède à internet en HTTPS. Par contre les IP que le provider contrôle n'y accèdent pas. Rien à voir avec pfSense mais plutôt avec ton fournisseur, je pense  ;)



  • J'ai écris ceci à 9h39 ce matin :

    Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
    Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
    Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
    Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.

    Donc, vous n'avez sans doute rien à mettre dans l'onglet WAN !

    Si vous réfléchissez un peu, en regardant votre schéma, vous voyez bien que le trafic entre les serveurs Linux et Internet ne passe pas au travers du pfSense !

    Le réglage mis en place par l'opérateur consiste à autoriser l'ip WAN du pfSense, et par conséquence, toutes les machines situées dans le LAN de pfSense.
    Mais en aucun cas les machines au 'même' niveau que pfSense !

    Si vous voulez que vos serveur Linux accèdent, il faut, donc, que leurs adresses soient traitées comme l'IP WAN de pfSense.

    Vous utilisez un schéma très traditionnel, proposé par les opérateurs : un réseau MPLS avec accès Internet contrôlé depuis le 'centre' du réseau.
    De facto, le niveau de contrôle est très limité : pas de logs par ip, users, pas de blacklist ou pas de whitelist, quel stockage, …
    Et chaque modif est payante, c'est leur gagne pain !

    Une bien meilleure façon de gérer le trafic Internet repose nécessairement sur un proxy interne, dédié et bien configuré. (3 mots avec un sens précis !)
    (Au choix il sera central ou par agences.)
    (Et il aura son propre accès à Internet ...)

    Dans mon entreprise, j'ai un pfsense par site avec 2 lignes (SDSL pour le vpn inter-sites, et ADSL pour l'accès Internet) et un proxy par site.
    Je peux faire des blacklist ou des whitelist (pour les utilisateurs de base afin de les limiter). J'ai des logs sur 1 an (puisque c'est la loi). Et bien sûr je peux autoriser des serveurs sans authentification. (Certes cela fait des années que je le fais ...)

    Vous voyez, vous avez été capable de faire un schéma et de remplir le formulaire.
    Cela vous a pris 10', 20' ou 30' : qu'est ce que c'est pour être bien compris ? Où est la contrainte ? Quelle est la difficulté ?
    Alors, franchement, pourquoi ne pas l'avoir fait dès le début ?
    Et ça sert à quoi de parler sur l'accueil : pas de formulaire + dire mauvais accueil = vous vous attendiez à quoi ?

    A l'inverse, les autres nouveaux n'ont pas à se plaindre de l'accueil, il me semble ...



  • Je reviens sur ton schéma et les explications qu'il contient:

    • si le contrôle d'accès à internet se fait, par le provider, sur la base d'une authentification AD, il n'y a pas beaucoup de solutions pour donner accès aux serveurs Linux.

    Il faudrait que ces serveurs rejoignent le domaine (je sais ce sont des serveurs Linux  :D  mais ce n'est pas un point bloquant). Il faut surtout bien comprendre comment fonctionne le contrôle du provider (par exemple est-ce basé sur un ticket Kerberos et du profiling par groupe ?) soit il faut demander au provider d'ajouter des exceptions pour les IP de ces serveurs (ce qui accroit la taille de la bêche).

    Cette compréhension technique du service du provider est un point de passage obligé pour une quelconque évolution du design.

    Une manière élégante de résoudre ce type de problème serait de changer le schéma que tu montres (je ne sais pas si c'est possible dans ton cas)

    • en organisant les choses de manière différente, il doit être possible de simplifier la communication avec le provider tout en offrant plus de souplesse.

    Par exemple:

    Si tes machines sont regroupées sur des segments réseau différents, ta problématique va changer.

    • Suppose par exemple que tous les serveurs soient sur un segment, isolé, "SERVEURS".
    • ton Wifi "guest" dispose également d'un segment propre
    • les utilisateurs sur le LAN sont également sur leur propre segment

    le tout est connecté à un FW qui se connecte au segment réseau connecté au réseau MPLS et donc au filtrage du provider.
    Sur ce segment (coté WAN du WF), tu peux installer un proxy accessible uniquement aux serveurs et au wifi guest et demander à ton provider d'autoriser cette adresse IP.

    C'est juste un exemple de design qui vise à répondre à ta problématique mais également apporter un peu de sécurité dans ton réseau.

    Si tu ne peux pas changer celui-ci, un autre approche peut consister à:

    • changer l'adresse IP de ton FW pfSense coté WAN (par exemple 10.0.1.253)
    • en 10.0.1.254 10.0.1.244, tu installes un proxy HTTP  (typo)
    • tu configures tes serveurs sur le LAN et les machines sur le segment wifi guest pour utiliser ce proxy, lequel est autorisé par ton provider sans contrôle.

    (juste un autre exemple)

    La vraie difficulté ici consiste à exprimer clairement ses besoins avant de définir la solution la plus adaptée.



  • Il y a ici une astuce qui peut permettre de fournir un accès internet aux serveurs Linux, assez simplement.

    Mais avant de la décrire, il faut avoir compris pourquoi actuellement cela ne fonctionne pas.



  • Merci pour vos réponses très constructives.
    Le schéma actuel a été décidé il y a deux ans en fonction des besoins de l'entreprise et je n'en maîtrise pas le changement.
    J'ai pris contact ce matin avec notre opérateur pour voir ce que nous pourrions envisager de faire.

    @chris4916
    Quand tu parles de segments (un pour les serveurs, un pour les utilisateurs, un pour les guests), tu parles de VLAN ? de tranches IP ?
    Si c'est de VLAN que tu parles, dans mes souvenirs imagés, c'est un switch qu'on découpe virtuellement pour faire comme si on en avait plusieurs. Dans mon esprit, je ne vois pas comment les postes pourraient avec communiquer avec les serveurs s'ils sont sur 2 VLAN différents ?
    Si c'est par tranche IP, dans ce cas, il faut un routeur pour faire le travail de routage entre les différents segments… ?

    @jdh
    Les serveurs Linux n'ont pas accès à Internet parce que le watchguard donne cet accès aux utilisateurs du domaine et aux machines dont l'adresse IP est rentrée dans dans le watchguard. Dans la pratique, on pourrait faire une demande d'ajout à notre prestataire pour nos nouveaux serveurs Linux mias cela est pénible puisque coûteux (en temps (contact du prestataire, explication de la demande, tests, rappels si pb...) et en argent).
    Si vous avez donc une solution pour donner l'accès aux serveurs Linux, ça m'intéresse !

    Merci



  • @bennijamm:

    Quand tu parles de segments (un pour les serveurs, un pour les utilisateurs, un pour les guests), tu parles de VLAN ? de tranches IP ?
    Si c'est de VLAN que tu parles, dans mes souvenirs imagés, c'est un switch qu'on découpe virtuellement pour faire comme si on en avait plusieurs. Dans mon esprit, je ne vois pas comment les postes pourraient avec communiquer avec les serveurs s'ils sont sur 2 VLAN différents ?
    Si c'est par tranche IP, dans ce cas, il faut un routeur pour faire le travail de routage entre les différents segments… ?

    Ce peut effectivement être du VLAN ou des segments physiquement séparés. La réponse dépend de ton infrastructure réseau physique. Si tes serveurs sont, par exemple, dans un data centre ou une salle machine spécifique, il est facile de les mettre sur un réseau "isolé". Si les serveurs sont répartis dans différents bureaux, selon la manière dont est gérée la baie de brassage, ça peut être beaucoup plus difficile et le VLAN est probablement mieux adapté.

    Le VLAN revient à construire, de manière virtuelle (d'où son nom) un LAN virtuel isolé.
    Bien sûr qu'il faut dans ce cas, gérer le routage entre ces différents segments réseau et c'est justement tout l'intérêt puisque, en isolant les réseaux, tu contrôles qui accède à quoi et avec quels protocoles.

    Mais je dirais que ce n'est que la cerise sur le gâteau (bien que dans le cas de serveurs, ce soit plutôt des "best practices")

    L'idée principale qui répond à ta question initiale, c'est de dire:

    • faisons en sorte que tous les serverus accèdent à internet via un proxy (ce qui signifie, du point de vue de ton fournisseur de service d'une IP interne unique)
    • demandons au fournisseur d'autoriser cette IP ou bien configurons le proxy pour utiliser l'IP déjà autorisée.


  • Bonjour,
    Bon bon bon… Pas d'évolution de mon côté.
    L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.
    Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à  l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".
    Dans les logs du firewall, j'ai activer les logs pour la règle que j'ai placée dans WAN (voir copie d'écran), tout semble passer... mais ça ne revient pas !

    En revanche pour le LAN (accès donné aux clients via un AP Wifi), aucun problème de surf.

    Que dois-je faire ? Merci






  • @bennijamm:

    L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.

    Tu pourrais, stp, poster un schéma à jour montrant cette modification ?

    Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à  l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".

    J'avoue ne pas comprendre ce que ça signifie. Le schéma devrait répondre à mon interrogation.
    Dans ce que tu décris, il semble que les PC utilisateurs ne sont pas derrière pfSense (celui-ci étant intercalé entre le LAN et l'équipement en 10.0.1.254) mais sur un segment auquel serait connectée l'interface WAN de pfSense (en 10.0.1.202)
    Si c'est le cas, c'est normal que ça ne fonctionne pas car si 10.0.1.202 est la gateway des PC, ceux-ci vont accéder à cette IP pour joindre internet (au lieu de 10.0.1.254). Tu as peut-^tre ajouté une route pour renvoyer vers 10.0.1.254 (ce qui est une mauvais eidée sauf à prendre quelques précautions de configuration dans pfSense) mais lorsque les paquets reviennent à 10.0.1.254, celui renvoie ces paquet directement vers le PC alors que celui-ci attend une réponse de 10.0.1.202.

    Bref, un nouveau schéma s'impose  ;)



  • Oui, ça doit être ce que tu décris.
    Le pfsense est passerelle pour les serveurs Linux. Je n'ai pas créé de route ni rien.
    J'ai mis à jour mon schéma.
    Si tu peux m'indiquer quoi faire… je suis preneur.




  • Ce schéma ne fonctionne pas, sauf si, et c'est un design que je ne vais pas supporter, pfSense exécute un proxy Squid qui écoute sur son interface WAN.
    Je ne comprends même pas pourquoi ça marcherait pour les serveurs et pas pour les PC :o

    1 - il faut que tes serveurs soient derrière pfSense et non pas coté WAN
    2 - si tu n'as pas besoin de pfSense pour tes serveurs (pas de fonction d'isolation via un FW des serveurs et des PC, alors installe un proxy en 10.0.1.244, configure pfSense pour avoir 10.0.1.243 (par exemple) en adresse WAN et dirige les clients qui sont derrière pfSense (wifi) vers 10.0.1.244 (proxy HTTP)
    3 - ne change rien aux PC: ceux-ci sont déjà autorisés au niveau du watchguard si ils utilisent 10.0.1.254 comme dft GW.



  • Je ne vois pas non plus comment ce schéma pourrait fonctionner. Bien évidement il faut mettre les serveurs derrière Pfsense (éventuellement un second pour ne pas toucher à ce qui est tombé en marche) sur la pâte Lan. Ils en ressortiront translatés avec l'ip wan de Pfsense qui n'a qu'à être une ip autorisée sur le firewall opérateur. Mais il faudra router le trafic à destination de ces serveurs si ils doivent être accédés depuis les machine du lan. Tout cela est tellement alambiqué que je pense avoir perdu de vue l'expression de besoin initiale (si il y en avait une). Sinon le proxy tel que proposé par Chris convient.

    Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
    Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) …



  • Ce que je constate, c'est

    • l'initiateur n'est pas compétent, et fait des réglages 'au petit bonheur' en espérant que cela puisse fonctionner
    • l'initiateur a écrit un passage virulent sur le forum et ne semble pas près de s'en excuser (pour moi c'est un blocage !)
    • un utilisateur émet des idées, certes logiques mais hélas parfaitement inaccessibles à l'initiateur, en sus de quelques digressions et erreurs. De plus cet utilisateur encourage l'initiateur dans ses opinions vis à vis du forum …
    • la société veut tout et son contraire : pas d'expertise = confiance au FAI et ne veut pas payer d'où bricolage par amateur pas éclairé

    Or, dans ce cas, avec les réglages initiaux (bien meilleurs et bien plus logiques), il y a une astuce (non trouvée par chris4916) qui donnerait l'accès souhaité.

    En fait on en revient exactement à ce que j'ai écrit le 17 à 9h39 et qui reste d'actualité :

    • Il y a nécessité de disposer d'un conseil en réseaux qui saura mettre en oeuvre les bonnes techniques (cela a forcément un coût : patauger depuis tout ce temps a déjà couté !)
      J'ajoute que, malgré l'astuce que je vois, il y a nécessité de remettre à plat ce schéma !

    En ce qui me concerne, à partir du moment où il n'y a pas d'excuses, je ne vois pas pourquoi je donnerais la piste, pourtant simple, qui donnerait l'accès souhaité.
    Je répète qu'il y a une astuce simple et il n'est pas question de segments, ....

    @ccnet :
    Beaucoup de PME font confiance à leur opérateur et utilisent un réseau MPLS avec accès Internet 'central'.
    Dans le cas, l'opérateur a 'vendu', en sus, un contrôle utilisateur pour la navigation, ce qui 'attire' la PME.
    Mais la PME ignore les imperfections et difficultés qui ne manqueront pas, accompagnées de leurs solutions payantes.
    Le schéma est bancal parce que la PME tente d'ajouter un pfsense sans expérience et sans passer à une solution solide (i.e. sans accès Internet central)
    C'est fréquent en effet ...



  • @ccnet:

    Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
    Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) …

    Oui surtout que quand c'est simple, généralement ça marche ;-)  mais dans la vraie vie, pour certaines sociétés, l'infrastructure n'est pas le résultat d'une réflexion murement réfléchie pour chacune des évolutions et il y a parfois des verrues qui poussent suite à des décisions rapides, d'urgence mal gérée ou de contrainte dont on ne tient plus compte quand on regarde la big picture à postériori.

    Si les intervenants dans la société change, il n'y a pas toujours continuité, d'où des designs parfois étranges.

    Et heureusement car si tout était parfait, on s'ennuierait  ;D ;D ;D



  • @jdh:

    Or, dans ce cas, avec les réglages initiaux (bien meilleurs et bien plus logiques), il y a une astuce (non trouvée par chris4916) qui donnerait l'accès souhaité.

    Je n'ai pas la prétention d'avoir exposé ni trouvé, ni même cherché, je l'avoue, l'ensemble des solutions possibles à cette problématique  :P
    Tout le monde n'a pas ta compétence pour trouver LA solution idéale et formuler LA réponse concise et unique.
    Mais j'apprends régulièrement en te lisant  ;)

    En ce qui me concerne, à partir du moment où il n'y a pas d'excuses, je ne vois pas pourquoi je donnerais la piste, pourtant simple, qui donnerait l'accès souhaité.
    Je répète qu'il y a une astuce simple et il n'est pas question de segments, ….

    Au moins tu as la satisfaction de connaitre LA bonne solution  ;D ;D ;D

    Blague à part, la vraie difficulté consiste ici à bien comprendre quels sont les objectifs immédiats.
    Le design réseau est assez surprenant et certes sujet à discussion et amélioration mais cette considération, sauf si c'est un point bloquant, ne me semble pas être l'objectif immédiat de l'initiateur du message. La décision ne lui appartient d'ailleurs peut-être même pas.

    D'où l'intérêt, à mon avis, mais bien sûr ce n'est pas le tien, de proposer modestement différentes pistes avec des explications de ce que ça fait ou pas.



  • @jdh:

    Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
    Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
    Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
    Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.

    Attention à cette vision simplificatrice.
    Pour que cette description fonctionne à tous les coups, il faut (faudrait) activer dans le menu "System / Advanced / Firewall/NAT" la fonction "Static route filtering" (*) sans quoi les règles de l'onglet LAN vont bien concerner tous les paquets entrant par l'interface LAN, quelle que soit leur destination  ;)

    (*)

    Bypass firewall rules for traffic on the same interface
    This option only applies if you have defined one or more static routes. If it is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be desirable in some situations where multiple subnets are connected to the same interface.



  • Quote from: jdh on 17-11-2015, 08:39:22

    Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
        Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
        Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
        Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.

    Attention à cette vision simplificatrice.
    Pour que cette description fonctionne à tous les coups, il faut (faudrait) activer dans le menu "System / Advanced / Firewall/NAT" la fonction "Static route filtering" (*) sans quoi les règles de l'onglet LAN vont bien concerner tous les paquets entrant par l'interface LAN, quelle que soit leur destination  ;)

    Il est important de bien suivre ce que j'écris : je décris le fonctionnement de pfSense, rien que le fonctionnement, tout le fonctionnement.
    Il est absolument clair que les règles situées dans l'onglet LAN traitent les paquets arrivant à pfSense par cette interface.
    Concernant l'onglet WAN, il est rare d'écrire une règle directement dans cet onglet. Généralement on écrit des règles dans NAT > Port forward, règles qui génèrent une règles dans l'onglet WAN.

    Attention de bien éviter les choses trop complexes ajoutés par d'autres …



  • @jdh:

    Il est important de bien suivre ce que j'écris : je décris le fonctionnement de pfSense, rien que le fonctionnement, tout le fonctionnement.

    Je sais bien que toi seul détiens la vérité et toute la vérité  ::)  mais si je me permets de reprendre et préciser ton propos, c'est justement parce que:

    • tu décris quelque chose qui est le fonctionnement "la plupart du temps" mais qui n'est pas, comme tu l'écris "tout le fonctionnement".

    • dans le cas particulier de ce fil, nous sommes justement dans la situation que je relève (et contrairement à ce que tu sembles croire, je ne fais pas cette remarque pour te taquiner mais pour que les autres lecteurs aient une meilleure compréhension) => l'utilisateur à installé pfSense avec des machines sur le LAN mais également des machines coté WAN pour lesquelles il est suggéré qu'une solution pourrait être de changer la route par défaut pour passer par pfSense. D'où ma mise en garde.

    La raison pour laquelle ce paramètre "Static routes filtering" existe, BTW, c'est parce qu'il y a des cas de figure où le flux passe par pfSense sans pour autant changer d'interface.



  • C'est désespérant ! Il faut TOUJOURS que tu ajoutes un petit truc ALORS que ce qui est essentiel a été dit !
    JAMAIS tu ne te poses la question : ce que j'ajoute va-t-il embrouiller le lecteur ?
    Je le dis c'est toujours le cas !

    Ce n'est pas parce que tu ne vois pas l'astuce que je vois ici qu'il faut essayer de bricoler : mon astuce est très simple et ne nécessite que très peu de choses.

    Mais comme l'initiateur a insulté l'accueil et ne fait aucune excuse, je ne décrirais pas ici l'astuce.



  • @jdh:

    C'est désespérant ! Il faut TOUJOURS que tu ajoutes un petit truc ALORS que ce qui est essentiel a été dit !
    JAMAIS tu ne te poses la question : ce que j'ajoute va-t-il embrouiller le lecteur ?
    Je le dis c'est toujours le cas !

    Veux-tu dire que ma remarque sur le fait que dans le cas précis exposé par l'initiateur du fil, il n'y a pas de risque de routage via l'interface WAN sans passer par le LAN ?
    Alors j'ai mal compris  ::)

    Ou alors je ne partage pas avec toi la compréhension de ce qu'est l'essentiel  :P

    Pourquoi faut-il que ce soit toujours avec toi alors que sur les autres fils dans la section anglaise, je ne rencontre jamais ce genre de difficulté de compréhension ?

    Ce n'est pas parce que tu ne vois pas l'astuce que je vois ici qu'il faut essayer de bricoler : mon astuce est très simple et ne nécessite que très peu de choses.
    Mais comme l'initiateur a insulté l'accueil et ne fait aucune excuse, je ne décrirais pas ici l'astuce.

    Je ne me suis même pas posé cette question et je ne cherche pas d'autre solution.
    Si tu as une solution élégante c'est bien.
    Si tu ne veux pas la partager parce que l'initiateur et le autres lecteurs ne te méritent pas, ce n'est pas grave  ;)

    PS 1: à mon avis, qui n'est bien sûr pas le tien, l'initiateur du fil n'a insulté personne. Il a juste fait remarquer, suite à ton intervention :

    Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
    Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...

    Si tu te sens insulté, c'est ton problème.

    PS 2: je pense que l’initiateur a résolu son problème sans avoir recours à ton astuce magique. Ou alors il l'a trouvée sans toi  ;)



  • risque de routage via l'interface WAN sans passer par le LAN

    On va où là ? Pourquoi faire quelque chose d'aussi nul et d'aussi inutile ?

    L'initiateur, qui a oublié son problème car il ne répond plus, n'est pas très compétent, certes. Et il tente, forcément sans logique.
    Notamment au point de faire des choses complètement anormales, comme celle de changer la passerelle par défaut !
    En aucun cas, je ne saurais lui reprocher son inexpérience.

    Mais en aucun cas, on doit 'router' avec ce pfSense : encore une aberration !

    A quoi servirait d'expliquer une technique très très peu utilisée (et qui, ici, n'a aucun intérêt !) ?

    Les 2 phrases citées insultent TOUS ceux qui répondent et donne de leur temps gracieusement.
    D'ailleurs certains arrivent très bien à lire le post en haut et savent utiliser le formulaire :
    ce fil est d'ailleurs encore ouvert alors que ceux qui ont utilisé le formulaire ont obtenu des réponses, c'est encore une démonstration !
    J'ajoute que la dernière phrase est carrément horrible : 'ne vous investissez pas'; et puis quoi, venant d'un tout nouveau !

    Le problème essentiel est qu'avec 775 posts, on attendrait juste un peu de solidarité sur la question du formulaire.
    Il suffit d'observer les fils qui partent en c. : forcément il y a chris4916 qui laisse aller sur le formulaire !


Log in to reply