[Résolu] Netasq Ipesec impossible de joindre des page web

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [Résolu] Netasq Ipesec impossible de joindre des page web

PsYKrO_Fred

Bonjour,

J'ai 2 sites reliés par 2 NETASQ U70 et U30 en Ipsec.
La version du firmware : 8.1.4 de chaque coté.

Je ping bien les 2sites mais j'ai un petit problème pour les requêtes HTTP.
Je suis obligé par exemple pour atteindre la page intranet de :

- mettre une regle de nat qui dit :
Orginal : Network_in
Destination : Serveur IIS
Port de Destination : http
Translaté : Serveur ISS
Port Translaté : http

ou

- mettre un autre port que le port 80. Dans ce cas je ne suis pas obligé de faire du nat.

J'ai l'impression que le Netasq a du mal entre les requêtes http pour aller sur Internet et les requêtes HTTP pour le réseau VPN.

Message édité par PsYKrO_Fred le 09-04-2013 à 17:19:59

Publicité

Gimea

So, get rid of noise.

Tu utilises le filtrage URL de l'UTM ?

PsYKrO_Fred

Oui

Gimea

So, get rid of noise.

Ta règle de NAT permet le bypass du filtrage URL.
Il doit y a avoir une règle implicite qui redirige toutes les requêtes vers le port 80 vers le proxy de l'UTM pour qu'il fasse le filtrage URL.
Ton "problème" vient de la.

PsYKrO_Fred

Je suis en PROXY Transparent.. ca y joue?

Gimea

So, get rid of noise.

Oui c'est ce que j'ai écris au dessus.
Quand tu fais une requête http (80) en proxy transparent, en fait le Netasq la redirige automatiquement (via une translation) sur son proxy. C'est ce proxy qui fait le filtrage URL.
C'est probable ensuite que le proxy ne sache pas envoyer la requête dans ton tunnel.
Ca doit être un truc du genre.
J'utilise pas les fonctionnalités intégrées de filtrage URL (pas assez évoluées à mon gout), donc rapidement je peux pas plus t'aider.

Message édité par Gimea le 04-04-2013 à 17:27:59

PsYKrO_Fred

Est ce que l'option "NAT avant VPN" doit être coché?

PsYKrO_Fred

J'ai trouvé une option. Je peux ajouter une ligne en plus de
HTTP transparent
Port 80
Interface In

Je peux ajouter une ligne
HTTP transparent
Port 80
Interface Ipsec

Tu crois que ca peut marcher ?

Gimea

So, get rid of noise.

Si le site ou y a le U30 doit juste accéder à 1 serveur web sur l'autre site, tu peux laisser ton bypass du proxy avec ta règle de nat de ton 1er post.

PsYKrO_Fred

Justement la réponse est non...
J'ai des pages Intranet, j'ai des services qui utilise le port 80 etc... et vice versa par exemple si je veux me connecter sur la page web des multifonctions, je ne peux pas.

Publicité

Gimea

So, get rid of noise.

T'as accès à l'espace client Netasq ?

PsYKrO_Fred

Oui

Gimea

So, get rid of noise.

Dans la base de connaissance de l'espace client va lire cet article alors :

Depuis que j'ai activé le proxy, je ne parviens plus à communiquer à travers mes tunnels IPSec site à site sur les flux concernés, quel est le problème ?

PsYKrO_Fred

j'y vais de ce pas

Gimea

So, get rid of noise.

Sinon il y a également cet article :

Comment désactiver le proxy http pour un site particulier ?

Mais cela correspond à la solution de NAT de ton 1er post.

PsYKrO_Fred

Ca me semble intéressant, je le poste ici.

Citation :

Une fois que le proxy a terminé ses traitements sur une requête HTTP, il doit établir une nouvelle connexion pour relayer cette requête et la transmettre à sa destination réelle. Dès lors, l'adresse IP source de l'émetteur de cette nouvelle connexion n'est plus la machine d'origine mais le firewall.

Lorsque le firewall établit une connexion vers une destination quelconque, l'adresse IP source prise par les paquets est celle de l'interface de sortie des paquets. Or, d'un point de vue chronologique, le paquet est d'abord traité par le proxy, puis par le module IPSec.Donc lorsque le proxy doit déterminer l'adresse IP source qu'il doit attribuer aux paquets sortants, il ne sait pas que ces paquets sont destinés au tunnel IPSec. Il détermine donc l'interface de sortie via la table de routage classique du firewall, pour s'apercevoir que la destination, le réseau privé distant, est inconnue du point de vue routage et en déduit que le paquet doit être envoyé vers la passerelle par défaut du firewall.

Or dans une configuration classique en mode routé, la passerelle par défaut est située sur la patte out du firewall. Les paquets prennent donc l'adresse iP de cette interface comme source.

Ils arrivent ensuite dans le module IPSec qui se base sur les adresses IP source et destination pour les comparer avec sa SPD et déterminer si le paquet doit être chiffré pour être envoyé dans un tunnel IPSec. Dans ce cas, comme les paquets arrivent avec Firewall_out en IP source ils ne correspondent à aucune politique IPSec, qui elles ont été configurées avec, par exemple, Network_in en extrémité locale de trafic.

C'est pourquoi, à configuration inchangée, les paquets HTTP ne sont plus envoyés dans le tunnel IPSec après activation du proxy HTTP. Le comportement est identique pour les proxies SMTP, POP3 et DNS.

Pour remédier à cela, il existe deux solutions.

Modification de la politique IPSec

Vous pouvez modifier l'extrémité locale de trafic pour que Firewall_out y soit inclus. Attention cependant, Network_in doit également rester en extrémité locale de trafic pour les flux qui ne passent pas dans le proxy. Par exemple, vous pouvez créer un groupe dans lequel vous ajoutez Netwrok_in et Firewall_out, et le désigner comme extrémité locale de trafic. Evidemment, vous devez effectuez les modifications équivalentes sur le correspondant IPSec distant.

Source Netasq

Message édité par PsYKrO_Fred le 08-04-2013 à 15:41:57

PsYKrO_Fred

Par contre je me pose la question suivante :

Interface: IN (ou celle sur laquelle écoute le proxy)
Action: Redirect
Source: Any
Destination: site_sans_proxy
Destination port: 80
Translaté: site_sans_proxy
Port translaté: 80

Je dois le faire sur chaque extrémité ?

PsYKrO_Fred

Je vais tenter la premiere solution demain.

Gimea

So, get rid of noise.

Si tu as juste 2 sites avec qqs serveurs web de l'autre coté, la solution du NAT est simple.

Tu crées juste ta règle de NAT sur le firewall du site ou il n'y a pas le serveur. En fait c'est juste une règle de NAT qui va être prioritaire sur la règle implicite qui redirige les paquets sur le proxy.
Ca te permet de "bypasser" le proxy transparent.

Ou bien tu pourrais ne pas avoir à faire ça et fonctionner avec un proxy déclaré dans ton navigateur, plusieurs solutions alors : WPAD, gpo, etc.

Mais je crois qu'il faut passer en V9 sur tes Netasq, à vérifier.

PsYKrO_Fred

En fait, j'ai vérifié je n'ai que des U30 et la V9 est mal supporté alors il faudrait que j'achète des U30X.... donc bon....

Je veux accéder de chaque coté à des pages http. C'est pour ça que je demande s'il faut que fasse le nat sur chaque firewall.

Pour finir, tu me dis de passer par une solution navigateur, cela me convient pas car des fois c'est dans les applications qu'ils utilisent le port 80. Il faudrait dans ce cas modifier le port de communication pour chaque appli... Je trouve cela un lourd.

Message édité par PsYKrO_Fred le 08-04-2013 à 16:23:12

Gimea

So, get rid of noise.

La v9 est mal supportée sur les U30 ?

PsYKrO_Fred

Oui (au niveau performance)
C'est pour ça qu'ils sortent les nouvelles series U30(X)
La v9 est trop lourd pour les anciennes générations.

Message édité par PsYKrO_Fred le 08-04-2013 à 16:52:53

PsYKrO_Fred

Merci test effectué

Publicité

FORUM HardWare.fr

Systèmes & Réseaux Pro

Réseaux

[Résolu] Netasq Ipesec impossible de joindre des page web

Sujets relatifs
Analyseur de logs firewall (welf) - équivalent NetAsq Event Analyzer	Connexion impossible aux webmails
Restauration d'une config Netasq ancienne sur du neuf	Suppression objet AD impossible
RV042 dual wan... gestion trafic impossible [HELP]	[résolu] password recovery sur un Netasq F50 V3.5
[RESOLU] netasq F60 - probleme de mise en fonctionnement	VPN Ipsec Netasq Nomade
Connexion VPN IPSEC entre Netasq et serveur 2003	Cisco VPN distant monte mais impossible de pinger quoi que ce soit !
Plus de sujets relatifs à : [Résolu] Netasq Ipesec impossible de joindre des page web

Page générée en 0.084 secondes