Je confirme que c'est bien ma carte réseau qui a un problème. J'ai switché mon interface WLAN de carte physique et ça fonctionne.

Merci quand même pour votre aide :)

Et rien de bizarre au niveau des DHCP leases dans le GUI?

Menu Status –> DHCP Leases

Dsl j'ai oublié,
  dans le DNS décocher (Allow DNS server list to be overridden by DHCP/PPP on WAN)

Salut,

Pour ma part j'ai des dizaines de configurations avec des VLAN taggés sur une interface active, mon record pour le moment est de 34 VLAN sur une carte Intel.

Il faut savoir qu'en fonction du driver utilisé (bce,bge,em,igb etc.) il est souvent nécessaire de rebooter pfsense avant que des trames taggées ne puissent entrer/sortir de la carte. On peut rapidement se faire avoir et croire que ce n'est pas fonctionnel.

Après le lecture et vérification des captures d'ecrans, ce setup semble correct.
Ne vous manquerait-il pas une règle de NAT outbound pour vos réseaux 101 et 102 car si ils obtiennent une IP via DHcP il y a continuité de niveau 2 et les VLAN ne sont pas le problème.

Un réel cloisonnement implique que le réseau wifi soit connecté à une interface séparée du firewall. Une autre interface sera connecté au réseau local de l'entreprise.

Je n'ai pas bien compris les differentes liasons entre le materiel de mon reseau:
j'ai le serveur pfsense et le routeur wifi (linksys). A l'entré du reseau se trouve le firewall (que j'utilise pas directement pour le moment).

que le réseau wifi soit connecté à une interface séparée du firewall

c'est quelle interface qui doit être connecté au firewall? (mon routeur wifi ou bien une interface de mon pfsense)

Une autre interface sera connecté au réseau local de l'entreprise.

s'agit il ici du routeur wifi à connecter directement au reseau local?

En fait j'ai un problème avec les differentes liasons qui doivent se faire entre serveur pfsense,routeur linksys et le firewall.

Merci bien de m'eclaircir !

On atteint des sommets …

Normaux les up and down incessants des interfaces réseaux ?

Je ne crois pas qu'une clé puisse impacter la longueur des "vouchers" (à moins que je n'aurais rien compris à un voucher).

Les voucheur sont des nombres/chaines (clés alphanumériques) qui permettent l'authentification au niveau du portail ainsi qu'une certaine durée de temps d'utilisation.

Il faut donc rechercher comment ils sont générés, puis stockés en vue de l'utilisation.

Visiblement, vous avez trouvé un fichier "voucher.c" (puisque vous avez copié 2 lignes au début).
A moins que ce soit le how-to http://doc.pfsense.org/index.php/Captive_Portal_Vouchers
Mais la clé a sans doute déjà été créé … (et il n'est pas nécessaire d'en créer une de 64 bits !)

Comme il s'agit d'un sujet peu étudié, il va falloir lire l'anglais ...
On peut trouver quelque chose avec "voucher length" ...

Mea culpa : j'ai interverti les 2 modes !

Outre le post de Juve, on peut lire le toujours très bon http://blog.nicolargo.com/2008/04/ftp-actif-versus-ftp-passif.html qui détaille bien les 2 modes.

En effet.
Merci :)

Effectivement je connais.

Mais j'utilise mon appliance pfsense pour deux raison:

super léger et outil maitrisé par mes équipês (on a quelques centaines de pfsense en production) j'ai adapté la partie authentification pour reposer sur une infra ActiveDirectory (auth via apartenance à un groupe).

J'ai une seule interface car l'appliance est située en DMZ.

L'idée est de lancer le ping depuis Pfsense et de regarder ce qui arrive ou pas sur la machine 10.10.188.110.

FTP sur UDP, peu probable !! Ca vient d'ailleurs !

Le port 20 ne devrait jamais être naté en entrée,c'est qu'on ne connait pas le fonctionnement du protocol !

-> En entrée on NAT et autorise port 21 et range ports passifs
-> En sortie on autorise le serveur à sortir avec en port source le 20 et en destination 1024-65535.

Pour rappel, en FTP, le client se connecte au serveur sur le port 21, c'est le canal de commandes, puis il y a deux modes possibles pour la transmission de données:

actif : c'est le serveur qui établi le canal de données en direction du client, avec une connexion TCP émise de son port 20 (si respect RFC) en direction du client sur un port > 1024 passif : c'est le client qui établi le canal de données en direction du serveur, avec une connexion TCP émise d'un port > 1024 en direction d'un port du serveur > 1024 ( dans la fameuse range passive)

Attention en mode passif, le serveur indique au client l'IP et le Port sur lequel il doit se connecter avec la commande PORT, si le serveur est en IP privée derrière un NAT, il faut lui renseigner un parametre pour qu'il connaisse l'IP publique sur laquelle il est publié, avec d'utiliser celle-ci dans les commandes PORT et non son IP privée….

FTP c'est archaïque mais bon, toujours utilisé...

Un serveur devrait savoir travailler dans les deux modes pour être sûr de servir n'importe quel client.
Maintenant sur Internet, à cause du NAT (eh oui peu de clients sont en IP publique directe avec ports ouverts), la plupart des clients passent en passifs.
Dans le cas d'une connexion active, il faut que le modem/routeur/firewall du client possède un ftp helper pour recevoir et accepter la demande de connexion de données en provenance du serveur (port 20 en source !)

ba dans ce cas là, je fais un réseau du style

windows 7 (reseau 1) <–--> (Réseau 1)[routeur](Réseau 2) <–---> (Réseau 2)[pfsense](Réseau 3) <–-> windows 7 (Réseau 3)

tout en vm et ça devrait passer tranquille ?

C'est bon on m'a indiqué sur un autre post.

Merci quand même

Effectivement, Jdh, tes règles me plaisent !

Je confirme la proposition de JDH.
Utilisez un wpad.

Je viens de résoudre le problème comme quoi l'IP Virtuelle ne répondait pas aux pings. C'était un soucis au niveau de mon hébergeur.

Cependant, désormais que je la ping, je n'ai pas accès a l'interface d'administration …
Et savez vous comment mettre l'interface d'administration en HTTPS a tout hazard.

Oni'

Waou

Tout d'abord quand je parle d'externe cela veut dire que ce n'est pas sur la machine de Pfsense cela me semblait logique.
Bien sur que notre proxy est est en dmz, le placement du réseau que va gérer Pfsense ne dépend pas de moi et cela ne représentera qu'une infime partie du réseau totale dont je ne connais pas l'entièreté, je travail suivant des contraintes. Le réseau est protégé et utilisé par un nombre important d'agent et est géré par une équipe d'ingénieurs qualifiés je pense qu'ils savent ce qu'ils font et mêmes si le font mal je n'ai pas le choix et doit faire de mon mieux pour y intégrer ma solution.

Pour l'authentification vous comprenez de travers mais après relecture ma phrase mérite en effet éclaircicement :
Je disais cela car notre proxy demande habituellement une authentification et un profil classique pouvait donc être réalisé si j'utilisais squid qui propose une option upstream proxy avec un identifiant/mot de passe, la solution avec le nat ne permet pas cela et une règle spéciale doit être définie dans notre proxy pour ne pas demander d'authentification pour les adresse IP de mon réseau. Pour faire de l'identification sur le proxy il nous faudrait faire des modifications sur les postes clients ce qui ne peut pas être fait pour nous car les utilisateurs seront des usagers externes dont nous ne maîtrisons pas le matériel.

Par contre la présence de l'adresse IP est indispensable pour faire le recoupement avec les logs de connexion du portail captif mis en place pour pouvoir dire qui a fait quoi et à quel moment comme le nécessite la législation.

Si vous n'aviez pas compris l'architecture décrite dans le premier post qui était primitive et uniquement vraie pour les premiers tests a été dépassée et était aussi fausse au vu des changements opérés dans notre cahier des charges, cela ne me semblait pas important à préciser au vu des questions qui sont plutôt indépendantes de l'architecture.

Mais j'aurais aimé savoir comment vous voyez idéalement l'enregistrement des logs de consultation des usagers vu que j'utilise Pfsense comme portail captif. La présence d'un proxy est surement indispensable maintenant comment le liez-vous à Pfsense sachant qu'il peut être en coupure mais pas directement relié à internet sur sa patte WAN (je ne suis pas le seul sur cet accès) , notre proxy est sécurisé et disponible sur la patte WAN.
Cela m'aidera peut-être à mieux intégrer Pfsense dans mon réseau.

Merci d'avance.

Toi et Jdh, j'adore vos réponses… souvent avec ce petit ton condescendant...

Tout simplement car tu utilises pfSense comme moi, tu en es un "habitué", que tu as déjà très sûrement des alertes de liens qui tombent, ainsi que de leur retour.
Plus haut on m'indique que ce message n'est pas celui attendu en cas de retour de lien.