A minima, une machine doit être "clean".

Avez-vous déjà testé un memtest, l'install d'une bête Debian, la désactivation de paramètres inutiles dans le bios concernant l'énergie, …
Que se passe-t-il avec d'autres options que 1 ? (p.e. safebios ou équivalent ...)

Je suspecterai une erreur hardware ...

J'ai créé deux virtuals adresses IP de type other à savoir 196.28.255.220 et 196.28.255.222 mais le hic c'est que ces virtuals IP ne repondent pas au ping à partir de mon LAN ni de l'exterieur. Par contre sur ipcop elles repondent au ping en interne et à l'exterieur.
Mon objectif est de natter ces virtuals IP adresses avec les adresses IP de mes serveurs qui sont en DMZ à savoir la 10.10.3.4 et 10.10.3.5

Mon deuxième problème je ne peux pas accéder à mon serveur de mail et web en interne et à l'externe par leur nom fqdn

Ma config:
Firewall: Aliases

Firewall: NAT: Port Forward

firewallAliases.png
firewallAliases.png_thumb
FirewallPortForward.png
FirewallPortForward.png_thumb

Bonsoir,

JDH:
Oui, c'est bien la prochaine étape prévue sur mon matériel :)
Je voulais tester la MAJ car j'ai quelques pf en prod dont certains en PPPoE, même si je n'ai pas l'ombre d'une raison de les migrer en V2, qui est pour l'heure encore en RC.

depuis :
Cas 1 : Alix 2D13 (nanobsd) reçu en 1.2.3 de chez OSnet -> configuration initiale basique puis MAJ en V2 -> reboot -> pas connecté.
=> configuration des paramètres PPP dans Wan puis dans l'onglet PPP's dédié -> connecté OK
Il est réservé à quelques clients Ovpn, ce qui à motivé la MAJ en V2.
Il est stable et tout fonctionne parfaitement.

Cas 2 : Vieux soekris sur Hdd réinstallé directement en V2 -> paramétrage dans Wan de la connexion PPP -> connecté OK
Également dédié à Ovpn, il me sert actuellement à faire quelques tests chez un client.

Mais :) il me reste tout de même une question, en théorie, ou est-on sensé renseigner les paramètres PPP, dans l'onglet dédier ou directement dans les paramétrages de l'interface Eth concerné ?

Ma conclusion suite a ces tests : La MAJ fonctionne bien sur le matériel neuf que j'utilise le plus souvent
==> Vive pF & merci à tous

Bonjour,

Une fois ton client authentifié sur ton portail, par défaut il reste authentifié durant une heure. C'est pourquoi ton portail captif ne te renvoie pas à la page d'authentification à chaque fois. A toi de modifier les paramètres pour qu'ils correspondent à ce que tu recherches dans cet onglet Services -> Captive Portal

Idle time out : ton client se déconnecte après une période d'inactivité.
Hard time out : ton client se déconnecte après une période définie quelque soit son activité. ( par défaut les clients doivent s'authentifier toutes les heures )

Cordialement,

Tommy DEVOYE

captive.png
captive.png_thumb

Bonjour,
Je vais regarder ça

Merci

Bonjour,

Je relance le problème car il est toujours d'actualité. Personne n'a jamais rencontré ce type de dysfonctionnement?

J'ai fait un petit topic sur mon wiki, j'essayerai de le mettre plus propre dès que j'ai un peu de temps.

http://www.lenain.net/index.php/Pfsense

cdlt,

Bonsoir,
Merci pla pour ces infos ccnet.
Je viens d'essayer cela sur ma plateforme de test:

passerelles wifi 10.82.1.x/24 olsr –-----> sur opt1 et olsr activé sur opt1 règles de firewall entre opt1 et lan.

Cela à l'air de tenir la route.
Et en plus, je récupère correctement les logs de connexion des clients wifi sur opt1.

Merci encore.
Jean-Marc

Bonjour, je souhaite réaliser la même chose que toi. Merci de me donner comment cela est possible.
J'utilise la version 2.
J'ai tester en créant un groupe mais je ne trouve pas le privilège qui permet de créer des utilisateurs

Merci

Vincent

Je me permet d'insister mais c'est très important… :'( :'( :'(

La HCL de FreeBSD peut être ?

C'est limpide il faut des Vlans mais notre ami ne semble pas décidé.

Quid de la sécurité des vlans, de leur étanchéité ?
Sur du Cisco récent ET bien configuré c'est fiable. Chez d'autres constructeurs je n'en mettrai pas ma main au feu pour les raisons données par jdh entre autres. Bien configuré ce n'est pas si simple. Il faut vraiment faire attention à ce que l'on fait avec les protocoles Cisco. Et ne pas utiliser le Vlan 1 comme on le voit trop souvent.
Si on est en environnement sensible on n'utilisera pas de Vlan (du moins pas pour des questions de sécurité) mais des réseaux physiques distincts.

Merci,

C'est exactement ce que je pensais.
Après enfin avoir compris mon erreur.
Je vais donc me lancer dans l'installation d'un Free-Radius maintenant.

Seb86.
Tech. info. Admin/gestionnaire réseau et tout pleins de choses diverses et variées…

Depuis qu'on le repère … surtout avec une centaine d'utilisateurs.

L'intérêt de "DHCP server" reste limité à de petits sites sans réels serveurs (où, j'ai du mal à comprendre la nécessité d'un serveur proxy).

Dès que sur un site, il y a un serveur Windows gérant un domaine, il est quand même bien plus simple de gérer sur celui-ci DHCP et DNS puisqu'ils se mettent à jour automatiquement.
On a donc tous intérêt à ajouter les options nécessaires sur le DHCP du serveur Windows.

Bonjour,

j'ai trouvé (enfin, nous avons trouvé, avec un collègue), illumination suite à un mail :

J’ai regardé sur le net je n’ai rien trouvé à part ton post et au sujet du traffic shaping mais je doute que ça soit à cause de ça, on peut toujours voir ça si jamais le conflit ne viens pas du vpn.

Et effectivement, le problème venait du Traffic Shaper. A l'installation du boitier, ils n'avaient pas encore reçu leur lien ADSL, donc tout avait été configuré pour du 1Mo, dont le traffic shaper. Une modification du traffic shaper pour atteindre 19Mo et il n'y a plus de bridage.

Merci à tous

Note pour plus tard : Rajouter le traffic shaper dans les trucs à vérifier sur les pfsense

Kinder