Routage de base pfsense ?



  • Bonjour à tous, je débute dans l'utilisation de Pfsense,

    j'ai un LAN (10.0.0.x) et un WAN (192.168.0.x)

    General Setup:
    DNS : 8.8.8.8

    LAN
    DHCP = 10.0.0.10/24-10.0.0.20/24
    gateway = 10.0.0.254/24

    WAN
    dhcp = freebox 192.168.0.150-192.168.0.200
    gateway = 192.168.0.1

    Lorsque je me connect depuis un client en LAN (10.0.0.X), je peux résoudre les noms de domaine et naviguer sur le WEB, depuis le wan, je peux PING mes host sur LAN

    J'ai beau chercher la doc sur le net, je ne comprend pas pourquoi pfsense laisse tout passer du WAN vers LAN et inversement

    je cite wikipedia :

    https://fr.wikipedia.org/wiki/Pfsense

    pfSense est un routeur/pare-feu open source basé sur le système d'exploitation FreeBSD. À l'origine un fork de m0n0wall, il utilise le pare-feu à états Packet Filter, des fonctions de routage et de NAT lui permettant de connecter plusieurs réseaux informatiques. Il comporte l'équivalent libre des outils et services utilisés habituellement sur des routeurs professionnels propriétaires. pfSense convient pour la sécurisation d'un réseau domestique ou de petite entreprise.

    Ai-je manqué quelque chose ? (un par-feu qui laisse tout passer par défault  ?  ??? )

    Merci pour votre retour

    cdlt

    EDIT :

    Redirection NAT Par défaut, le NAT redirige tout le trafic sortant vers l'adresse IP WAN. Dans le cas de connexions WAN multiples, le NAT redirige le trafic sortant vers l'adresse IP de l'interface WAN utilisée. NAT réflexion : dans certaines configurations, NAT réflexion est possible si les services sont accessibles par IP publique à partir de réseaux internes.

    Ceci explique cela, par default l'ensemble du WAN est route vers le LAN, pourquoi l'inverse du coup  ? (d'un point de vue sécurité ?)

    Est il possible de suprimer les routes NAT,  WAN ->  LAN par default  ?



  • J'ai beau chercher

    Douteux !

    L'installation de base d'un pfSense inclut

    • une règle par défaut qui autorise tout de LAN vers WAN,
    • le NAT (outbound) automatique vers les interfaces de type WAN.


  • @jdh:

    J'ai beau chercher

    Douteux !

    L'installation de base d'un pfSense inclut

    • une règle par défaut qui autorise tout de LAN vers WAN,
    • le NAT (outbound) automatique vers les interfaces de type WAN.

    Le principe d'une phrase complète sert à faire passer une idée ou poser une question, si tu prends 3 mots sur la vingtaine que compte la phrase pour le plaisir de contre-dire c'est moche, relis bien ma question du DEBUT jusqu'a la FIN tu verra que le "douteux" est hors sujet.

    Merci pour ton explication sur le NAT j'avais posté en edit la réponse suite à ma lecture, cependant je n'ai pas la réponse à la question posté ci-dessus.  ;)

    cdlt



  • L'installation 'de base' fonctionne telle que je le décris (et comme c'est très logique).
    Donc, si votre installation ne fonctionne pas comme prévu, c'est que … vous avez fait quelque chose de particulier ...

    Plutôt que refuser, surtout en tant que débutant, vous devriez

    • fournir des infos (car il y en a peu et que vous ne présentez pas en respectant le formulaire A LIRE EN PREMIER),
    • réfléchir aux réglages que vous avez choisi de faire ...


  • J'ai beau chercher la doc sur le net, je ne comprend pas pourquoi pfsense laisse tout passer du WAN vers LAN et inversement

    Cela ne correspond pas au fonctionnement de Pfsense à l'issue d'une installation. JDH a indiqué comment fonctionne pfsense à l'issue de l'installation. En particulier aucun trafic entrant sur Wan n'est permis. Pas plus icmp qu'autre chose. Il apparait que e détail de votre configuration est nécessaire pour comprendre votre situation.
    Quelques remarques :

    gateway = 10.0.0.254/24

    Pourquoi utiliser une classe A pour faire un tel subnetting ,

    NAT réflexion : dans certaines configurations, NAT réflexion est possible si les services sont accessibles par IP publique à partir de réseaux internes.

    NAT relexion est à proscrire. Il y d'autres manières de gérer ce besoin, avec une configuration DNS appropriée.

    Est il possible de suprimer les routes NAT,  WAN ->  LAN par default  ?

    Il n'y a aucune raison de faire cela. Avez vous pensé au routage du trafic retour lorsque vous accédez à internet ? Ce n'est pas l'absence de route qui va garantir votre sécurité. Une route Nat je ne sais pas ce que c'est. En pratique :

    • ne touchez pas au routage de pfsense.
    • mettez en place des règles (donc des translations) après avoir compris le fonctionnement de Pfsense et la nature de vos besoins. Ceci en particulier sur l'interface Wan.


  • +1 ccnet : ce que tu relèves me 'choquait' de la même façon.

    Vous êtes débutant, et vous n'êtes pas rendu loin dans votre config : réinstallez votre pfSense (install fraiche) et regardez 'de base' comment il fonctionne …



  • Salut salut

    n'étant pas pour autant un expert dans du pf.

    Je pauserais la question comment avez vous câblé votre pf ?
    L'administration ne peut se faire que par le lan et non le wan.
    Vos explications quant à la présentation de votre problématique sous entend que vous avez virer des paramètres avant même de comprendre les bases d'un tel produit.
    Et que par confort vous désirez l'administrer via un autre site en l'attaquant puis son interface wan et non en passant par un vpn en arrière de votre pf ou toutes autres solutions qui pourraient et seraient plus sécure que ce que vous avez fait.

    Je ne serais que vous demande de refaire vite installation de votre pf et de brancher coté la une machine pour l'administration, et pas sur le wan et de ne surtout pas toucher au paramètres de la zone wan.

    Le schéma qui suit est le sens premier d'un pare-feu :

    Internet  <=== zone wan <=== wan pf / lan pf <==== zone lan

    Vous avez pléthore de site qui traite de pf de manière plus ou moins explicite mais ils sont tous sur ce schéma général, et même pour du multisite.



  • merci pour vos retours, je repars d'une installation fraiche (rien n'est en production pour l'instant je prend la main dessus actuellement en vm)

    Ma config est la suivante sous vmwares:

    WAN -> EM1 -> DHCP4 : 192.168.126.129/24 (NAT  sur vmwares)
    LAN -> EM0 -> Static v4 : 192.68.1.1/24 (reseau interne vmwares)

    DNS Rsolver : On
    Network interfaces : ALL
    Outgoing Network INT : ALL
    System Domain local Zone type : Transparent
    DNSSEC :Enable DNSSED Support

    effectivement le LAN -> WAN est fonctionnel

    EDIT:

    j'y ai ajouté SQUID, est il souaitable de rediriger le trafic HTTP (80) vers mon proxy via une règle pfsense  ? Ou vaut il mieux faire remonter l'adresse proxy via GPO en paramètre système  ?



  • @leknol:

    j'y ai ajouté SQUID, est il souaitable de rediriger le trafic HTTP (80) vers mon proxy via une règle pfsense  ? Ou vaut il mieux faire remonter l'adresse proxy via GPO en paramètre système  ?

    ??? je ne pense pas que ta "redirection" depuis pfSense fonctionne  :P
    Où se trouve ton proxy sur le réseau ?
    C'est pour faire du proxy transparent ?

    Par GPO, c'est faisable (pas en mode transparent hein) pour les machines Windows (c'est ça qui est bien avec Microsoft, ça ne marche qu'avec Microsoft  :-X)
    Pour le reste, la méthode standard, c'est WPAD  8)



  • Tout cela est de l'amateurisme !
    On lit maintenant que vous virtualiser (avec VMware Workstation probablement, et donc sur pc windows) et que, de plus vous ajoutez Squid.

    Très visiblement, vous n'avez pas les compétences nécessaires à ce 'job' mais surtout pas le recul.
    Il est essentiel d'avoir une ligne de conduite, d'avoir des étapes, de lire/se former à la théorie, et de les franchir une par une, mais surtout pas de bricoler et de tout faire en même temps.

    Moi c'est stop.
    Comme je dis, souvent : la première impression est toujours la bonne, surtout quand elle est mauvaise …



  • Terminé pour moi aussi. Rien de tout cela n'est bien sérieux. A la rigueur pour passer le temps. Mais rien de cela n'a à voir avec la sécurité du SI.



  • Ou est le soucis de Virtualiser pour un environnement de testes  ?  ???
    Ou est le soucis lorsque l'on souhaite comprendre le cheminement sur quelque chose de nouveau  ?

    Ca sent la condescendance à plein nez, oubliez pas que vous avez surement eux des questions stupides dans vos débuts  ;)

    Reste donc sur "ta première impression", au travers de 50 caractères en 2 postes de forum, ca doit surement être la bonne  ;) (je suis totalement ironique, ta réponse est surement aussi stupide que ma question nous voila au même niveau)

    Sans rancune bon week ends messieurs  ;)



  • @chris4916:

    @leknol:

    j'y ai ajouté SQUID, est il souaitable de rediriger le trafic HTTP (80) vers mon proxy via une règle pfsense  ? Ou vaut il mieux faire remonter l'adresse proxy via GPO en paramètre système  ?

    ??? je ne pense pas que ta "redirection" depuis pfSense fonctionne  :P
    Où se trouve ton proxy sur le réseau ?
    C'est pour faire du proxy transparent ?

    Par GPO, c'est faisable (pas en mode transparent hein) pour les machines Windows (c'est ça qui est bien avec Microsoft, ça ne marche qu'avec Microsoft  :-X)
    Pour le reste, la méthode standard, c'est WPAD  8)

    Effectivement ta question est intéressante, je regardai les spécificités d'un proxy transparent, dans quelle cas va on privilégier un proxy transparent  ?
    Je n'avais pas songé à cette problématique, proxy transparent ou pas  :-X

    Proxy Transparent

    L'objectif est de pouvoir intercepter le traffic à l'insu des utilisateurs. Cela se fait souvent en entreprise, notamment sur les flux https en mettant un certificat dont le proxy possède la clef privée sur le navigateur des machines banalisées.
    Ainsi le proxy peut décapsuler le traffic https à la volée.
    Ca permet aussi de ne pas avoir à faire de configuration proxy ou de proxy.pac sur chacune des machines de l'entreprise.



  • @leknol:

    Proxy Transparent

    L'objectif est de pouvoir intercepter le traffic à l'insu des utilisateurs. Cela se fait souvent en entreprise, notamment sur les flux https en mettant un certificat dont le proxy possède la clef privée sur le navigateur des machines banalisées.
    Ainsi le proxy peut décapsuler le traffic https à la volée.
    Ca permet aussi de ne pas avoir à faire de configuration proxy ou de proxy.pac sur chacune des machines de l'entreprise.

    A mon avis c'est une mauvaise idée.
    Le proxy transparent présente plein d'effets de bord qui justifient de ne pas déployer ça.

    Je ne sais pas d'où tu soirs ce texte mais celui qui a écrit ça a une bien mauvaise compréhension de comment ça fonctionne. L'objectif de WPAD étant justement de ne pas avoir à configurer proxy.pac sur chaque machine.

    Ceci étant, il y a des situations ou SSL-Bump présente un intérêt. Mais le proxy transparent, non  :P



  • J'ai vu ta source.  ;D

    Celui qui fait ce commentaire explique comment fonctionne le proxy transparent mais n'en décrit pas vraiment ni les avantages ni les inconvénients.

    Contrairement à ce qu'il explique, le proxy transparent est beaucoup plus, à ma connaissance, employé en dehors des entreprises car en entreprise, il est facile et souhaitable d'utiliser un proxy explicite en communiquant sur le fait qu'il y en a un car cela permet, ce que ne permettra jamais un proxy transparent, de faire de l’authentification et donc du profiling et du tracking d’utilisateurs.

    Après, quand on regarde de très près, il y a quelques d'entreprises qui déploient les 2 solutions en cascade :-X

    La seule vraie difficulté de WPAD, c'est que le mécanisme pour pousser le proxy ne fonctionne pas bien avec quelques browser ésotériques sur Androïd. Mais pour le reste, c'est plutôt efficace, surtout en entreprise.



  • Merci pour ton retour

    L'objectif est bien sur de pouvoir faire du profilage sur les users(savoir l'utilisation de la bande passante par user) et également par la suite de filtrer le contenu accessible (blacklist de domaine entre autre) + mise en cache, c'est pour cela que je pensais y ajouter Squid



  • L'objectif est de pouvoir intercepter le traffic à l'insu des utilisateurs. Cela se fait souvent en entreprise, notamment sur les flux https en mettant un certificat dont le proxy possède la clef privée sur le navigateur des machines banalisées.
    Ainsi le proxy peut décapsuler le traffic https à la volée.
    Ca permet aussi de ne pas avoir à faire de configuration proxy ou de proxy.pac sur chacune des machines de l'entreprise.

    J'ignore qui est l'auteur de ce texte. Ce qui est certain est qu'il est un beau condensé d’âneries.
    1. Le proxy transparent n'est pas utilisé en entreprise pour l'accès internet des utilisateurs pour des raisons juridiques. Le stockage de logs et la capacité à établir qui va où (pour dire les choses simplement) est une obligation. L'imputabilité est incontournable.
    2. "décapsuler le traffic https". Si vous avez un décapsuleur, gardez le pour un autre emploi. Le déchiffrement du trafic https par une méthode type Man In the Minddle est fortement encadré par des dispositions législatives et n'est certainement pas praticable à l'insue des utilisateurs. Cette méthode consiste à usurper l’identité du serveur de  destination. Elle nécessite aussi le déploiement correcte d'une autorité de certification interne.
    De ce fait aussi elle est peu employée. Sur les réseaux classifiés c'est beaucoup plus simple : pas d'accès à internet.

    Bref nous sommes loin des propos erronés tenus dans cette citation.



  • Merci pour ton retour et ton explication, elle sort en premier sur google sur "proxy transparent", pas top pour la recherche d'infos  ???



  • Voilà une différence majeure :
    ce n'est pas parce que cela apparait en premier que c'est ce qu'il faut considérer comme juste !

    Informatique finit en tique, et n'est pas une science absolue comme les mathématiques (finit par erreur en tique).
    Mais cela ne dispense pas d'avoir un esprit méthodique et scientifique …

    Donc on fait une expérimentation d'une chose à la fois ...



  • @jdh:

    Voilà une différence majeure :
    ce n'est pas parce que cela apparait en premier que c'est ce qu'il faut considérer comme juste !

    Informatique finit en tique, et n'est pas une science absolue comme les mathématiques (finit par erreur en tique).
    Mais cela ne dispense pas d'avoir un esprit méthodique et scientifique …

    Donc on fait une expérimentation d'une chose à la fois ...

    D'ou l'avantage de pouvoir croiser les informations récoltées via un forum avec des gens compétents dans le domaine et surtout pédagogue dans leur réponse, ne pas considérer son interlocuteur comme un imbécile peut aussi permettre un meilleur échange  ;)



  • Petit retour, j'ai consulté pas mal de docs néanmoins je reste bloqué sur un point avec ma carte wifi,

    Lorsque je souhaite la passer en AP sur pfsense, j'ai un retour :

    urtw0 : expect 0xe6!! (0x66)
    urtw0 : HOSTAP mode not supported

    urtw0: <vendor 0="" 2="" 0x0bda="" product="" 0x8187,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
    urtw0: unknown RTL8187L type: 0x8000000
    urtw0: rtl8187l rf rtl8225u hwrev none

    [1:33] 
    urtw0: HOSTAP mode not supported</vendor>

    Ma clef wifi est plug en USB dans une workstation vmwares, 802.11b/g Model : awus036h

    Si vous avez une suggestionn je suis preneur

    Bon week end

    cdlt

    EDIT:
    Citation d'un forum Freebsd en 2013

    Note that the urtw(4)() driver it based on Realtek's Linux driver and at that moment it didn't support adhoc and hostap modes[1]. It's possible that some developer is interested in patch this requested feature in -HEAD directly.


Log in to reply