Bonjour a tous,
 
Je travaille actuellement sur un firewall cisco Pix 515 (je suis pas expert, c'est dans le cadre d'un stage).
 
Tout fonctionne avec le Pix néanmoins quelquechose m'intringue :
Quand j'ai voulu me connecter au départ en VPN sur un routeur distant (Soho) ca a pas marché tout de suite, j'ai du creer une règle :
 
PiX(config)# access-list acl-soho permit ip host IP_Soho_Publique any
PiX(config)# access-group acl-soho in interface outside
 
Par contre si je veux me connecter sur un autre serveur distant (via IP publique), en ssh par exemple (avec PuTTy), pas besoin de créer une telle règle, ca marche direct
Et cela meme si la connection VPN est arretée
 
Je comprend pas trop la différence entre les 2, pourquoi dans un cas je devrais accepter les connections entrantes de Soho public et dans l'autre cas (qui me semble plus normal) le retour de connection est accepté directement : j'ai lu partout que le Pix acceptait automatiquement une connexion entrante, a condition que celle ci soit justifiée par une demande préalable : c'est le cas pour la demande de connection VPN .. alors pourquoi créer une règle ?
 
Vous avez peut etre une hypothèse là dessus ?
 
En vous remerciant

up, personne n'a ne serait ce qu'une vague idée ?

Parceque le pix doit être configuré pour accepter le retour de connexions sortantes, ce qui n'est pas la même chose qu'une connexion entrante.
Edit : il est probable qu'il y avait déjà une access list en "in" sur l'interface outside

en fait, c'est pas vraiment une connection entrante.
Quand on dit que le PIX est statefull, ca veut dire que si tu initie une connexion TCP d'un port X vers un port Y, forcement, le traffic TCP dans l'autre sens sera accepté (ce qui n'a pas toujours été le cas).
Idem pour UDP.
Par contre, dans le cas de protocoles de plus haut niveau, le PIX ne sais pas forcement qu'une connection de l'autre serveur VPN vers ton pix fait suite a une demande de ta part. (Pour etre biensur de ca, il faut analyser en fond, en large et en travers les connexions générées par une connexion VPN)
 
L'exemple le plus courant est le cas du FTP qui nécessite l'écoute des transmissions pour savoir quelles règles ouvrir automatiquement pour le canal DATA.
 
Je sais pas si j'ai été clair .. si non, je peux toujours _essayer_ de préciser

Oui tu as été plus ou moins clair, tu dis que c'est parce que le Pix ne peut pas "reconnaitre" que je fais appel a cette connection car c'est pas un protocole TCP / UDP / IP (...) mais PPTP / IPSec (PPTP dans mon cas)
 
Pourtant le Pix est parfaitement capable de gérer le VPN, il permet meme d'initialiser des connections a distantes sur des routeurs VPN. Mais cependant faute de mieux je me raccroche volontiers a ta thérorie, merci d'ailleurs.
 
Pour le coup du FTP qui nécessite l'écoute des transmissions j'ai pas bien compris le fond de ta pensée, si tu pouvais developper ca m'aiderai un petit peu.
 
zvince > je t'assure que la seule access list est seule que j'ai mise, et la connection VPN est bien un "retour" de connection sortante

une session ftp stad, c'est le client qui initie une connection tcp sur le port 21 du serveur .. tout va bien, le PIX voit la connection s'etablir, et laisse passer les paquets dans un sens puis dans l'autre.
Mais pour le transfert des données (hors mode passif, qui est un cas particulier), c'est le serveur qui initie une nouvelle connection DATA sur un port du client qui a été négocié dans la sessions de controle. Si le PIX n'ecoute pas la sessions de controle, il refusera la connection du serveur.
 
(pour la config du cas FTP, ceci se confuigure avec les commandes fixup PROTOCOLE)

Oui mais apparemment le client (moi) envoie une demande de connection en clair (FTP), ce a quoi le serveur repond en utilisant un protocole bien spécifique aux connections VPN (GRE) donc dans mon cas je remplace "ip" par "gre" et ca marche toujours (et c'est plus restrictif ca tombe bien )
C'est exactement ce que tu dis
 
Merci pour ton aide