Bon voilà les résultats de mes captures de trames :
Lorsque je pingue depuis un PC vers Pfsense :

dans wireshark je vois bien les ARP partir mais pas de réponse de pfsense en lancant une capture de trame sur pfsense, aucun paquet capturé

Lorsque je pingue de la pfsense vers le PC :

dans wireshark je capture bien les requêtes ARP de pfsense ainsi que les réponses de mon PC, mais elles ne semblent pas être prise en compte par pfsense puisqu'il ré émet des requêtes ARP.

Pour vérifier si le problème venait d'ARP, j'ai ajouté une entrée statique à ma table ARP de mon PC, et lancé une requête ping.

Je vois bien les requêtes ICMP partir, mais pas de réponse.

J'en déduis donc qu'aucun paquet "in" n'est pris en compte, ce qui est confirmé par le screenshot de la page "Status:Interface" ci joint.

Je ne sais plus quoi penser …

Capture.JPG
Capture.JPG_thumb

Bonjour,

Si vous n'êtes pas à l'aise avec les terminaux, je vous conseille d'utiliser l'outil "PhysGUI.exe", une fois que vous l'avez télécharger,
http://m0n0.ch/wall/downloads/physdiskwrite-0.5.2-PhysGUI-bundle.zip, on dézippe, puis lancer l'exécutable, ensuite faites un clic-droit sur votre CF, puis "image laden" et ensuite "Öffnen" vous chargez alors votre image sur votre CF… Si vous avez une carte de plus de 2G cochez la case, sinon faites Ok, Ok, et laisser l'appli chargée l'image. Une fois que vous avez ce message “PhysDiskWrrite beendet" vore carte est prête.

PS : N'hésitez pas à me faire part de vos remontées.

pkg-add blabla

^_^

Yes ! c'est ok.
J'ai décoché "Disable the userland FTP-Proxy application" du WAN2

merci pour la rapidité, qualité,clarté et efficacité de ta réponse.

Tu pousses : tu dis 3000$, je propose 10x moins et c'est encore trop !  :D

Chez Bechtle, on trouve la carte Intel 2 ports entre 120 et 150€, et la carte Intel 4 ports entre 320 et 384€ (prix public).
Ce sont des cartes dites "serveurs", elles permettent de créer un firewall à 5 ou 6 ports réseau physiquement distincts.

C'est à répartir sur un investissement 5 ans …

Je viens de configurer le routeur pour OpenVpn. Je vais faire le test ce soir.

Vous pourriez commencer par vous assurer qu'il n'y a aucun filtrage actif, sur aucune des interfaces si ce n'est pas une configuration en production.
Ensuite il n'est pas étonnant qu'une machine ne puisse pinguer l'autre. A l'évidence le routage par défaut ne peut convenir.
Sur les interfaces Wan qu'en est il des réseaux RFC 1918 ?
Il y a beacoup de questions en suspend à traiter avant de pouvoir se lancer dans le test d'un tunnel IPSEC entre les deux machines. Sur le principe le test me semble possible.

Bon apparemment, en sélectionnant un des pool du load balancer comme passerelle sa fonctionne. Quelqu'un pourrait me confirmer la bonne configuration?

Bonjour,

J'ai joué la simplicité :

Réservation dans le DHCP des adresses IP par rapport aux adresses MAC des téléphones Définition dans PF d'une règle pour que cette plage IP passe par l'interface WAN dédié.

Je n'ai plus qu'à trouvé une carte réseau avec double WAN et ça roulera.

Nusa

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,