Merci Titoffe tu est en or! en effet j'avais vu cette case mais je l'avais lu trop vite j'avais juste retenue "en général laissez cette option sur on"^^ . En tous cas j'aurais pus chercher un moment vraiment merci car 2 jours pour pinguer un wan dur dur :)

@Juve: Dans ce genre de situation, Faites un backup total de votre configuration sans la configuration des package "case à cocher dans le menu backup", réinstaller pfsense et réinjectez la configuration vous repartirez sur de bonnes base. Vous pourrez alors réinstaller vos package. OK merci du conseil, dès que j'ai 5 mn je met en oeuvre ton conseil et remonte l'info sur ce topic

PC avec 3 cartes réseau (pci). A la maison, si on souhaite séparer la fonction firewall (pfSense) et la fonction hébergement-test-nas-…, l'idéal serait d'avoir un petit boitier embarqué pour le firewall. Donc j'ai une vielle Debian avec Shorewall + tous les services qu'il me faut ... En entreprise, c'est direct un PC en salle info, et souvent c'est 2 PC : pfSense sait faire du failover si rapidement !

Enfin ça marche tant que tu ne clique pas sur save dans services –> captive portal sinon ça te remet tout par defaut. Donc toujours le même probléme.

Cherchez dans mes posts, j'explique celà de nombreuses fois. ;D

oki, merci :) Donc voici comment cela fonctionne finalement: Nous avons déclaré les IP's vituelles en Proxy ARP étant donné que nous n'utilisons pas d'option de Forwarding vers ces IPs. En suite nous établissons des règles de port forwarding depuis ces IPs vituelles vers une IP locale. Mise en place des règles de firewall autorisant le trafic depuis Any vers le adresse IP locales sur les ports désignés dans le NAT. Constatation: Si nous voulons que les réponses portent la même source que l'interface par laquelle ils sont entrés il faut quand même utiliser la fonction 1:1 et associer les IPs vituelles aux IPs locales concernées. Avez-vous fait cette même constatation? Néanmoins, je trouve dommage de devoir passer par cette technique car enfin ce serait plus prorpre à mon sens de pourvoir déclarer ces IPs en tant qu'interface et gérer les règle de NAT et de Firewall exactement de la même manière que l'interface WAN par défaut.

v tester merci pour l'info

J'ai trouver ….. J'ai toujours créer mes VPN avec comme port utiliser UDP, je n'ai jamais eu de souci, et sur pfsense, il y a en pas non plus si vous le faite avec une seul interface, par contre avec CARP donc IP virtuel puisque deux firewall ça ne marche pas" et je ne sais pas pourquoi !!! Donc il faut utiliser comme port TCP et tous rentre dans l'ordre. Titofe Cela ne pouvez être que quelque chose d'aussi simple pour que je passe au travers, … plus mes 80 et quelque heures de cette semaine. ;D Ps: encore merci jdh

les règles étaient OK. Le problème venait d'une erreur de masque (erreur de frappe) merci.

Quand on ne peux pas accéder au proxy ce n'est pas trés pratique. J'ai essayer le commande export mais ça ne fonctionne pas donc on ne doit pas pouvoir dommage. Merci

Bonjour, Moi aussi j'ai ce probléme et je n 'est pas encore trouvé de solution mais j'ai une petite technique pour savoir. Lorsque tu regarde les logs d'authentification de ton portail captif tu voit quel utilisateur s'est connecté et surtout quelle adresse ip pfsense lui a attribué. Donc dans lightsquid il te suffit juste de regarder l'adresse ip correspondant à la personne recherché. Cordialement.

Bon je n'étais pas loin. Dans squid.conf j'ai décommenter/modifier 'acl our_networks src 192.168.221.0/24' qui je rappel est mon interface LAN et 'http_access allow our_networks password' au quelle on peux voir que j'ai rajouter 'password' afin que mes utilisateur s'identifie pour allez sur le WEB. Voila si cela peut être utile à quelqu'un. Titofe

tu peut jeter un œil sur http://forum.pfsense.org/index.php/topic,20973.0.html y a des tutos intéressants

Merci :)

Je reviens sur ce post, Dans la config décrite plus haut et ses dérivés pour obtenir le résultat désiré, je constate un trou de sécuritédans ma configuration: Le client peut à tout moment ajouter une route dans son fichier de config qui va lui donner accès à d'autres segments du réseau ou des Vlans qui n'ont pas été autorisés ni sur le serveur ni dans le scc Comment puis-je palier à cette situation? :'(

Je te remercie pour ton retour. Je vais suivre ton conseil concernant le site Christian CALECA A une prochaine, peut-être

C'est maintenant clair. La première et importante différence que je vois réside dans le fait qu'une règle avec une passerelle différente de la passerelle par défaut peut s'appliquer qu'à un protocole, port ou groupe de ports de destination. Ce qui n'est le cas d'une route statique.

Je ne suis pas très versé sur ce type de configuration "domstique" où le proxy tourne sur Pfsense. Je ne le fais jamais. Pourriez vous m'indiquer quelques pistes pour un tutorial sur les Firewall rules pour une configuration simple et les plus utiles ? Pas de recette. Bloquez dans les deux sens tous ce qui n'est pas nécessaire. le trafic sortant est aussi dangereux que le trafic entrant. Dans Firewall: Schedules vous pouvez définir des plages horaires utilisables dans les règles. Servez vous en !

<mode joke="" musical="">Ca m'énerve</mode> Il n'y a pourtant pas beaucoup d'éléments à brancher : (je suppose qu'il y a 1 pc pour pfSense + 1 pc de test + 1 switch + 1 routeur wifi + 2 cartes ethernet) 2 cartes réseaux (je suppose ethernet) : vont dans le pfSense (?), cela va FORCEMENT distinguer 2 réseaux : l'un WAN, l'autre LAN. routeur wifi : de quel côté on peut le brancher ? FORCEMENT du côté LAN. PC (de test) : de quel côté on peut le brancher ? FORCEMENT du côté LAN en ethernet ou en Wifi. 2 éléments à placer : d'où le switch Bref, prendre 2 minutes de réflexion permet d'éviter de poser sur un forum une question aussi aisée … (Va falloir s'y mettre parce que réussir un portail captif demande un peu de réflexion ... cf le n° du mois de Linux Magazine ...)