[Résolu] Pfsense - Partage de bande passante

[jdhog]

Bonjour,

Suite à une panne sur un serveur IPCop, j'ai du opter pour pfsense qui supporte mieux le matériel récent.

La conf est basique :
- 1 Lien Wan en PPPoE sur modem ADSL
- 1 Lien Lan vers le réseau local
- 1 Lien Opt1 vers une DMZ

NAT de WAN vers LAN et OPT1 (deux subnet distincts)
Blocage de tout le traffic Wan vers LAN
Blocage de tout le traffic Wan vers OPT1
Blocage de tout le traffic OPT1 vers Lan
Ouverture totale de LAN vers WAN et OPT1
Ouverture totale de OPT1 vers WAN

Jusqu'ici, tout fonctionne bien !

Sauf qu'une fois la machine en production (environ 15 postes clients) sur LAN. Il suffit qu'un poste opère un gros téléchargement sur Internet pour paralyser tout le système, la bande passante maximum de mon interface WAN est intégralement absorbée par ce téléchargement. Plus moyen de se connecter à l'extérieur en http, ftp, smtp ou pop3.

Le problème ne s'est jamais posé avec la box IPCop qui répartissait automatiquement le trafic entre les machines clientes et protocoles de manière très satisfaisante.

J'ai parcouru pas mal de doc pfsense et je suppose que ça passe par le traffic shaper (merci de confirmer) mais je n'ai rien compris, mais alors rien du tout à la manière de configurer ça correctement. Gros mélange entre les bandes passantes dans un sens et dans l'autre puis par protocoles....

J'avoue avoir du mal à comprendre pourquoi il n'existe pas un paramétrage par défaut vu qu'en l'état, le système est juste inutilisable (en tout cas sur mon site).

Par ailleurs, si j'ai bien compris, le traffic shapper fonctionne par protocole puis par interface. Existe t'il un moyen "simple" de répartir la bande passante par utilisateur ?



Merci d'avance pour votre aide.

[ccnet]

J'avoue avoir du mal à comprendre pourquoi il n'existe pas un paramétrage par défaut vu qu'en l'état, le système est juste inutilisable (en tout cas sur mon site).

Par défaut le Traffic Shaper n'est pas actif dans Pfsense. J'ai plusieurs Pfsense en production chez des clients et je n'ai jamais rencontré ce problème de consommation de la bande passante par un seul et unique utilisateur lors d'un téléchargement. Et pourtant j'en connais qui ne se privent pas.

[jdhog]

Et ça se passe bien sans traffic Shaper, ou après l'avoir soigneusement configuré ?

[ccnet]

Sans.

[jdh]

Un pfSense qui fonctionnerait mal à la base ?

Non, pfSense fonctionne immédiatement et correctement, et sans aucun réglage de traffic shaping !
(Et il est TRES souhaitable de laisser les réglages PAR DEFAUT, sauf la règle de défaut à partir de LAN.)


Il est notable que vous ne semblez pas comprendre comment on configure pfSense :
Blocage de tout le traffic Wan vers LAN => inutile : pas de règles = pas de trafic
Blocage de tout le traffic Wan vers OPT1 => inutile : pas de règles = pas de trafic
Blocage de tout le traffic OPT1 vers Lan => inutile : pas de règles = pas de trafic (je serais curieux de voir cette règle)

Quand aux autres règles, ce n'est pas mieux qu'un routeur
Ouverture totale de LAN vers WAN et OPT1 => mauvaise règle
Ouverture totale de OPT1 vers WAN => mauvaise règle (je serais curieux de voir cette règle)
Ces règles ne doivent être actives que juste après l'installation : on ne peut mettre en production ceci.


Il faut savoir que les règles s'écrivent dans des onglets qui représente l'interface d'arrivée du paquet.

Par ailleurs, par nature, une session, pour les protocoles usuels, est capable de prendre la bande passante.
Mais il m'étonne que cela bloque tout autre trafic !
Le problème est sans doute ailleurs ... et vous avez tout sous les yeux !

[jdhog]

Un pfSense qui fonctionnerait mal à la base ?

Non, pfSense fonctionne immédiatement et correctement, et sans aucun réglage de traffic shaping !
(Et il est TRES souhaitable de laisser les réglages PAR DEFAUT, sauf la règle de défaut à partir de LAN.)

C'est ce que j'ai fait, et le problème de monopolisation de la bande passante est apparu immédiatement.

Il est notable que vous ne semblez pas comprendre comment on configure pfSense :
Blocage de tout le traffic Wan vers LAN => inutile : pas de règles = pas de trafic
Blocage de tout le traffic Wan vers OPT1 => inutile : pas de règles = pas de trafic
Blocage de tout le traffic OPT1 vers Lan => inutile : pas de règles = pas de trafic (je serais curieux de voir cette règle)

Quand aux autres règles, ce n'est pas mieux qu'un routeur
Ouverture totale de LAN vers WAN et OPT1 => mauvaise règle
Ouverture totale de OPT1 vers WAN => mauvaise règle (je serais curieux de voir cette règle)
Ces règles ne doivent être actives que juste après l'installation : on ne peut mettre en production ceci.

OK, j'ai dû mal m'exprimer. J'ai bien compris que tout ce qui n'est pas expressément autorisé est bloqué par Pfsense.
Donc mes explications ci-dessus ne reflètent pas les règles que j'ai mises en place mais les possibilités de trafic et les blocages de la configuration par défaut. La seule modification, règle que j'ai écrite concerne le trafic de LAN vers OPT1.

Quand j'écris "Ouverture totale de LAN vers OPT1", c'est mal exprimé. il faut comprendre mise en place d'une règle sur LAN qui autorise le trafic vers OPT1.

Vous dites que la règle par défaut de LAN ne doit pas être utilisée en production, qu'est il recommandé de faire (rien vu dans les tutos) ?

Par ailleurs, par nature, une session, pour les protocoles usuels, est capable de prendre la bande passante.
Mais il m'étonne que cela bloque tout autre trafic !
Le problème est sans doute ailleurs ... et vous avez tout sous les yeux !

Probable mais j'avoue que ça m'échappe pour l'instant.

[jdh]

Un pfSense, fraichement installé, n'a qu'une seule règle installée : depuis le LAN tout est autorisé.
C'est à dire n'importe quel protocole, n'importe quelle destination.

Cette règle permet de tester, vite et bien, à partir d'un PC dans le LAN.

Dès que les tests minimum sont réalisés, on passe, dans un mode pro, avec le filtrage en sortie.

Chacun sa méthode.
Pour moi, c'est un tableau du genre :

LAN -> WAN :
machine -> machine / proto
...

LAN -> DMZ :
machine -> machine / proto
...

Et ainsi de suite ...

Il est alors très facile de créer des alias puis de créer les règles (en utilisant les alias).
Nota : je créé des alias en "normant" les noms : portxxx pour désigner un port, srvxxx pour un serveur, lanxxx pour un réseau
J'utilise très abondamment les alias : j'évite une règle avec une ip en dur, de cette façon, on change l'alias et plus besoin de changer la règle ...

[jdhog]

J'ai du mal à comprendre une règle du type LAN -> WAN : machine -> machine / proto : Filtrage par protocole ok, mais limiter à certaines machines sur WAN !???

Même par protocole, ça fait un paquet de règles à mettre en place ça. Est-ce que vous savez où on peut trouver une liste des protocoles usuels qui seront nécessaires ?
Et que faire si on ne sait pas quels ports seront utilisés, par exemple dans le cas de connexions sortantes en ftp passif ? il est difficile d'établir une liste des ports utilisés...

La question est peut être stupide, mais quel est l'intérêt de faire du filtrage en sortie si à priori on a pas l'intention de restreindre les utilisateurs ?

LAN -> DMZ : Ok, vu le nombre limité de machines et services en DMZ, ça parait beaucoup plus jouable, mais là encore, je m'interroge sur l'intérêt d'un tel filtrage.


PS : Concernant le problème de répartition de bande passante, je suis sur une piste. J'avais forcé Wan à 10MB-Full duplex. Ca avait l'air ok et ne génèrait pas d'erreurs dans les stats de la ligne mais je pense que le problème vient de là : Sur le firewall IPCop, la ligne était en autoneg, ce qui aboutissait en 10/Half (logiquement il y a des collisions, mais non pénalisantes); après l'avoir forcée en full, j'ai un comportement très similaire aux problèmes que je rencontre avec pfsense.

[jdh]

Un paquet de règles ?

source -> destination / proto
srv dns local -> any / dns
proxy -> any / http, https, ftp
srv mail -> relais mail (dmz) / smtp
relais mail (dmz) -> any / smtp
(NAT) any -> relais mail (dmz) / smtp
(NAT) any -> srv web / http, https
(NAT) any -> srv ftp / ftp
srv en dmz -> srv dns local /dns

Voilà pour la base : cela fait 8 règles, ce n'est pas un paquet !
Bon, même multiplié par 2 ou 3, ce n'est pas beaucoup !

Et puis, en faire la liste, c'est déjà les maitriser !
Et ne pas en faire la liste, c'est la non sécurité ... jusqu'au problème !

Quand à ne pas limiter les utilisateurs, c'est juste très "unsecure" et, de mon point de vue, irresponsable.

[jdhog]

OK OK, c'est juste que je ne suis pas habitué, jusqu'ici, le firewall était un IPCop en 1.4.21 ou la philosophie de la conf de base est de tout laisser passer de LAN vers WAN...
Bon, vu les utilisateurs du réseau, il va quand même falloir que j'ouvre un peu si je veux pas les avoir sur le dos à longueur de journée. Ils ont leurs habitudes (messageries diverses, connexions à des pops et smtp chez divers providers, protocoles exotiques). Si je coupe tout d'un coup, je risque fort d'avoir pas mal de soucis, je pense qu'il va falloir y aller progressivement.

Mais je comprends bien l'idée générale, et je dois probablement pouvoir mettre en place une solution un peu plus permissive sans toutefois remettre en cause la sécurité du réseau.

Merci pour tous ces conseils.


------------------------

Bon le problème de répartition de bande passante est résolu, il y avait en fait deux erreurs de configuration de la ligne WAN :

1) Le forçage du lien PPPoE en 10MB Full-duplex était une très très mauvaise idée. Il en résulte le comportement décrit plus haut, il était possible de passer un trafic important, mais à partir du moment ou un utilisateur générait beaucoup de trafic, toutes les autres sessions devenaient quasi impossibles. Retour à la normale après passage en autoneg qui aboutit à 10Mb/s Hal-duplex.

2) Le MTU de la ligne PPPoE : Par défaut, j'ai laissé le champ vide, soit un MTU de 1492. La connexion WAN se faisait mais l'accès WAN était très perturbé, voir quasi impossible à partir de certaines machines. Le comportement était très différent d'une machine à l'autre. J'ai remarqué que sur la machine IPCOP, le MTU était automatiquement fixé à 1456. Après application de ce MTU pour la machine Pfsense, tout est rentré dans l'ordre. Notre ligne ADSL est chez Orange, je n'ai trouvé aucune info chez eux à propos de cette valeur.

Mea culpa, je retire toutes les vilénies que j'ai pu proférer à l'encontre de pfsense

[jdh]

Je/nous préfère/rons ce retour "qualifié" :
- le mode auto est toujours préférable pour une interface ethernet,
- le mtu doit être adapté au fournisseur.

Dons pfSense n'est pas en cause formelle.


Concernant les règles de sécurité, il faut être responsable.
Par exemple, je ne créé aucune règle pour permettre pop et smtp à tout le monde !
Si dans la société, on utilise pop, la règle est "pop vers les serveurs du fai" et pas "vers tous les fai" !
Parce qu'alors chacun ajoute son compte perso à Outlook et c'est le bazar. Donc non !
(Cela dit, je ne peux les empêcher d'aller sur leur webmail ! Mais là il passe dans le proxy qui peut filtrer les pièces jointes comme la suite antivirus de leur pc !)

[jdhog]

Dons pfSense n'est pas en cause formelle.

C'est bien pour ça que j'ai pris la peine de poster mon feedback. Désolé pour la nuisance.


Pour le reste, on tourne pour l'instant avec la règle LAN par défaut que j'ai modifié en destination !DMZ au lieu de any.

Je vais tester les règles d'ouvertures ciblées en commençant par la DMZ où je n'ai qu'un serveur et des services limités à gérer. Une fois que j'aurai bien saisi tout ça, je fermerai progressivement le traffic sortant de LAN.

Petite question : pour ouvrir quelques ports à mon serveur DMZ vers WAN j'ai procédé ainsi :

- Création d'un Alias pour les ports voulus
- Création d'un Alias pour mon serveur
- Mise en place d'une régle du type : Pass : Mon_serveur_DMZ -> ! LAN_Subnet / "Mon Alias de ports"

Le but étant de n'ouvrir ces ports que pour ce serveur vers WAN et conserver tous les blocages vers LAN. Est-ce correct ou y a t'il plus simple ?

Il mes semble que des règles écrites comme ça sont efficaces tant qu'on ajoute pas de nouvelle interface. L'autre solution que j'ai trouvé étant de faire une règle qui bloque tout de DMZ -> LAN puis une qui autorise les ports voulus de DMZ -> any.