Merci de créer un nouveau fil pour vos questions en détaillant vote configuration complètement dès le premier post.

Voilà, je possède un réseau virtuel (VMWARE) complet avec ipsense et 3 interfaces :

Pouvez vous décrire d'un part le hardware et d'autre part les configuration réseau autant au niveau ethernet que ip.
J'ai installé et utilisé (et utilise en prod) chez de nombreux clients des dizaines de fois Pfsense et je n'ai jamais constaté de tels problèmes sauf hardware défaillants ou non validés.
Vos logs Pfsense seront bienvenus aussi.

Merci tous de prendre le temps de me répondre c'est très aimable a vous  :D

@Tatave:

Question  : Pourquoi ne pas mettre ces machines dans un vlan et de tel sorte qu'elles communiquent entre elles ?  si j'ai bien compris ou suivi le poste

En fait j'ai déjà un Vlan; c'est un peut compliqué je vais essayer de shématiser ça (j'ai pas de visio sous la main  >:( )

Logiciel Sur Vm–-----------------pfSense (Entrée dans le Vlan X)------------------R1(Sortie du Vlan X)------------(Équipements)

J’espère que c'est assez clair, mais pfSense et R1 font office de routeur ici (je vais me faire taper sur les doigts  ::) )
Je ne peux pas modifier les adressage réseau des ces deux réseaux.
J'espère que j'ai un peut éclaircis le shéma Tatave au besoins quand je rentrerais chez moi j'essayerais de faire un visio.
Dans tout les cas rajouter un Vlan par dessus ça me parais très compliqué.

@Chris Oui grosse incompréhension j'ai foncé tête baissée, mais merci pour ta lumière Chris :)

@Endast Merci, n'hésite pas a passer.

Bon maintenant j'ai quelques questions, si ça ne vous dérange pas d'éclairer ma lanterne.
Quand je regarde le liens de la solution donné initialement : http://www.vttoth.com/CMS/index.php/technical-notes/63#Appendix
Je me pose deux question, la première est comment faire si les port d’émission de broadcast ne sont pas static et quel est la différence avec le port fowarding présent dans pfSense.

Je m'explique, j'ai actuellement fais une redirection de port de mon interface pfSense vers la machine qui a le logiciel en question, les trames arrivent bien jusqu'à elle mais pas les broadcast. Cerais-ce parce-qu’elle ne sont pas directement dirigé sur l'ip de ma machine pfSense ?
Si ma supposition s’avère vrai pourquoi dans ce cas le paquet UDP-Proxy me permettrais de le faire, je suis pas sur de bien comprendre son fonctionnement.
Il relaye bien un paquet arrivant sur un port X de son WAN sur sont interface LAN.

Dans tout les cas merci pour vos réponses, j'apprends toujours en venant ici et c'est très plaisant.

Mes serveurs DNS sont bien les AD également.

Du coup, quand un serveur DNS est aussi un contrôleur de domaine AD, et qu'on veut avec un DNS forwarder résoudre des noms locaux, il faut les ajouter manuellement dans domain Override  :)

Je n'ai pas tout compris vos réponses, du coup je vous fais un résumé et je vous joint la config openvpn que j'ai en place sur mon routeur
Pour résumer, j'ai 1 routeur pfSense côté Serveur (RT1) et un routeur pfSense côté Client (RTClient).

Sur le routeur RT1, je suis en MultiWAN, du coup je souhaites mettre en place une configuration de failover automatique (Si possible) de mon serveur OpenVPN.
Du coup j'ai paramétré deux serveurs OpenVPN sur le RT1 avec la même configuration sauf sur l'interface réseau. Sur le client, j'ai mis dans les options avancés une iroute pour pouvoir joindre mon réseau client et deux remote vers les adresses WAN1 et WAN2.

Sur le routeur client RTClient, j'ai configuré le client VPN pour aller pointer vers le serveur sur WAN1 et dans les options avancés, j'ai mis un remote pour aller vers le serveur sur WAN2.

Lorsque je coupe WAN1, sur mon routeur RT1, je vois au bout quelques instants (1minute environ), que mon client se reconnecte sur le serveur OpenVPN attaché à WAN2 cette fois ci.
Cependant je ne peux joindre le réseau de mon client car dans les routes de RT1, pour joindre le réseau 10.X.X.0/24, il passe par la GW 10.0.8.A qui correspond à la VirtualIP du Tunnel lorsqu'on est connecté sur le serveur OpenVPN de WAN1. Sur mon routeur client, j'ai le même soucis.
Est ce que le paramétrage de mes serveurs et client OpenVPN sont mauvais ou est ce que j'ai oublié des options ?

Merci de votre aide

openvpn-config-RT1(Serveur).txt
openvpn-config-RTClient(Client).txt

Pour compléter la réponse déjà très claire de ccnet, il ne faut pas non plus négliger les aspects de performance.

Si les VLAN doivent tous être isolés les uns des autres, il n'y a généralement pas ce type de soucis (performance) mais dès lors que tu vas mettre en œuvre des VLAN pour des environnements hébergeant des services partagés pour plusieurs VLANs (par exemple un datacentre)  il va falloir, idéalement, faire du trunking pour supporter le lien inter-VLAN. Le bon dimensionnement des routeur de niveau 3 est important (je ne dis pas qu'il y a forcément un bottleneck mais qu'il faut y penser).

De même dans un environnement compartimenté via des VLANs, il est parfois utile voir indispensable de se ménager un ou des VLAN dédiés à des fins d'administration  ;)

il s'agit du routage nécessaire au dialogue (Diffie Helman) d'échange de clé.

Ne mélangez pas tout. Dès lors que vous pouvez effectivement joindre le serveur OPenvpn sur le port 1194 le tunnel pourrait être monté correctement.
A vérifier dans l'ordre :
La présence des fichiers .p12 et .key corrects sur le client. Il semble que ce soir le cas.
La possibilité de joindre effectivement le serveur de destination. Ce qui suppose sur celui-ci l'autorisation depuis any vers l'ip du vpn pour UDP/1194. A vérifier en regardant les logs.
Ensuite si vous voulez parler paramètres cryptographiques, vous ne devriez pas utiliser sha-1 pour le Hmac. Il n'est plus considéré comme sûr.
Dans votre fichier ovpn, si votre client est une machine Windows Seven il manque deux lignes de configuration, cette fois ci pour le routage justement :

route-method exe route-delay 2

Par ailleurs le routage dépendra de l'option push route éventuelle côté serveur.
Aucun nat n'est nécessaire du côté du serveur.
Vérifiez tout cela et laissez Diffie et Hellman tranquilles !

@ccnet:

Puisque je l'ai rédigé, cela m'évite de me répéter : https://forum.pfsense.org/index.php?topic=90750.msg501996#msg501996
Par ailleurs la solution, une solution en tout cas, se trouve du côté de Squid.
http://www.squid-cache.org/mail-archive/squid-dev/201104/0009.html
http://www.squid-cache.org/Doc/config/external_acl_type/

Bonjour, une des autres solutions pour gérer le temps des connexions se trouve dans radius si je me trompe pas. Je vais suivre cette piste. vu que c'est déjà via radius que je gère le timeout de chaque utilisateur individuellement mais je vais voir si c'est possible pour des groupes.

Le gros problème est que pour la suite je devrais laisser l'administration de la base  des utilisateurs à des employés de bibliothèque. J'ai trouvé un moyen pour qu'ils puissent ajouter des utilisateurs à ldap via une interface graphique mais impossible pour eux de gèrer leur temps de connexion.

Merci en tout cas pour la piste sur squid.

Compte tenu des problèmes que semblent rencontrer les utilisateurs de Squid sur la 2.2 (d'une manière générale et sans même regarder les aspects authentification), la bonne solution serait quand même de faire tourner un Squid sur un autre serveur.

Si tu tiens absolument à garder Squid sur pfSense, une réinstallation en 2.1 me semble toute indiquée.

Christian

80.10.124.152 est un équipement réseau de Orange (probablement ton ISP  ;))

D'accord, je prends ça en note.
Merci pour votre réponse

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.