Squid et HTTPS et Accès WAN

chris4916

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.

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.

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 !

chris4916

@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 ?

ccnet

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.

jdh

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) :

KARMAZ (13-11) https://forum.pfsense.org/index.php?topic=102297.0
Mercenaire (12-11) https://forum.pfsense.org/index.php?topic=102330.0 (malgré des digressions bien inutiles)
Mamatov (17-11) https://forum.pfsense.org/index.php?topic=102546.0 (très bonne présentation)
A l'inverse :
mryou (8-11) https://forum.pfsense.org/index.php?topic=102090.0 (fil très long du aux allers et retours)
scratch (9-11) https://forum.pfsense.org/index.php?topic=102136.0 (fil long et peu intéressant)
ce fil

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.

chris4916

@jdh:

Mercenaire (12-11) https://forum.pfsense.org/index.php?topic=102330.0 (malgré des digressions bien inutiles)

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.

Tatave

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

++

jdh

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

bennijamm

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 !

Dessin1.png_thumb

bennijamm

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 !

chris4916

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 ;)

jdh

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

chris4916

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.

jdh

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.

bennijamm

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

chris4916

@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.

bennijamm

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

firewall_rules.png_thumb

logs.png_thumb

chris4916

@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 ;)

bennijamm

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.

Dessin1.png_thumb

chris4916

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.