Ok en tout cas merci d'avoir essayé !

Ah génial, merci d'être repasser, si tu peux édit le titre et marquer résolus ça serais top  :P

Absolument. Aucun mensonge. Pour ceux qui n'ont pas vécu ce grand moment de communication, rappelons les conditions dans lesquelles Microsoft avait obtenu cette certification.
1. Valable pour un seul et unique modèle de serveur de marque Compaq.
2. Sans lecteur de disquette ni lecteur de CD.
3. Le meilleur pour la fin : la machine devait n'être connectée à aucun réseau.

L'approche est clairement insuffisante, typiquement au "doigt mouillé". La segmentation pourrait réduire l'importance des broadcasts. Mais, comme indiqué, les goulots d'étranglement risquent d’apparaitre ailleurs. Le besoin est à clarifier fortement avec des données objectives notamment si il s'agit de performance.

@abrougui:

et j c pas pourquoi tout ça,

Désolé mais sans même répondre à ta question je vais mettre les choses au point (et ce n'est que ma vision personnelle, n'en fait pas une généralité), si tu continue à écrire comme ça (j c) je ne vais même pas lire la suite de ton message ni les messages suivants d'ailleurs. Je suis vieux, le langage SMS ne m’intéresse pas et même si je n'y arrive pas tout le temps, j'essaie, par respect pour le lecteur, de ne pas faire de fautes.
J'apprécierai vraiment que tu fasse de ton coté un effort similaire.
Si ça te gonfle, ça ne me pose pas de problème mais c'est sans moi  ;)

Remarques :

un fil de la semaine parle du même sujet ! vous avez un lien qui est parfaitement explicite du problème, et vous l'indiquez !

Lisez, relisez, (re-relisez), comprenez et agissez …

NB : il est crucial de comprendre le mode 'actif' versus le mode 'passif' de FTP.
Une fois bien compris, cela est tout à fait limpide.

Non  8)

l'autorisation o communiquer, ce n'est pas de la translation d'adresse mais une règle du pare-feu qui dit:

protocole: TCP source IP: 180.33.4.5 source port: any destination IP: 85.245.23.12 destination port: 443 rule: allow

dans le cas bien sûr ou le but est que le serveur distant se connecter au serveur local.
Dans le cas contraire, ça dépend des règles que tu as déjà en interne mais également des règles sur le site distant.

une fois que la communication est autorisée vers cette adresse, il s'agit de la rediriger vers l'adresse interne sur le LAN.

J'ai dans le passé fait des test de ce type, c'est à dire utiliser Pfsense comme base pour des appliances en tout genre, étant entendu que cela restait séparé du firewall. Cela peut fonctionner et fonctionne.
Néanmoins on est dans cette situation un peu bancale lié à la pratique des packages sur Pfsense et a tout ce que cela implique.
Finalement le Squid à "l'ancienne" convient bien. Je suis sur la même ligne que Chris4916. Ce qui permet aussi d'utiliser autre chose que Squid pourquoi pas.

Merci beaucoup pour vos réponses.
En effet pour pfsense 2.2 , la vitesse doit etre à 115200 !
je n'avais pas vu cet info sur le net et j'ai tout tenté en 9600 …

Bonne journée !  ;D

@Endast:

Aussi, une solution de supervision, c'est super, c'est prévu pour, ça marche, c'est secure la plupart du temps… mais j'espère qu'elle ne servira pas qu'à ça vu ce que ça demande comme boulot pour l'installation. Si c'est simplement pour l'envoi d'un mail lorsque c'est up....  c'est un peu dommage.

un monitoring par exemple en snmp (qui n'est pas aussi sécurisé que ça, surtout en V1  ;D)  est effectivement une bonne solution mais je suis d'accord que, plus que "dommage", c'est une machine supplémentaire à gérer, ce qui n'est pas forcément souhaitable selon les environnements et surtout finalement assez lourd si il y a peu de machines à surveiller. Dans ce cas, c'est d'autant plus frustrant que pfSense embarque son propre lot de graphes en tous genres.

un script, par exemple en perl, pour analyser syslog fonctionne également mais c'est malgré tout, si l'option "script local" n'est pas acceptable, une machine supplémentaire pour mettre en oeuvre rsyslog.

Sur le principe, il est effectivement surprenant d'avoir une notification de changement d'état lorsque la gateway est "down" mais de ne pas en avoir lorsqu'elle passe "up".

Bonjour

votre boitier pourrais m’intéresser , si il est toujours a vendre
cdlt

@Endast:

Est-ce que tu as besoin que tes PCs dans des Vlans différents puissent se joindre entre eux ?
Si c'est le cas, les vlans ne sont pas adaptés, car ça m'étonnerait que la box Fai puisse du faire du routage intervlan sur son lien local.

Mais est-ce que ce n'est pas pfSense qui ferait ça dans ce cas ?  ???

Dans tous les cas, il faut quand même commencer pas décrire le résultat (fonctionnel) de ce qu'on souhaite obtenir car ce n'est pas aussi simple qu'il y parait et ta question relative à l'éventuelle communication entre les différents clients renforce ce point.

Assez logiquement, ce devrait/pourrait être, en interne, une communication des clients vers des services qui eux seraient accessibles par les clients de chaque catégorie (clients, invités…)
Mais ce serait une erreur de croire que tout se règle au niveau réseau (ce qu'adresse la notion de VLAN).
Il y aura des services qui nécessiterons un contrôle plus fin: si je reprends l'exemple du NAS évoqué dans le post initial, une fois que ce serveur est accessible via le réseau (et le bon VLAN si c'est la solution retenue), est-il souhaitable que tous les utilisateurs aient le même niveau d'accès ? Anonymes ?

Pas simple n'est-ce pas  ;D

La bonne nouvelle est que ça fonctionne  :)

Mais finalement, ça a du bon qu'il y ait ce genre de problème: même si ça n'a, après coup, rien à voir avec pfSense, ça permet d'échanger un peu sur des design un peu moins basiques qui peuvent répondre à d'autres interrogations (par exemple ce sujet démarré ce jour)

Je rappelle la première phrase de mon premier post :

Un post spécifique sur cette pratique si souvent rencontrée du proxy sur le firewall et la question qui en découle que l'on peut généralisée ainsi : Pourquoi pas de package sur le firewall ?

@C566:

Je souhaite automatiser le lancement de la commande "fusioninventory-agent –debug" avec crontab. Pour cela j'ai entré dans crontab :
43 13 26 4 7 root fusioninventory-agent --debug
La tache se lance à 13h43 le  Dimanche 26/04. Mais cela ne fonctionne pas (après vérification dans GLPI).
Y'a-t-il une erreur dans l'automatisation de ma tâche ?

Effectivement ce n'est pas exactement une problématique pfSense  ;)
Ceci étant, ta commande ne dit pas: "je veux lancer cette tâche le dimanche 23 avril"
Elle dit: "je veux lancer cette tache le 23 avril ou le dimanche".

Si tu regardes la doc, celle-ci dit:

Note: The day of a command's execution can be specified by two fields –
    day of month, and day of week.  If both fields are restricted (ie, are
    not *), the command will be run when either field matches the current
    time.  For example, ``30 4 1,15 * 5'' would cause a command to be run at
    4:30 am on the 1st and 15th of each month, plus every Friday.

En gros, si c'est le 23 avril, pas besoin de spécifier que c'est le dimanche  :P

Ceci étant, qu'est-ce qui te fait dire que ça ne marche pas ?

@chris4916:

@Tatave:

…/... à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.

j'avoue ne pas bien comprendre la finalité  :-[  si tu pouvais développer un peu  ;)  il y a peut-être quelque chose que j'ai raté.[/quote]

J'espérais avoir un peu plus d'information à propos de ce design mais ce n'est pour le moment pas le cas.
Ce design est intrigant et même en y réfléchissant plus en détail, je ne vois pas quelle est la finalité si on considère que l'objectif initial est de mettre à disposition l'accès à des serveurs web hébergés localement à des utilisateurs distants accédant via internet.

Un reverse proxy peut cependant servir à des utilisateurs internes si celui-ci est placé en frontal de serveurs web(1). C'est un moyen efficace de fournir de la haute disponibilité ou de la répartition de charge. Dans ce cas, le positionnement du reverse proxy en DMZ, comme je le montre sur mon schéma, n'est probablement pas le meilleur choix.
En cas d'utilisation d'un reverse proxy à usage (également) interne, si les utilisateurs locaux utilisent un proxy, le flux sur le LAN pourrait devenir:
browser => proxy => reverse proxy => web server

mais le proxy n'apporte pas grand chose, si ce n'est la gestion du cache, AMHA
A noter que pour un utilisateur distant, si un proxy est déployé de son coté, le flux sera exactement le même  :)  sauf qu'entre le proxy et le reverse proxy, il y a le WAN  ;)

Tatave, n'hésite donc pas si tu as une vue différente.

(1): c'est assez courant dans les data-centre

Cette distinction se fait, le cas échéant, au niveau du portail captif pour lequel tu peux configurer un serveur Radius local ou distant.
Il n’y a pas de vraie différence dans la logique de fonctionnement mais peut-être des différences dans ce que le Radius de pfSense permet (expose) en terme de configuration par rapport à un Freeradius "standalone"