NAT partiel vers proxy

krusty

Bonjour tout le monde,

Tout d'abord, j'espère ne pas ouvrir un sujet dont une réponse à déjà été donné. Si tel est le cas je vous pris de m'excuser.

Bon, entrons dans le vif du sujet.

Voici grosso-modo une partie de mon réseaux:

Le but du jeux: faire passer les requêtes http (port 80) sortant du LAN par le proxy (port 3128) mais uniquement pour celle souhaitant atteindre internet. En effet dans la dmz_interne nous avons des serveurs web dont on a évidemment confiance et dont on ne souhaite donc pas de filtrage sur url.
Notre proxy à pour seul intérêt le filtrage des url demandé.

Donc ma question est: est-il possible de créer un règle nat sur pfsense2 en excluant les requête en destination de la dmz_interne?

Par ailleurs, lors de l'un de mes test, j'ai remarqué qu'en redirigeant le port 80 vers le proxy (sur pfsense2), je ne pouvais plus accéder à l'interface de pfsense (logique me diriez-vous vu qu'il s'agit de http). Existe t-il un moyen pour éviter ceci?

Je ne sais pas si je suis suffisamment clair, si ce n'est pas le cas n'hésitez pas à m'en demander d'avantage.

Merci par avance à tous ce qui prendrons le temps de lire ce post et de réfléchir à une solution.
Et évidemment, si j'avance de mon côté je vous tiendrais informé.

Krusty.

titofe

Bonjour,

Proxy transparent ou non-transparent ?

krusty

Salut Titofe

Vu que je souhaites "nater" ce qui est en direction du port 80 vers le port 3128 du proxy, c'est en effet pour qu'il soit transparent.

titofe

Bonjour,

@krusty:

Vu que je souhaites "nater" ce qui est en direction du port 80 vers le port 3128 du proxy, c'est en effet pour qu'il soit transparent.

Même si cela parais évident …

Par contre dans cette configuration, je ne vois pas ou ce trouve le problème ou alors je n'ai pas compris la question?!
Il ai vrai que je ne comprend pas pourquoi autant de pfSense, mais en fessant simple, le Proxy ce trouve sur la patte WAN de pfSense2 et les serveur dit de confiance ce trouve sur une patte OPT, donc à aucun moment les requêtes des serveur dit de confiance iront interroger le Proxy.

Si il y a problème de cheminement, je le vois plus côté de pfSense3.

Question: pourquoi autant de pfSense?

Cdt,

Ps: On ai pas contre de plus d'information.

krusty

Pourquoi autant de pfSense?

Il faut savoir que mon réseau est bien plus complexe que ça. J'ai représenté que les éléments utile à mon problème. et donc les différents matériel inclus.
Par exemple:

entre pfsense1 et pfsense2 nous avons des serveur accessible depuis internet
entre pfsense2 et pfsense3 nous avons un switch dont une patte est relié à un 4ieme pfsense qui sert à nous protégé d'une connexion vpn (que je ne gère pas).
etc..
Mais ceci ne nous intéresse pas pour le présent problème.

Je vais faire un petit historique:

Jusqu'à maintenant, notre proxy filtrant était installé et configuré sur pfsense2. Du coup pas de chichi, toute communication sur le port 80 passais par le filtre (aussi bien celle en direction d'Internet que celle en direction de la dmz interne).
Maintenant, nous cherchons à gagner en performance et donc ne pas effectuer de filtrage pour les communications sur le port 80 vers la dmz_interne (et/ou vers le vpn). D'ou l'idée de sortir le filtre de pfsense2 et le placer juste après (dans le sens de la sortie). Du coup on se retrouve à devoir dire à pfsense2 que tout ce qu'il reçoit sur le port 80 doit être redirigé vers le proxy sur le port 3128 sauf pour ce qui est en destination de la dmz interne.

petite interprétation du but à atteindre:
###################################################
1er échange:

flux1: bonjour pfsense2, je veux aller sur le site de google
pfsense2: bonjour, veuillez vous rendre sur le proxy porte 3128
flux1: bonjour proxy, je voudrais aller sur google
proxy: google autorisé, passez.

2ieme échange:

flux2: bonjour pfsense2, je voudrais aller sur le serveur webserv dans la dmz interne porte 80
pfsense2: bonjour, veuillez passer par pfsense3

3ieme échange:

flux3: bonjour pfsense2, j'aimerais accéder à ta porte 80
pfsense2: bienvenue
###################################################

ce qu'il en est en ce moment:
Première échange: pas compliqué, c'est du nat
Deuxieme echange: vu que c'est natté pfsense lui dit tout de même d'aller voir proxy
troisieme echange: même raison, c'est natté du coup il passe par le proxy aussi

Voilà, j'espère que c'est un peu plus clair comme ça. C'est pas toujours évident d'être perspicace, veuillez m'excuser.

ccnet

Voici grosso-modo …

Hélas ! En sécurité le diable est dans les détails. Le traitement d'un besoin sécurité s'accomode assez mal d'approximation.

Il faut savoir que mon réseau est bien plus complexe que ça.

C'est en général ce qu'écrivent tous les administrateurs qui soumettent des architectures hors norme et inutilement compliquées.

Avec deux dmz, un accès vpn, un proxy et des serveurs accessibles depuis le net, il n'y a aucune raison pour une telle architecture. Celle vous conduit à des problèmes difficiles à résoudre du simple fait de la complexité de l'architecture.
Rien de tout cela ne va dans le sens de la sécurité, bien au contraire.
Cette architecture serait plus efficace, plus maintenanble, avec des flux clairs et centralisés. Elle pourrait comporter le cas échéant des liaisons wan supplémentaires. Votre problème s'en trouverait simplifié. Il serait utile et pertinent que tous les services accessibles depuis internet le soient au travers de mandataire (relais SMTP, reverses proxy, …) en dmz externe alors que les serveurs sont dans une autre dmz, éventuellement "firewallisé" au niveau de chaque OS et cloisonné dans des Vlans.

INTERNET
|
|
DMZ_externe–--Pfsense---- DMZ_interne (proxy)
|
|
|
LAN

krusty

Ah, ccnet !
Après avoir lu plusieurs de tes messages posté sur ce forum, j'attendais ton intervention avec hâte ;)

Je vais te répondre au sujet d'une architecture aussi complexe. Étant dans un organisme encore récent et en pleine expansion nous n'avons pas pu investir dans des par-feux digne de ce nom. Nous utilisons de vieille bécane sur lesquelles nous avons installer pfsense. Donc oui ton schéma réseaux est bien-évidemment plus simple, mais nous n'avons pas de pc pouvant accueillir 5 carte réseaux (oui 5 car une patte est relier à un vpn propriétaire), mais 3 au grand maximum. Puis je crains qu'une tel archi surcharge le par-feux (encore qu'il faudrait en faire des tests).

Bref, nous nous penchons vers une solution qui serait de changer physiquement pfsens1 par une autre bécane pouvant nous permettre d'avoir 3 carte réseaux et ainsi ouvrir une dmz externe dessus et y placer notre proxy.

Mais par curiosité j'aurais bien voulu savoir si des solutions existe pour faire de la redirection de port selon la destination avec pfsense ou autre chose.

ccnet

Que votre impatience soit récompensée !!

Étant dans un organisme encore récent et en pleine expansion nous n'avons pas pu investir dans des par-feux digne de ce nom.

Pfsense est un parefeu digne de ce nom donc tout va bien. Un DL380 G4 BiPro 3Ghhz se trouve facilemement pour environ 250 euros. C'est un vrai serveur, toujours mieux que des vieux PC. Ce qui n'explique pas le choix d'architecture.

mais nous n'avons pas de pc pouvant accueillir 5 carte réseaux (oui 5 car une patte est relier à un vpn propriétaire), mais 3 au grand maximum

Une carte carte réseau Intel quadri port résoud le problème. Problème que nous avons tous.

Puis je crains qu'une tel archi surcharge le par-feux

Non, je ne le pense pas. J'en suis même certain. Cette documentation vous donnera des références :
http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49

Mais par curiosité j'aurais bien voulu savoir si des solutions existent pour faire de la redirection de ports selon la destination avec pfsense ou autre chose.

Ce sera un peu différent. mais bref. Si vous reteniez cette hypothèse en terme d'architecture réseau je vais vous fournir dès que j'en ai le temps une solution qui devrait répondre à votre problème. Le temps de ressortir un dossier un peu ancien.

ccnet

Par ailleurs, lors de l'un de mes test, j'ai remarqué qu'en redirigeant le port 80 vers le proxy (sur pfsense2), je ne pouvais plus accéder à l'interface de pfsense (logique me diriez-vous vu qu'il s'agit de http). Existe t-il un moyen pour éviter ceci?

Il est préférable d'utiliser https pour administrer Pfsense. Vous pouvez redéfinir le port d'écoute de Pfsense en 445 par exemple. Si vous utilisez un seul Pfsense et un proxy en dmz sur une Debian + Squid + les packages nécessaires, le problème ne se posera plus.
Une règle autorisant http et https uniquement pour les adresses de la dmz à atteindre placée avant la régle de nat devrait suffire.

jdh

Je plussoie bien évidemment ccnet : un seul pfsense devrait suffire pour tout gérer.

Récemment, j'ai acheté 2 Dell R210 neuf avec 1 carte quad port intel dans chacun : 6 ports par machine, il y a de quoi faire ! (Bon cela fait quelques switchs à côté : je suis vieille école : une zone, un switch !)

De plus, cela permet d'unifier les alias, la façon d'écrire les règles, … Simple.

Dans une DMZ, je place un proxy : une basic Debian (éventuellement avec son propre ADSL) avec ce qui convient : Squid, SquidGuard, LightSquid, un petit script iptables, ... Basic

krusty

Merci beaucoup pour vos réponse, ça m'a permis de remettre en question la structure du réseaux et en effet il y a moyen de limiter les chemins superflu.
Du coup grosse charge de boulot supplémentaire mais c'est pour un avenir plus glorieux héhéé.

Encore merci, et ccnet, ne te prends pas forcément la tête si tu ne retrouve pas l'info, ça ne sera pas le bout du monde pour autant ;)

Allez, bonne continuation à vous

ccnet

Je pense que cette solution devrait convenir :

Une règle autorisant http et https uniquement pour les adresses de la dmz à atteindre placée avant la régle nat (celle qui autorise l'accès à la dmz vers le port 3128) devrait suffire.
Il faudra aussi bien regarder la configuration dns (split horizon) afin que la même url fonctionne dans le réseau local comme en dehors.

Bon courage.