tu l'envoi sur une machine linux ou il y a R-syslog dessus…(port 514 en ecoute), puis tu fait un "tcpdump -i [ton interface] src or dst [ton adresse de pf]" pour voir si tes machines communique bien qd il y a un event…et ensuite tu fait un "tail -f /var/log/syslog"  et des qu'un event arrivera tu le verra passer par le tcpdump avant d'ariver sur ton syslog linux...

Il y a plus simple surement, mais moins drole...

Exactement…Mais ce que j'ai remarqué est bien exact ??? et ds ce cas en connaitriez-vous la raison ???

@pierreINT92:

En effet, j'ai supprimé le vlan sur le Pfsense et tout fonctionne bien. Merci pour cette solution.

Mais malgré tout, j'aimerais savoir pourquoi ? Dans ma logique, si la trame n'est pas taggué par le VLAN respectif elle ne peut pas communiquer avec le reste. Alors pourquoi faut il enlever le tagguage sur l'interface WAN du pfsense ?
Peut être ai je trop la logique Cisco …

Justement non, vous n'avez pas la logique Cisco mais la logique des autres constructeurs… Cette dernière étant la "plus logique" je dirais... ;)

En fait, chez Cisco: .

un port en mode access est un port sur lequel le switch va taggé les paquets non-taggés dans le VLAN défini. Par contre, si un paquet taggé arrive sur ce port, le switch va le "dropper"

un port en mode trunk va lui accepter tous les paquets (taggés et non-taggés). Le switch ne changera pas le tag d'un paquet taggé mais si un paquet non taggé arrive, le switch le taggera dans le native vlan (vlan 1 par défaut - configurable avec la commande switch trunk native vlan X)

Donc, en configurant le VLAN sur votre pfSense et le port du switch en mode access, ça ne pouvait pas fonctionner.

@pierreINT92:

En fait, j'ai 3 AP Cisco qui fonctionne en roaming sur deux VAP différents donc deux réseaux différents. Les deux réseaux communiquent bien avec mon firewall principal qui est un Checkpoint pour ensuite aller sur Internet. Je ne peux donc pas connecter mes differentes bornes directement sur ce firewall. Et voilà aussi pourquoi je n'utilise pas Pfsense en tant que firewall car j'en ai déjà un qui est le "coeur de réseau" et qui route entre les différents réseaux.

Pas tout bien compris les raisons mais bon…

@ccnet:

Ok pour la gateway. C'est normal le /31 sur "Source" ? Je ne crois pas surtout pour un single host. Avec un nat 1:1, sans outbound nat, ça devrait fonctionner.

Oui, car elle est grisée… Je ne peux pas la changer...

J'ai mis du Packet capture sur Completel avec 192.168.90.155 sur le port 25, nada.
Par contre, et là c'est normal, je vois les ports 110 et 5125 (SMTP extérieur)

14:02:25.356951 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.357996 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.396929 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.397375 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.397484 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 20 14:02:25.436916 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.437908 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 34 14:02:25.438489 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.438589 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 5 14:02:25.475929 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.492986 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 15 14:02:25.493590 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.504818 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 16 14:02:25.541967 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.543953 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 6 14:02:25.544328 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.544428 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 18 14:02:25.581976 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.587921 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 8 14:02:25.588424 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.588595 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 24 14:02:25.625930 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.627962 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 10 14:02:25.628416 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.629505 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 26 14:02:25.667949 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.672967 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 6 14:02:25.673356 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.673739 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 18 14:02:25.673923 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.712967 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.713472 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.714030 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.714520 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.732976 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.733476 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.752938 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:25.753415 IP 92.103.113.154.110 > 217.128.228.248.53480: tcp 0 14:02:25.792065 IP 217.128.228.248.53480 > 92.103.113.154.110: tcp 0 14:02:31.476580 IP 92.103.113.142 > 92.103.113.141: ICMP echo request, id 8842, seq 0, length 64 14:02:31.477036 IP 92.103.113.141 > 92.103.113.142: ICMP echo reply, id 8842, seq 0, length 64 14:02:32.499641 IP 92.103.113.142 > 92.103.113.141: ICMP echo request, id 8842, seq 1, length 64 14:02:32.500026 IP 92.103.113.141 > 92.103.113.142: ICMP echo reply, id 8842, seq 1, length 64 14:02:33.501575 IP 92.103.113.142 > 92.103.113.141: ICMP echo request, id 8842, seq 2, length 64 14:02:33.501955 IP 92.103.113.141 > 92.103.113.142: ICMP echo reply, id 8842, seq 2, length 64 14:02:34.502445 IP 92.103.113.142 > 92.103.113.141: ICMP echo request, id 8842, seq 3, length 64 14:02:34.502821 IP 92.103.113.141 > 92.103.113.142: ICMP echo reply, id 8842, seq 3, length 64 14:02:35.504326 IP 92.103.113.142 > 92.103.113.141: ICMP echo request, id 8842, seq 4, length 64 14:02:35.504703 IP 92.103.113.141 > 92.103.113.142: ICMP echo reply, id 8842, seq 4, length 64 14:03:04.638186 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 0 14:03:04.639045 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.692178 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 0 14:03:04.692603 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.695487 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 44 14:03:04.751171 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 15 14:03:04.751693 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.754721 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 146 14:03:04.813178 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 12 14:03:04.813630 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.813749 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 18 14:03:04.869179 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 42 14:03:04.869611 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.869740 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 18 14:03:04.924236 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 14 14:03:04.924687 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.934424 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 31 14:03:04.991207 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 45 14:03:04.991641 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:04.991748 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 14 14:03:05.049205 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 35 14:03:05.049714 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:05.050247 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 14 14:03:05.115193 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 6 14:03:05.115611 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:05.115746 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 37 14:03:05.179561 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 1460 14:03:05.182460 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 1152 14:03:05.183044 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:05.238190 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 5 14:03:05.238624 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:05.239417 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 37 14:03:05.497300 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 0 14:03:07.795375 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 0 14:03:07.795588 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 6 14:03:07.795947 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:07.796047 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:07.796121 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 15 14:03:07.796382 IP 92.103.113.154.5125 > 89.2.48.82.54775: tcp 0 14:03:07.851347 IP 89.2.48.82.54775 > 92.103.113.154.5125: tcp 0

EDIT à 14h24 : J'ai repris la règle du Firewall du LAN et j'ai changé le port 25 pour passer à "any"… Et cette fois ci, c'est bon !
L'en-tête de mon message que j'ai reçu a bien 92.103.113.154 comme adresse de serveur de courrier !!

Reste à savoir pourquoi le port 25 n'est pas suffisant…

Encore un grand merci, ccnet, pour ta gentilesse, tes questions et tes réponses qui m'ont permies de solutionner ce problème!!!

@ccnet:

Par contre, je ne suis pas sûr que vous pouvez utiliser une partie de la plage d'adresse du LAN du site A… A vérifier...

Si c'est bon. Source : Definitive Guide - Chap 14. Mais cela valait la peine d'être validé.

Ok. Bon à savoir. Merci pour l'info.

Dans la première capture d'écran, moi j'aurais pas laissé à PASS…

@AldKiki:

[…]J'ai trouvé ma réponse sur un forum Anglais et pour votre info ça fonctionne mais il faut faire du routage manuel car PFSense (même si c'est un UTM niveau 7) ne fait que des routes "implicites" entre ses interfaces, ce qui est normal (cherchez sur Google Multiple LAN Gateway), surtout que je ne suis pas le seul dans ce cas. […]

Solution 2 de mon premier post…

Concernant le routeur Orange machin chose, je ne demandais pas: j'avais juste la flemme de regarder le nom complet sur votre schéma.

@jdh:

On a un schéma, mais on a AUCUNE idée du MOINDRE réglage tenté !

config des interfaces ? quelles règles (NAT et Rules) ?

(En 1.3, il y avait un "FTP Helper" qui devait être coché. Je ne me rappelle pas si cela existe en 2.0)

Et je rajouterais: FTP passif ou actif?

c'est bon problème résolut.

solution :

dans ldap : filter (samaccountname=%{User-Name})
                basedn enlever le cn=users

dans nas/client : créé un client avec 127.0.0.1 et le secret partagé.

merci ccnet pour votre aide.

je reste disponible si quelqu'un souhaite en savoir plus sur la configuration de cette architecture réseau.

reste à finir quelques tests et mise en près production^^

merci encore

Bon tant pis j'utilise pfctl qui est bien plus complet.

Je pense que ce que je voulais faire est impossible avec easyrule à moins de modifier directement le code de cette commande…

Ce serait bien d'ajouter cela à l'avenir peut être que c'est déjà en cours d'ailleurs.

Concernant la doc je ne sais pas si c'est une faute où si j'ai mal compris, mais si c'est une faute ca serait bien de faire remonter l'info ;)

Sinon me concernant tous les problèmes sont réglés grâce a pfctl.

Bonne continuation.

Salut tous le monde,

Problème résolu.

J'ai donc suivi le conseil de jdh pour une réinstallation propre, et plus même. Je m'explique.

Réinitialisation de pfsense en config d'origine + attribution de interface réseau. Pas de changement par rapport à ma première config.

Par doute, j'ai contrôlé le branchement de mes cartes réseau. J'ai peu constater que ma carte fille Intel PRO/1000 CT en PCI Express n'était pas enfiché complétement et qu'il manquait 1mm. J'ai joué sur les vis entre la carte et le bracket low profil pour que ce soit OK. Pour info c'est sur cette carte qu'était et est encore branché mon NAS.

Redémarrage, reconfig comme initialement, à l'exception des noms des interfaces. LAN est resté LAN et OPT1 se nome maintenant LAN2.
Mes règles pare feu sont comme celles indiquées précédemment, et maintenant j'accède à mon NAS sans problème.

Je ne sait pas dire avec certitude d’où venait mon problème, mais maintenant tout est OK.

Merci à ccnet et jdh pour le temps qu'ils m'ont consacré.

A+

Meirick

Pas de MySQL sur Pfsense.
Il y a une interface pour la gestion de la base locale. Je ne saisi pas ce que vous voulez dire par programmatiquement.
Sur le fond la présence d'un annuaire Ldap permettrai de régler une fois pour toute les problématiques d'annuaire, d'authentification, etc … Si c'est possible il faut le faire.

Description confuse, orthographe aléatoire, demande hors sujet (règles sur Watchguard) . je n'aimerai pas être votre client.

Alors hier ça ne fonctionnait pas, pourquoi je ne sais pas j'ai tellement bricolé …
Aujourd'hui après nombres de bricolages ça marche !

Je vais voir ce que cela donne dans le temps.

Personne n'est inspiré????

In modern FreeRADIUS configurations, in general, you '''should not''' set the Auth-Type attribute manually. The server will figure it out on its own, and will do the right thing. That is, the authentication-related modules that you enable (or leave them enabled by default) will set the Auth-Type on their own.

http://wiki.freeradius.org/Auth%20Type

As far as I know pofsense Captive Portal can only do "PAP" authentication so there is no way to use captive portal with EAP.
Perhaps this will change on pfsense 2.1 but I do not know.

Y'a t'il un moyen de rester tout le temps connecter ?

Normal qu'il faille un délai pour remonter une connexion vpn. Si vous examinez les protocoles vpn vous comprendrez pourquoi.

requête DNS de mon poste en spécifiant le serveur DNS : OK, je capture bien la demande, réponse etc…
Requête DNS de mon poste en utilisant mon Pfsense avec les "DNS forwarder" de paramétré vers mon serveur DNS utilisé dans le premier test et là : rien, nada, la capture est vierge

.
Ok. Je pense que le poste ne tente pas d'interroger le dns indiqué. Pour en avoir le coeur net une capture sur le poste avec Wireshark. On saura tout de suite où va la requête dns. Avant peut être vérifier la conf réseau du poste ? Ipconfig /all si c'est une machine Windows.