:D    ;D  continuez avec vos proverbes, j'adore!!!
Plus sérieusement, je suis parvenu à faire fonctionner openssh snort openvpn ssl pure-ftpd apache2 sur les machines lan/dmz/wan
J'écrire un billet là dessus, histoire d'expliquer à d'autres comment y arriver. Je préciserai aussi ma version de pfsense, vmware (  ;) )
Sinon j'arrive toujours pas à connecter pfsense à internet…

La virtualisation c'est très pratique … pour tester !
En production, il NE FAUT PAS virtualiser un firewall ! NE PAS !

tout est dit, j'ai testé de virtualiser, j'ai arrêté  :)

Mon problème n'a pas encore été réglé, j'ai demandé à faire des modifications sur le firewall distant, malheureusement, ils ne peuvent laisser passer le traffic désiré (192.168.aaa.1/24, 192.168.bbb.1/24, 192.168.ccc.1/24 étant respectivement nos sous réseaux interne). La seule solution serait donc d'installer du NAT selon eux… Ou un système de proxy.

Comment puis-je savoir si ma version de pfsense gère le NAT-T (j'ai regardé sur le site et j'ai trouvé ce lien http://doc.pfsense.org/index.php/Does_pfSense_support_NAT-T%3F qui indique que certaines version ne le gère pas)? :)

Bonjour JDH,

Merci de cette réponse par laquelle tu réponds implicitement à ma première question.

Donc la méthode pour écrire une règle qui authorise l'accès internet n'a pas changé depuis la version précédente de pfsense, il faut créer un alias avec les différent VLANs bloquer l'accès intervlan, il n'y a pas un objet créé automatiquement qui simplifie les choses (soit un objet "internet" soit un objet "tous les vlans sauf celui en question").

Merci beaucoup

David

C'est mal parti la comparaison Ipfire / pfSense !

pfSense est un firewall.
Un firewall, ça travaille sur les flux réseaux autorisés ou non.
Et ça ne travaille pas forcément sur l'intérieur d'un flux !
L'intérieur d'un flux est le job d'un proxy (du flux concerné).
De plus ce proxy est ou non intégré au firewall !

"Bloquer sur des catégories" c'est le boulot d'un proxy http à partir de blacklists correspondantes à les URL classifiées en catégories.

Première contrainte : doit on intégrer le proxy au firewall ?
A partir d'une certaine taille, compte tenu de la différence de boulot, il est logique de séparer le proxy du firewall.
J'ai l'habitude d'écrire à partir de 10 utilisateurs.
Mais est-ce 10 "gros" utilisateurs ou 20 "petits" utilisateurs ?
Et puis le hardware prévu est-il adapté ? C'est assez sensible !

Deuxième contrainte : le proxy dispose-t-il de l'addons de gestion des blacklists ?

(Troisième contrainte : mise à jour des blacklists,  quid ?)

(Quatrième contrainte : quid du contrôle ? quid de la façon de bloquer ? …)

Bref, la question écrite en 1 phrase aurait du être décomposée en un minimum de 2 ou 3 éléments.
Quelque soit le point de vue, filtrer par catégorie est une problématique très banale et pas simple à mettre en oeuvre, sans compter les choix qu'il faudra prendre ...

J'aurais pu répondre OUI ou NON, mais j'espère avoir montré qu'il faudrait hausser le niveau de compréhension des problématiques.
Par ailleurs, on peut aussi lire les forums, les docs et/ou tester soi-même, non ?

J'aurais juré avoir répondu ifconfig à la question posée …

Il n'empêche, je n'aime pas du tout faire un on/off sur une interface, c'est qu'il y a quelque chose d'autre qui cloche AMHA.

Bonsoir JDH,

Merci de ta réponse.

@Alesk13Fr:

Il est essentiel que le mode de fonctionnement choisi soit le mode "point d'access" pour assurer qu'un micro connecté en wifi soit strictement dans le même réseau qu'un PC connecté au port ethernet.
Ce mode est un bridge entre le côté ethernet et le côté wifi.

Je suis bien "configuré" en "Access Point" !

Donc oui les DAP sont bien en "Access Point", et il n'y a bien évidement pas de WLAN sur le réseau !

Cordialement,
Alex.

Bonjour,

Merci pour vos réponses !

Je vais donc lire les liens que vous m'avez fait parvenir.

Bonne journée.

Cordialement,

Essayes l'extension "OpenVPN Client Export Utility" disponible dans les packages.

Dans server :

Server Mode : Remote Access SSL/TSL
Protocol : UDP
Device mode : tun
Interface : Wan (selon ta config)
Local port : 1194

–-
Crées des certificats

DH Parameters lenght : 2014
Encryption algo : AES-128-CBC

Tunnel network : 10.0.60.0/24 (ou autre)
Redirect Gateway : désactivé
Local Network : 10.0.0.0/24 (selon ta config)
Compression : activé

--
Dynamic IP : activé
Address Pool : activé
DNS domain : selon ta config (mondomain.local)
DNS server : activé + à fournir

Et c'est tout !!!

Google est ton ami :

http://skear.hubpages.com/hub/How-to-Configure-Deep-Packet-Inspection-Using-pfSense

http://www.osnet.eu/fr/content/introduction-au-traffic-shapping-avec-pfsense-20

http://doc.pfsense.org/index.php/VoIP_Configuration

La solution est d'utiliser une redirection 302 sur une adresse publique (Ex. : http://mgi-partenaires.ch/firewallblock/index.php?a=%a&n=%n&i=%i&s=%s&t=%t&u=%u).

En prod, il me parait aberrant d'utiliser une carte non reconnue par un firewall.
Donc la solution qui consiste à installer un système de virtualisation qui supporte la carte (fautive) et émule dessus une autre carte pour la VM firewall est une erreur AMPSHA !

C'est une erreur, parce que,

il y a baisse de performance forcément (qui peut être considérable), on oublie que les couches réseau basses de l'hyperviseur ne sont pas couvertes par la VM … firewall ! un jour ou l'autre, on va être tenté d'ajouter une VM.

Oui, j'ai bien conscience qu'openvpn est un service inutile dans mon cas, je suis d'accord
Qu'il s'agit d'un problème de paramétrage. Je vais donc continuer à rechercher la bonne syntaxe. Merci

Migration du premier serveur faites, tout se passe bien, les autres viendrons progressivement dans la semaine. Merci JDH :)

YOUUUHOUUUU !!! Pour ma part j'ai réussi :D

Erreur stupide, voir même de débutant, je n'avais pas renseigné la bonne passerelle par défaut dans la zone de paramétrage de l'interface WAN.
J'avais stupidement rentré l'adresse de mon serveur Radius :s

Donc merci à tous ceux qui m'ont aidé et on essayé de trouver une solution à mon problème.

Yannick.

@jdh:

SME n'est pas un linux comme les autres : c'est une distribution "tout-en-un".
Il est prévisible que la config de ses services soient ajustée "aux petits oignons".

Attention à bien modifier le template et non simplement le fichier smb.conf : gare au reboot !

(Il eut été mieux de l'exposer de suite : la piste aurait été plus vite vue.)

Concernant pfSense 1.2.3, il est intéressant de migrer à 2.0 et cela se passe bien … sauf OpenVPN !?
Enfin, je viens de faire une migration pour une 1.2.3 sans OpenVPN. Et j'ai ajouté OpenVPN juste après.
Cela a suffisamment changé pour que je considère qu'il faut refaire sa config OpenVPN.
Mais on y gagne sérieusement puisque la gestion des certificats est désormais intégré !

Pour la SME, il n'y a pas grand à faire, juste le plan d'adressage IP à définir mais ça c'est HS.

En ce qui concerne la migration, c'est là où je suis c…. c'était une instalation toute neuve, j'ai donc hésité entre la 1.2.3 que je connais et la 2 que je n'ai pas encore testé... j'ai choisi la 1.2.3, erreur...

Nusa

j'ai trouvé le coupable.
au début de la mise en prod. j'ai fait une capture de paquet (Diagnostics-Packet Capture).
Je l'avais stoppé mais le process tcpdump tournait toujours et augmentait toujours plus sa place
en mémoire (le fichier dump surement)

Pour info un simple top en console ne m'a pas mis sur la piste de manière évidente.

J'ai fait : top
puis la commande o
puis la commande res
–> ca fait un classement par process qui occupe le plus la mémoire. res pour resident memory size.

si ca peut servir à d'autres.
a+