J'avais trouvé ces solutions intéressantes, mais je les ai écarté pour les raisons suivantes. Intel Atom N270 1.6 Ghz - 4 ports GbE LAN + 1 port FE LAN (chipset Intel) http://www.osnet.eu/fr/content/firewall-fwa-3035l Cet équipement ne dispose pas de suffisamment de port selon le besoin exprimé. ou pour du très haut de gamme: Intel Pentium M à 2.0GHz - Interface PCI-E sur carte mère GbE LAN 4 ports & port PCI FE LAN 4 ports http://www.osnet.eu/fr/content/firewall-fwa-5010 Cet équipement permettrait d'avoir le nombre de ports suffisants, mais serait limité en cas d'évolution du besoin. Et surtout cette solution dépasse le budget disponible :/ Mais merci pour ces suggestions :)

Et d'intervertir les interfaces entre elles? WAN deviens SDSL et SDSL deviens WAN. changer de carte reseau, de port PCI, Tester sans résultat. De toute façon, le problème est sûrement plus complexe que vous le présentez : plus de réseaux, des vlans, … ? Pour mes premiers tests, non, je suis aller au plus simple et j'utilise bien le schéma donné lors de mon premier post. Quand on réalise des tests, il est impératif, à un moment, de cesser de croire à certains acquis : un dhcp qui fournit correctement une adresse à partir d'une adresse mac peut très bien se mettre à délirer … On est bien d'accord, cependant je n'ai jamais vu un DHCP merdé sur un seul poste et pas sur les autres. Et puis en dhcp, il FAUT regarder les baux : certains serveurs sont configurés pour des baux TROP courts. (Il y a eu une époque où les Freeboites fournissaient des baux de 60 secondes !!). Le baux DHCP d'IPCop est réglé à 1800sec. Ce problème est GRAVE : il faut TOUT regarder, y compris les câbles, les switchs, les cartes réseaux, … J'ai déjà regardé toute la partie physique sans trouvé de cause. J'ai l'habitude face à ce genre de situation de remonter un à un les couches du modèle OSI: physique, liaison … Attention à la méthodologie des tests : pas 3 modifs à la fois : comment sait-on lequel bloque ? Je teste bien mes modifications une par une, jamais plusieurs modifications à la fois. => Il est possible que vous ne compreniez pas à quoi servent les Alias : c'est ABSOLUMENT indispensable d'utiliser le maximum d'Alias dans l'écriture des règles de filtrage. On est aussi tout à fait d'accord. Pour information, j'ai renoncé à régler ce problème, vu que la liaison ADSL sera configuré au final en PPOE et plus en DHCP derrière un IPCop comme c'est le cas actuellement. J'ai testé cette liaison en PPOE et PFSense est opérationnel.

Je suis passé du switch virtuel virtuel vde_swith à un switch physique, un vieux Netgear FST726T ça fonctionne. Conclusion : vde_switch ne sait pas faire correctement du vlan contrairement à ce qui est annoncé à moins que je me sois trompé ce qui n'est pas exclu … Merci à tous de votre collaboration.

couldn't find the proper pskey Problème avec la psk ? ou dissymétrie dans les paramètres de chiffrement IKE ?

Dans les logs systèmes, tu devrais avoir:Dec  1 13:04:07 pfsense apinger: ALARM: 192.168.37.1(192.168.37.1)  *** down ***quand ton lien tombe et``` Dec  1 13:03:45 pfsense apinger: alarm canceled: 192.168.37.1(192.168.37.1)  *** down *** Est-ce le cas ? (Pour le voire, soit tu utilises l'interface web, soit tu te connectes en ssh sur pfsense, et tu affiches les logs avec la commande suivante:``` clog /var/log/system.log ```)

Apparament je crois que mon problème est dû à la présence de Squid en mode transparent, étant donné que je suis en train de mettre en place le Multi Wan, c'est là que ça "couille" Donc je vais enlever Squid, installer Artica et je vous dirais si mes problèmes sont toujours présents, Merci

Merci je vais fouiller tout ça !

Pfsense est configuré pour faire un recover automatique de son filesystem suite à un arrêt brutal (salvage=yes).

nouvelle self réponse : remplacer l'utilisation du dhcp host name en vendor id, puisque je n'utilise pas le hostname. editer /etc/inc/interfaces.inc dans la fonction "interfaces_opt_dhcp_configure", modifier comme suit la ligne avec dhcp-client-identifier: $dhclientconf_hostname = "send dhcp-class-identifier \"{$optcfg['dhcphostname']}\";\n";

re, la solution un rm du dossier squid et squidguard.. merci a mon installateur  ;) a+

Merci c'est bien mieux :-)

J'ajoute ce que je viens de découvrir dans les logs en redémarrant les serveurs DHCP : dhcpd: Sending on BPF/vlan0/02:00:00:c8:e6:61/192.168.100.0/26 dhcpd: Listening on BPF/vlan0/02:00:00:c8:e6:61/192.168.100.0/26 dhcpd: Sending on BPF/vlan1/02:00:00:c8:e6:61/192.168.100.64/26 dhcpd: Listening on BPF/vlan1/02:00:00:c8:e6:61/192.168.100.64/26 dhcpd: Sending on BPF/vlan2/02:00:00:c8:e6:61/192.168.100.128/26 dhcpd: Listening on BPF/vlan2/02:00:00:c8:e6:61/192.168.100.128/26 Là je ne comprends plus très bien ce qui se passe coté PFSense. Pourquoi ce ne sont pas les ID que j'ai données ? Merci d'avance de votre aide.

Bonjour à tous et merci de votre aide. J'ai ramé pas mal pour arriver à la conclusion que le "NAT reflexion" ne pouvait marcher que si le host joignable après une redirection depuis une adresse publique était sur le LAN. Mes serveurs sont en DMZ et de ce coté là il n'y a rien à faire ou alors je n'ai pas réussi … Je suis donc passé à "DNS forwarder" pour les PC raccordés à une interface OPTx qui ne sert qu'à offrir un accès au net par wifi et là ça fonctionne. Bien sûr le serveur DNS est PFSense. Enfin pour les PC sur le LAN qui utilisent un DNS local (Debian + Bind) j'ai adapté named.conf pour avoir un "split DNS" et là ça marche aussi. Cette doc explique bien la chose : http://www.bind9.net/manual/bind/9.3.1/Bv9ARM.ch04.html Merci à tous de votre aide et bon travail

Bonjour ccnet Merci pour votre réponse.

Vous n'avez pas bien saisi. Il n'y passeront jamais. Il faut vous installer une version DEV pour créer les modules drivers puis les copieer sur votre stable.

Bonjour, Oui, c'est normal j'ai changé le port par default. Sinon, j'avais bien quelque chose qui bloquait mon autre réseau je n'avais pas tout les droits en sortie dessus. Tout fonctionne, je te remercie pour ton aide.

En regardant le site d'Ucopia, il me semble que ce produit pourrait être vu comme un proxy-transparent s'installant en coupure entre réseau local et routeur d'accès Internet. Ce produit est centré sur proxy, authentification, filtrage, log, respect prescriptions CNIL. Avec un tel produit, il n'y a normalement AUCUN intérêt à installer le proxy sur le firewall ! Pour les questions https/http, il vaut mieux ne pas se compliquer : l'explication est peu claire ! Je préfèrerais voir ce produit en DMZ et avec une seule interface réseau mais il est positionné pour des non spécialistes. Je réagirais plutôt comme ccnet : un proxy dédié sur une base Debian est meilleure et plus efficace … pour autant qu'on a l'expertise pour la créer et mettre en oeuvre !

Merci pour vos informations.

et c'est par celle la que je voudrais faire l'admin C'est le mode de fonctionnement par défaut de Pfsense. mais surtout pas avoir de prompt login password si il tape l'ip de la gateway. Si vous ne créez pas de règles l'autorisant explicitement ce ne sera pas le cas. je vaudrais aussi qu'il n'y a pas de routage entre le network opt1 et le lan. Pourquoi ? Globalement une bonne lecture de la documentation serait profitable.