La capture de trame s'impose. je crains que simplement le serveur radius ne réponde pas. Il reste à déterminer pourquoi ?

Idem. Dans ce qui a été modifié, on ne sait pas ce qui est décisif. Certes cela fonctionne. Personnellement cela m’ennuierait. En effet si votre structure est petite, ce qui semble être la cas, la messagerie en direct ce n'est si simple, c'est même assez lourd à mettre en place sérieusement.

Bon ca doit etre un pb de conf siot sur les pfsense soit sur tes switch ou routeurs entre lse 2…

L'interface failover du carp est-il en lien direct ou passe t il par des vlan et des switchs ???

Sinon technique simple...tu recommence a zero (pour le carp), et tu fait interface un par un...avec bascule pour chaque...c un peu bourrin, mais des fois on peut voir ou ca coince...en meme temps tu met un tcpdump et un tail -f /var/log/syslog et tu regardes ce qui se passe...

Pour le vrrp (carp sous bsd) tu doit voir des trames d'echanges entre chaque interface...vers l'interface backup de l'autre pf...Si tu as 2 master c qu'il ne se voient pas...mais que le carp fonctionne...essaie de suivre ta trame reseau pour savoir ou elle bloque...(as tu pensé a laisser passer les trames vrrp sur ton pf ???

Si jamais tu montes tous tes interfaces, et que cela fonctionne encore pas tres bien, tu peux disables tes regles de firewall et mettre des logs sur des regles que tu te crees pour regarder le vrrp (carp)...tu fait donc un filtre...Le processus est :

La trame arrive sur le pf, elle fait ce qu'elle a a faire (nat ou autre), puis passe par le firewall...si tu fait un tcpdump tu as la trame qd elle arrive, si tu fait un tail -f tu as la trame une fois ds le syslog donc passé le firewall...Si tu vois en reel ta trame s"implementé par tcpdump mais rien sur le firewall, alors elle est bloqué...

Pour moi t interfaces ne se voit pas...mais pourquoi ??? a toi de voir...

Lire un minimum la documentation ou parcourir, juste un peu l'interface, vous renseignera.

Hmmm, lorsque vous dites "INCOMPATIBLES" c'est bien d'utilisation des deux en même temps qui est de la sorte n'est-ce pas ?

Et donc ces packages permettent d'accéder à un LDAP, hors j'aurais préférence pour une base MySQL… donc étant donné que dans tout les cas je devrais installer un Serveur SQL (mon formulaire en C# renseigne d'autre info' que je devrais stocker...), est-ce que je shéma suivant est envisageable ?

Réseau LAN      -----------  pfSense (LAN)/pfSense (WAN) -------------- Réseau WAN (Accès WEB)
192.168.1.0/24  ------------- 192.168.1.2    / 192.168.7.253 --------------- 192.168.7.0/24
                                                      |
                                                      |
                                                      |
                                            Serveur "Radius"
                                                      +
                                              Serveur SQL

De la sorte je n'utiliserais donc pas les packages étant donné qu'ils permettent l'accès à un LDAP et non à une base SQL.

Mon résonne ment tient-il la route ?

Je ne savais pas qu'on pouvait relier un modem directement à un switch.

C'est à peu près aussi sûr que de placer ses serveurs sur un trottoir !! Peut être même moins.

et si

Avec de telles suppositions, non vérifiées, on est en plein délire. Votre façon de faire est complètement contraire au minimum de d'un comportement professionnel. Il serait bien en l'état et sous réserve d'une information plus fiable que vous cessiez de "chatouiller" le SI de cette entreprise à laquelle vous faites prendre des risques énormes.

C'est ce que j'ai fait ne t'en fait pas mais je n'ai pas trouvé de solution à mon problème. Ce n'est pas très grave car j'utilise LightSquid mais j'aurais voulu comprendre l'erreur et la réparer.

As-tu mis deux cartes réseaux?

On le sait déjà :

pfsense detecte les deux interface wan et lan (le0 et le1).

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.