Probléme d'accès depuis l'extérieur vers l'intérieur (dmz)



  • Salut salut

    Suite au dysfonctionnement des disques de mon cluster PF (2.3.1) et des sauvegardes trop anciennes (pf v1), je me retrouve à remonter mon cluster et mes règles de routages.

    Et c est la le drame, j'ai du me rater soit sur le nat soit sur l'une des règles car je n'arrive plus à accéder a mon serveur web dans ma dmz depuis l'extérieur (internet)

    Topologie :

    • une Box bouygues

      • Redirection de port voulu extérieur > interieur sur l'ip carp

      • L'ip Carp ajouter dans la dmz de la box

    • un cluster de deux PFsense avec

    • 1 Wan 192.168.1.11/24 (ip pf-maitre) 192.168.1.12/24 (ip pf-esclave) 192.168.1.10/24 (ip-carp)

    • 1 Lan 192.168.2.11/24 (ip pf-maitre) 192.168.2.12/24 (ip pf-esclave) 192.168.2.10/24 (ip-carp)

    • 1 Dmz 192.168.3.11/24 (ip pf-maitre) 192.168.3.12/24 (ip pf-esclave) 192.168.3.10/24 (ip-carp)

    • un serveur web sous debian dans la dmz en 192.168.3.13

    • un pc sous 3g

    Les tests effectués :

    • Sans pf derrière la box avec d'une machine montée pour tester le htpp ayant l'ip du carp

      • depuis un pc local > ip local ==> ok

      • depuis un pc local > ip ext ==> ok

      • depuis un pc local > redirection dns ==> ok

      • depuis un pc en 3g > ip ext ==> ok

      • depuis un pc en 3g > redirection dns ==> ok

    • Avec Pf derrière la box avec la machine web pour tester le htpp

      • depuis un pc local > ip local ==> ok

      • depuis un pc local > ip ext ==> ko

      • depuis un pc local > redirection dns ==> ko

      • depuis un pc en 3g > ip ext ==> ko

      • depuis un pc en 3g > redirection dns ==> ko

    au cas ou le schéma (j'aime les schémas) du test

    Nat et rules :

    • NAT

      • WAN TCP adresse_ext_wan1 /web_80443 WAN address web_80443 dmz_01 web_80443 Redirection du hppt80443 vers dmz-01
    • Outbound en manuel

    • WAN  192.168.2.0/24 * * * 192.168.1.10 * NO Lan > Wan

    • WAN  192.168.3.0/24 * * * 192.168.1.10 * NO DMZ > WAN

    • WAN  192.168.4.0/24 * * * NO NAT * NO SYNCHRO > WAN (inutile)

    • Rules sur Wan

    • IPv4 TCP adresse_ext_wan1 web_80443 dmz_01 web_80443 * none   NAT redirection du hppt80443 vers dmz-01

    • IPv4 ICMP echoreq * * WAN address * * none

    • Rules sur Lan

    • IPv4 * LAN net * * * * none   Default allow LAN to any rule

    • Rules sur Dmz

    • IPv4 * DMZ net * ! LAN net * * none   No DMZ vers Lan

    • IPv4 TCP dmz_01 * * web_80443 * none   serveur web se met a jour par http

    • IPv4 ICMP echoreq dmz_01 * * * * none   serveur web repond au ping

    • Rules sur Synchro

    • IPv4 * * * * * * none     règle de synchro pf-maitre/pf-esclave

    DNS Forwarder

    • Enable dns Forwarder

    • Regstrer DHCP Leases in DNS Forwarder

    • interface all

    J'ai du rater quelques chose, j'ai déjà eu le soucis mais comme un âne j'ai pas pris de note ni fait de sauvegarde récemment.
    Cela me servira de leçon.
    Je suis sur que c est soit au niveau du nat ou de la règle sur le wan qu'il y a une erreur ou pire un oubli.

    Cordialement



  • Bonjour

    La règle de Nat ne semble pas correcte : (copier/coller de la doc en ligne)
    =>
    Source - this allows you to match a specific original source of the traffic, and is hidden behind an Advanced button as in most cases it should be "any", allowing all Internet hosts through. The source port range when using TCP and/or UDP, and will almost always be "any". The source port is not the same as the destination port, and is normally a random port between 1024-65535.

    Laisser pf écrire la règle de wan en automatique ^^

    Cordialement



  • Salut salut

    @baalserv

    Si je vous suis bien il faudrait que partie nat  donne quelque chose comme cela ?

    WAN TCP * * WAN address web_80443 dmz_01 web_80443 Redirection du hppt80443 vers dmz-01

    au lieu de

    WAN    TCP    adresse_ext_wan1 /web_80443    WAN address    web_80443    dmz_01    web_80443    Redirection du hppt80443 vers dmz-01



  • oui ça bien cela :)

    Edit : j'ai jamais essayer d'utiliser des alias dans les règles de Nat alors que je les utilisent beaucoup dans les règles de fw; je ne sais pas si cela peut jouer



  • Salut salut

    c est bien se que je me disait aussi , pour faire simple avec les aliases ca passe pas trop , je vais masser par les ip et port au cas où cela soit ca



  • Re salut salut

    Résultat rapide pas de changement que se soit avec ou sans les alisases

    j'ai refait le NAT avec

    • wan address

    • wan net

    • IPV wan

    même résultat.
    Je retourne le truc je n'arrive pas à prendre du recule sur ce point, je reste persuadé que c est au niveau wan soit sur le NAT soit sur les Rules, mais coté Rules sur le wan y a que celle créées en auto, à l install et par le NAT.



  • Tu devrais voir des choses passées dans ton log pfsense au niveau du firewall si çà bloque, sinon active un tcpdump.
    Ton serveur web sort bien sur internet lorsqu'il est derriere le pfsense ?
    Si tu essaie avec les ip du master et non celle du CARP ca donne quoi ?



  • Salut salut

    Depuis la DMZ je sors bien vers le web.
    Je suis en train de ma poser la question si j'ai bien remonté mon cluster, ces paramétrages en faites.
    Comme il me reste une machine et suffisamment de carte réseau.
    Je vais faire le teste avec un pf solo et recréer les routages vers le serveur en dmz.
    Je comparerais les différences les deux montage.
    Et cette fois ci je vais prendre des notes ;op.
    Pour les log je vais aussi regarder de par là effectivement je n'y avais pas pensé.

    Cordialement et bonne journée.



  • Salut salut

    Petites informations sur mon soucis

    Suite à une xième soubresauts du réseau électrique, quelques orages  sur la semaine ont eu raison de mon cluster.
    J'ai du remonter mes machines de A à Z :( dépenses non prévues).
    J'avais effectivement fait des erreurs de paramétrage sur le cluster même, mais mon problème est toujours là.
    J'ai fait le teste avec une machine en parallèle solo, je continue mes tests.

    j'ai du vraiment louper quelques choses , et surement une broutille que je n'aurais pas du rater.

    Cordialement.



  • Il y aurait vraiment un fort intérêt à regarder en détail ce qui se passe sur les interfaces impliquées. Donc captures de trames lors d'une tentative d'accès depuis wan. Le double nat n'arrange rien. Lorsque vous créez une règle de nat Pfsense propose de créer la règle de filtrage qui convient. Laissez le faire.



  • Salut salut

    @ccnet

    Lors de la création de la règle NAT, cela à créer aussi en auto sur la règle Wan, je ne m'amuse pas à y toucher ni à les monter indépendamment l'une de l'autre.

    @all

    ce que j'ai constaté durant mon remontage du cluster et sur la machine solo :

    • avec la 2.0.1 j'ai pas eu de soucis de paramétrage pour le cluster
    • avec la 2.3.1 je n'ai pas réussie l'installation de base, et pourtant l'iso vient du site officiel.
    • avec la 2.0.1 installer upgradé j'ai pas rencontré de soucis particulier, le dhcp qui de en temps désynchronise sur un switch qui demande un redémarrage du Pfsense maitre.

    Cordialement.



  • Re all

    J'avance à petits pas mais j'avance

    début de résolution je commence via le web a taper sur mon serveur dans ma dmz, mais pas depuis mon lan en passant par url ou l'ip extérieur.

    Mes params ont changé car je suis sur deux machines neuves

    • 1 wan ==> 192.168.1.0/24

    • 1 Lan ==> 192.168.4.0/24

    • 1 dmz ==> 192.168.2.0/24

    • 1 wifi ==> 192.168.3.0/24 (qui va être en captif plus tard)

    • 1 synchro ==> 192.168.5.0/24

    Outbount

    • WAN  192.168.4.0/24 * * * 192.168.1.10 * NO Auto created rule for LAN to WAN

    • WAN  192.168.2.0/24 * * * 192.168.1.10 * NO Auto created rule for DMZ to WAN

    • WAN  192.168.5.0/24 * * * 192.168.1.10 * NO Auto created rule for SYNCHRO to WAN

    • WAN  192.168.3.0/24 * * * 192.168.1.10 * NO Auto created rule for WIFI to WAN

    il me fallait passer de "wan address" à l'ip de mon "carp wan"

    Le NAT

    • WAN TCP/UDP * * 192.168.1.10 80 (HTTP) ip_de_mon_server 80 (HTTP) exterieur vers ip srv_dmz

    • IPv4 TCP/UDP * * ip_de_mon_server 80 (HTTP) * none   NAT exterieur vers ip_srv_dmz (monté par le nat)

    les Rules

    • coté Lan

    • IPv4 * LAN net * * * * none   Default allow LAN to any rule

    • coté Dmz

    • IPv4 * DMZ net * ! LAN net * * none      bloc Dmz vers lan rule

    • IPv4 * DMZ net * ! Wifi net * * none      bloc Dmz vers Wifi rule

    • IPv4 * * * ip_de_mon_server * * none      accès srv Dmz depuis all rule

    • coté Wifi

    • IPv4 * Wifi net * * * * none   Default allow Wifi to any rule

    Donc la faut que je trouve comment faire pour que depuis lan et wifi j'accède au server web via l'ip extérieur et via la redirection dns ovh
    Bon je sauvegarde j'arrête pour la soirée
    Mais j'avance.

    Merci all pour les infos et remarques.



  • @Tatave:

    Re all

    J'avance à petits pas mais j'avance

    début de résolution je commence via le web a taper sur mon serveur dans ma dmz, mais pas depuis mon lan en passant par url ou l'ip extérieur.

    ce point là est normal si tu n'as pas activé l'option NAT Reflection mode for port forwards dans Advanced :

    When enabled, this automatically creates additional NAT redirect rules for access to port forwards on your external IP addresses from within your internal networks.

    ps c'est la version 2.1.3 actuellement pas 2.3.1 ;-)



  • Salut salut

    @Guldil

    Oups la vilaine inversion de doigts pleins de fautes ;o

    Et pour le nat reflexion j'ai regardé dans avanced onglet firewall/nat :

    Si j'active "Enable NAT Reflection for 1:1 NATé et ou "Enable automatic outbound NAT for Reflection" j'ai un message suivant :

    php: rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:60: syntax error - The line in question reads [60]: rdr on alc0 proto tcp from any to 192.168.1.10 port $80 -> 192.168.2.15

    Pour l'erreur c'est bon je viens de trouver , c'était un aliase qui ne correspondait à rien.

    J'en perds mon latin.
    Cordialement



  • Plutôt qu'utiliser "NAT Reflection", il est bien plus simple (et direct) de faire du "split dns".
    En effet, quel est l'intérêt du mécanisme lourdingue qui consiste, depuis une machine interne, à atteindre une ip externe pour revenir vers une (autre) machine interne ?
    Il est plus simple d'utiliser un nom de domaine, qui, en interne, fournit l'adresse interne de la machin cible.



  • @jdh:

    Plutôt qu'utiliser "NAT Reflection", il est bien plus simple (et direct) de faire du "split dns".
    En effet, quel est l'intérêt du mécanisme lourdingue qui consiste, depuis une machine interne, à atteindre une ip externe pour revenir vers une (autre) machine interne ?
    Il est plus simple d'utiliser un nom de domaine, qui, en interne, fournit l'adresse interne de la machin cible.

    ca dépends surtout du nombre de serveur web qu'il a à gérer. Si c'est pour dupliquer un ou deux DNS ca va, si pour en faire et qu'il bouge beaucoup…

    Personnellement je le fais avec DNS Forwarder justement, çà permet à mes DNS interne d’être court-circuiter, mes DNS Active Directory pointant sur le pfsense en redirecteur, lui même répondant par l'ip interne du serveur web.



  • Salut salut

    Je n'ai pas répondu de suite pour prendre le temps de la réflexion au sujet des DNS.

    J'ai un DNS chez Ovh que je voudrais rediriger vers mon cluster Pfsense.

    J'avais dans l'idée de mettre en place :

    • en DMZ, le dns en principal sous Debian.
    • en LAN, le dns en secondaire sous Windows.

    Sauf que je n'en suis pas encore là. (le cluster debian est en cours de réalisation)

    Cordialement.


Log in to reply