Timeouts vers certains sites

baalserv

https://forum.pfsense.org/index.php?topic=79600.0

ccnet

Le formulaire s'impose en effet.

Aunet

D'accord, merci.

Contexte : c'est dans le cadre professionnel, mon niveau en réseau est assez faible je suis plus orienté système, le Pfsense en place a 9 mois de production.

Besoin : j'ai besoin de votre aide pour trouver pourquoi le reverse proxy est temporairement indisponible aléatoirement. Le problème ne vient pas du modem en bridge ou du FAI car j'ai essayé avec deux ISP différents et le problème persiste, il ne vient pas non plus du LAN, le problème est bien présent au niveau du Pfsense.

WAN (modem/routeur/box) : dans les bureaux de mon client, deux modems de FAI différents sont bridgés au Pfsense, ils agissent en failover.
Côté prod (serveurs dédiés en datacenter), les serveurs web sont en backend derrière un reverse proxy Nginx qui lui même se trouve derrière un firewall Pfsense. Le Pfsense a sa propre IP publique tout comme l'Nginx.

LAN : le LAN interne de la société ne comporte pas de VLAN et dispose d'un adressage par DHCP. 192.168.100.0/24

DMZ : toujours dans les bureaux, une DMZ staging est en place afin que les clients puissent consulter l'évolution du développement de leur site. 192.168.99.0/24

Autres interfaces : une interface "Public" est dédié au wifi des visiteurs 192.168.101.0/24

Règles NAT : il y a toute une série de règle NAT mais qui agissent sur des IP publique différentes de celle utilisée pour la navigation web.

Règles Firewall : il n'y a pas de règle particulière sur l'onglet LAN, LAN to WAN en any.

Packages ajoutés : aucun package n'a été aujouté.

Autres fonctions assignées au pfSense : il fait aussi office de passerelle VPN afin de relier les différentes antennes de la société.

Question : voir premier post.

Recherches : j'ai essayé avec différents modem et FAI mais le problème reste présent. Les autres antennes de la boite ne rencontrent pas ce problème, ils ont chacun leur Pfsense avec leur propre sortie vers Internet. Le problème ne vient pas du réseau LAN avec tout ce qu'il s'y trouve car j'ai essayé de joindre le reverse proxy en étant directement connecté en SSH sur le Pfsense de la boite et le problème est bien présent (cela vient donc du Pfsense). J'ai lancé une capture de packet depuis le Pfsense de la boite, vous trouverez le résultat dans mon premier post.

Logs et tests : voir premier post.

Merci d'avance pour votre aide.

Tatave

Salut salut

Premièrement obligé de vous faire un rappel a l'ordre qui ne dénote pas le professionnalisme (ça c'est dit)
Deuxièmement obligé de vous tirer les verres du nez ? gros manque d'informations manifeste.
Troisièmement manque flagrant de documentation de recherche et qui plus est de compréhension du l'environnement PF.

Tout ce temps pour ne pas cadrer totalement à une charte et un constat qu'une foret de baobab palmaire est indéniable.

A revoir totalement avec :

un formulaire contenant
une vrai recherche préalable
plus d'informations communiqué
de vrai schémas (j'aime les beaux schémas et je ne suis pas le seul)

Non cordialement.

Florian22

et est ce quil serait possible de voir l'erreur renvoyée par le proxy ? (capture ecran)

baalserv

Avez-vous essayer de prioriser les flux à l'aide du traffic shaper ?

Aunet

@Florian22:

et est ce quil serait possible de voir l'erreur renvoyée par le proxy ? (capture ecran)

Bonjour,

Si vous parlez du reverse proxy, il n'y a pas d'erreur, la requête n'arrive pas jusqu'à lui.
Le browser rentourne un timeout au bout d'une dizaine de secondes.
Ceci est complètement aléatoire, il y a des moments où les sites sont pleinement accessibles depuis le bureau et d'autres où ce n'est pas le cas.

@baalserv:

Avez-vous essayer de prioriser les flux à l'aide du traffic shaper ?

Je vais me renseigner là dessus, merci.

Merci pour vos réponses.

Florian22

avez vous un serveur a placer a coté de votre / vos serveurs distants de travail ?

je serai a votre place je m en servirai de témoin, histoire déja d'écarter que ca ne vient pas de votre outil de travail (vous évoquez une relation entre le remplissage du bureau et les timeouts) il serait bon d'envisager la route entière :

on va dire que A heberge le reverse et l'aapplicatif, et B est distant de A par internet.

lorsque B éprouve des timeouts envers A
vérifier que:

1/ B n"éprouve des timeouts qu''ENVERS A
2/ A est il joignable globalement a ce moment la ?
3/ B peut il joindre un serveur témoin sur A (autre que l'applicatif)

et enfin : sur quelle technologie d'accès A est il relié au net ?
les graphiques d'utilisation de WAN A font il état d'une utilisation élevée ?

toutes ces recherches vous permettront d'isoler l'origine de l'incident,
pour le moment, (et même si vous ne résolvez pas encore l'incident,)
vous ne savez pas si ca vient de A ou de B ou de l'applicatif, ou de rien du tout
il faut donc que vous reussissiez a isoler l'origine.

(le fond de ma pensée : si A est relié au net (donc a B) avec un ADSL qui synchronise a 800Kbits d'Upload (cas de la plus part en adsl2+)
et que de l'autre coté sur B vous avez 20 personnes qui font des choses vers A, ca va pas trop le faire)

aussi, nous vous remercions de donner le maximum de détails utiles, et de schematiser votre infra
cdlt

Aunet

Bonjour et merci pour votre aide,

Voici le résultat des tests demandés :

B n'éprouve bien des timeouts qu'envers A, le reste du web est accessible.
A est joignable depuis n'importe quel endroit lorsque nous n'arrivons plus à y accéder (pas de problème en 3G/4G et depuis d'autres bureaux à l'étranger).
B peut joindre plusieurs serveurs en SSH sur A lors du problème, et même le reverse proxy (SSH) ! Ca ne semble donc toucher que le port 80 et 443.
A est relié à Internet par OVH, le câble réseau d'OVH est relié à notre Pfsense de prod et derrière celui-ci Nginx (reverse proxy), Apaches, …
Les graphiques WAN restent stables, il n'y a pas de pointe de traffic.

L'hors du problème, les sites de développement hébergés en DMZ chez B restent accessibles depuis l'hébergement distant A. Le problème n'est donc que dans un sens.

La connexion Internet de B (bureaux) synchronise à 48,50 Mbps en download et 8,19 Mbps en upload.

Schéma :

LAN employés --- Pfsense --- connexion Internet 1 --- Internet --- OVH --- Pfsense de prod --- Nginx --- Apaches, IIS, ...
\ ---/
-- connexion Internet 2 /

Je ne vois d'autres infos à vous communiquer,
Encore merci

Florian22

@Aunet:

Bonjour et merci pour votre aide,

Voici le résultat des tests demandés :

B n'éprouve bien des timeouts qu'envers A, le reste du web est accessible.

A est joignable depuis n'importe quel endroit lorsque nous n'arrivons plus à y accéder (pas de problème en 3G/4G et depuis d'autres bureaux à l'étranger).

B peut joindre plusieurs serveurs en SSH sur A lors du problème, et même le reverse proxy (SSH) ! Ca ne semble donc toucher que le port 80 et 443.

A est relié à Internet par OVH, le câble réseau d'OVH est relié à notre Pfsense de prod et derrière celui-ci Nginx (reverse proxy), Apaches, …

Les graphiques WAN restent stables, il n'y a pas de pointe de traffic.

L'hors du problème, les sites de développement hébergés en DMZ chez B restent accessibles depuis l'hébergement distant A. Le problème n'est donc que dans un sens.

La connexion Internet de B (bureaux) synchronise à 48,50 Mbps en download et 8,19 Mbps en upload.

Schéma :

LAN employés --- Pfsense --- connexion Internet 1 --- Internet --- OVH --- Pfsense de prod --- Nginx --- Apaches, IIS, ...
\ ---/
-- connexion Internet 2 /

Je ne vois d'autres infos à vous communiquer,
Encore merci

corrigez moi si je me trompe

COTE B /////////////////////////////////////////////////////////////////////////// COTE A

LAN employés –- Pfsense --- connexion Internet 1 --- Internet --- OVH --- Pfsense de prod --- Nginx --- Apaches, IIS, ...
\ ---/
-- connexion Internet 2 /

Faites les tests suivants:

Ajoutez un serveur témoin du coté de A écoutant sur le port 80
1/ vous le mettez dans le pool nginx
2/ vous le nattez par ailleurs sur pfsense A par un autre port libre hors du pool exemple 8080 sur 80

depuis B

lorsque le probleme se produit:
1/ vous verifiez l'état en connexion 80 a travers le pool nginx sur le serveur témoin
2/ vous verifiez l'état en connexion 8080 natée sur le temoin 80 (hors du pool)

il sera interessant d'avoir ce résultat.

Coté B:
C'est quoi cette connexion internet 2 ?
les services de A demeurent ils joignables a travers cette deuxieme interface WAN coté B ?
Si non: Y aurait il une possibilité que pfsense B distribue d'une manière non souhaitée les requêtes sur ses ports WAN ? A verifier

lorsque le probleme se produit, faites l'essai avec cette connexion activée
puis faites un contre test après avoir éteint cette deuxieme interface et rebooté pfsense coté B.

autre test a effectuer: passez le gui de pfsense coté A sur 80 puis sur 443, et essayez aussi pendant les timeouts de contacter ca depuis B.

--
de prim'abord je dirais que c'est le reverse.
ces tests et contre tests vous permettront de mettre en lumiere cela

CDLT

ps: je me permet d'insister sur cette composante fondamentale du "serveur témoin" (une débian de base avec apache),
qui m'apparait évident afin de tester sur une bonne base.

en effet, un serveur derriere le pool pourrait tres bien aussi etre fautif, aussi nous ne pouvons faire confiance qu'en ce serveur frais, propre témoin

(a mon avis)

faites en sorte qu'il soit joignable sur les mêmes ports que vos serveurs applicatifs de production
faites en sorte qu'il soit joignable a travers le pool du reverse
faites en sorte qu'il soit joignable par NATage

testez les connectivités depuis B :

derriere en temps que LAN
derriere pfsense en temps que switch LAN
derriere le CPE opérateur (box) en temps que pfsense (si double nat)
ou testez avec un pc, directement au cul du CPE en bridge avec ip publique.

tous ces petits tests, vous feront mener l'enquete