Impossible d'envoyer des mails via Outlook - Erreur sur le SMTP 587
-
Oui je suis branchée sur le réseau Parcours, et je n'arrive pas à accéder à la page.
Je pense que je n'ai d'autre solution que de débrancher le PFSense1 et de connecter mon portable directement avec un câble ethernet sur le routeur PFSense2 pour pouvoir accéder à la page.Je ne comprends vraiment pas, j'ai mis mon adresse IP dans le serveur PFSense pour lui donner un accés complet sur le réseau. Mais rien n'y fait, j'ai mis la page dans les pages autorisées, rien n'y fait non plus. On dirait que toutes les modifications que j'apporte au serveur ne sont pas prises en compte ou alors je tape vraiment à côté !!
-
en partant du principe qu'il n'y a pas de proxy sur le réseau parcour (pas eut la réponse)
vous avez 4 url a essayer :
http://192.168.20.200
https://192.168.20.200
http://192.168.20.200:7777
https://192.168.20.200:7777 -
Dans "Proxy Server" c'est le proxy "LAN" qui est sélectionné.
"Transparent proxy" est cochée.Aucune de ces 4 adresses ne fonctionnent, je tombe soit sur la page de blocage soit sur une page internet "délai d'attente dépassée"
EDIT : si je sélectionne le proxy "PARCOUR" idem pour les adresses, aucune ne fonctionnent
-
La solution standard (pour retrouver le réglage qui manque) consiste à prendre le clavier/écran de la machine, accéder au shell et parcourir le fichier de conf (config.xml dans /conf).
Mais le pfSense2 n'a pas de clavier …Il est probable qu'une règle dans pfSense1 permette de déduire le port choisi ...
Avec 2 firewall, j'ai tendance à utiliser le même port, le même mot de passe ...
On ne vas pas passer 10 messages sur les techniques d'accès en http sur l'administration d'un pfSense ...
-
n'activez pas le proxy sur le réseau parcour si il n'était pas actif à l'origine ^^
l'Ip lan du pf2 n'a pas été vérifier (trouver sur votre doc et déduit d'une règle)
Quel sont les réglages dans : Interfaces | Wan (surtout la Gateway)Que donne un ping depuis Diagnostic | ping en sélectionnant comme interface (lan puis parcour) et comme ''host'' l''ip que vous trouverai dans les réglages de Wan comme Gateway ?
-
-
surement dans Diagnostic | interfaces ^^
donnez-nous svp les règles de l'interface parcour
que donne le ping ?
-
Bonjour,
Je me connecte au PFSense2 très prochainement, j'ai reussi à négocier de couper le réseau !Si j'ai bien compris, je dois m'assurer que le PFSense2 possède les mêmes règles que le firewall du PFSense1 ?
Et y rajouter la règle pour le port SMPT 587 ?ci joint la dernière configuration des règles du PFSense1
 -
Le rôle de pfsense2 est de faire le loadbalancing : comment le fait-il ? quelles règles de filtrage ?
Son rôle agit en COHERENCE avec pfSense1.
Donc, forcément, les règles doivent aller DE CONCERT.Puisque vous avez ajouté une règle pour le flux 587/tcp dans pfSense1, il faudra l'ajouter dans pfSense2.
Profitez de la coupure pour synchroniser encore plus pfSense1 et pfSense2 : même user, même mot de passe, même port d'administration et les règles dans pfSense1 pour accéder à l'administration de pfSense2. Et, bien sûr, mise à jour du schéma
-
Comme le précise JDH, les règles doivent être en accord sur le pf2 par rapport au pf1
Mais cela ne veux pas dire quelle doivent forcément être identique.
Il faut autoriser seulement le trafic utile; dans le pf 2 vous aurez une nouvelle notion a appréhender, celle des ''pool'' ou ''groupe'' de gateway qui sont a sélectionner dans les propriété avancer des règles de firewall sur l'interface lan du pf2. Les pool de gateway sont la pour orienter le trafic sur l'une ou l'autre des box et de gérer le load-ballancing pour les protocole qui le supporte.
Des ''alias'' ont peut être été utiliser dans la configuration du pf2, il faudra en tenir compte le cas échéant.
-
Merci beaucoup de votre aide,
J'ai pu me connecter au PFSense2 et accéder au Firewall, j'y ai rajouté une règle sur le port 587 (capture ci jointe)
Et tout marche parfaitement, outlook fonctionne très bien !Merci de m'avoir guidé, tout ceci m'a permis d’appréhender PFSense et je comprends maintenant un peu mieux son fonctionnement.
-
Au passage, vous constatez que le loadbalancing s'applique à 80/tcp=http et que les autres protocoles sont juste définis pour passez par l'une ou l'autre des sorties.
(A titre perso, je doublerai les règles avec une règle inactive vers l'autre sortie … pour être plus réactif en cas de panne !)Il reste à mettre à jour le schéma, documenter l'architecture, procédurer ...
-
votre problème est résolu :) MAIS, idéalement il faudrai :
1/ supprimer la règle que vous avez ajouter; puis ajouter le port 857 à l'alias nommer ''Mail'' que l'on visualise à la ligne en dessous (1 seule règle au lieu de 2^^)
2/ créer 2 pool de gateway type fail-over, dans la 1ère avec sfr1 en ''tiers1'' et sfr2 en ''tiers2'' (sfr1 secouru automatiquement par sfr2) et la 2ème avec sfr2 en ''tier1'' et sfr1 en ''tiers2'' (soit sfr2 secouru par sfr1)
3/ remplacer dans les règles existantent (sauf pour http) la gateway (sfr1 ou 2) par l'un des pool de fail-over fraîchement créerLa finalité étant que pour les protocoles pour lesquels on choisit une sortie d'être automatiquement secouru en cas de panne d'une box (inefficace lors d'une panne réseau du FAI car les 2 connexions sont chez le même FAI (sfr) )
Donc pour résumer :
le + : secours automatique et transparent en cas de panne d'une des Box
le - : coté utilisateur on ne perçoit aucune rupture de services, seulement plus de lenteur => si on ne vas pas vérifier l’état des box on peut chercher longtemps pourquoi ''sa rame d'un coup'' -> détection et identification plus compliquer d'une panne de box et donc de la cause éventuelle d'une ''lenteur'' inhabituelle !Cela relève donc d'un choix stratégique => révéler de façon franche (rupture de service partielle) la panne d'une des 2 box … ou pas ^^
L'autre technique est celle donner par JDH soit => doubler les règles en changeant la gateway utiliser et désactiver ces règles ''doublons'' de façon à changer rapidement mais manuellement le ''chemin'' à emprunter lors d'une panne de box@jdh:
Il reste à mettre à jour le schéma, documenter l'architecture, procédurer …
=> j'appuie et confirme les propos de JDH, je dirai même que c'est ''impératif'' :)
-
Je dois écrire que, compte tenu du point de vue de la "société" (= pas de prestations), vous avez bénéficié de conseils gratuits de "professionnels expérimentés".
Il faut donc "engranger" l'expertise obtenue à l'occasion de cette "panne" pour que cela serve.
D'où les impératifs de mise à jour de schéma, de description, de stockages des mots de passe, …
(Si vous saviez ce que les cimetières sont remplis d'indispensables !)Néanmoins de la prudence, vous n'avez pas forcément la compétence pour tout modifier à l'aulne des "best practices" que l'on vous indique.
Cependant, à votre portée, :- l'utilisation d'alias plutôt de n° de port (même si les n° de ports sont dans les alias) va diminuer le nombre de ligne,
- le doublage de ligne avec des lignes inactives "prêtes à réaction en cas de panne",
- l'ajout des règles nécessaires pour accéder à l'administration des 2 firewalls sans débrancher !
- pourquoi pas continuer dans le loadbalancing, si vous avez le temps pour des tests ...
-
Merci beaucoup,
oui bien entendu je me suis empressée de mettre à jour les schémas avec les chemin d'accès et les mots de passe, et de tout archiver dans l'intranet !
J’essaierai de me pencher sur l'optimisation de tout ça assez rapidement, comme par exemple le doublage des règles comme vous me proposez. :)