Probléme d'accès depuis l'extérieur vers l'intérieur (dmz)
-
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
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.
-
-
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
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.
