Problème accès machine derrière VPN par l'interface Green

Forum traitant de la distribution sécurisée montante nommée IP cop et basée sur la distribution Smoothwall. C'est à l'heure actuelle le forum le plus actif du site.

Modérateur: modos Ixus

Problème accès machine derrière VPN par l'interface Green

Messagepar shtroumf » 30 Avr 2008 13:20

Ma config :

à Gauche du VPN (Cisco PIX 515)
site 1 : 10.114.0.0/21
serveur www/dns/tralala : 10.114.1.1
client 1 : 10.114.1.20

à Droite du VPN
site 2 : 192.168.0.0/24
ip Green : 192.168.0.254 (ipcop)
ip RED : 66.36.11.11 (ipcop RED avec un dyndns)
client 2 :192.168.0.100

Voici la situation :
VPN Monté entre site 1 et site 2 : OK
Ping entre client 2 et serveur www : OK
connexion entre client 2 et server www : OK
ping entre serveur www et ip Green : OK
ping entre client 1 et ip Green : OK
connexion interface web de IPCOP entre client 1 (10.114.1.20->192.168.0.254): OK
ping entre ip Green (console ipcop) et serveur www : PAS OK
connexion entre ip Green et serveur www : PAS OK
connexion entre ip Green et serveur www.google.ca : OK
ping entre ip Green et www.yahoo.com : OK

en fait, tout ce qui origine de l'if green de mon IPCOP vers l'"autre réseau" (l'autre bout du VPN) ne passe pas...
tcpdump me donne ceci sur l'interface ipsec0 lorsque je pind du Green ipcop(connecté en SSH)
07:14:50.433853 IP 66.36.11.11 > 10.114.1.1: ICMP echo request, id 22058, seq 0, length 64

Logique que ca passe pas, la source est mon adresse public RED, elle devrait être mon adresse local Green... mais elle ne l'est pas.
Le tcpdump devrait ressembler à cela :
07:14:50.433853 IP 192.168.0.254 > 10.114.1.1: ICMP echo request, id 22058, seq 0, length 64


Voici le même ping, mais du client 2 vers le serveur www
07:16:13.882107 IP 192.168.0.100 > 10.114.1.1: ICMP echo request, id 1, seq 1121, length 40
07:16:14.063296 IP 10.114.1.1 > 192.168.0.100: ICMP echo reply, id 1, seq 1121, length 40


Donc voici ce que je pense : Un problème avec le règles iptables qui ne fait pas la bonne translation d'adresse pour mon interface RED lorsque je veut communiquer avec le réseau "externe"(l'autre bout du vpn)...

Ce qui fait que : Mon squid n'arrive pas à contacter mes serveurs web interne et ne peut pas en cacher le contenu (1) et 2, les client qui passent par le proxy (pas transparent dans mon cas) n'arrive pas à afficher la page du serveur www

Merci de vos réponse à l'avance!
shtroumf
Matelot
Matelot
 
Messages: 4
Inscrit le: 20 Août 2005 14:45

Messagepar shtroumf » 30 Avr 2008 17:12

J'ai trouvé une solution :
avec la commande suivante le tout fonctionne à merveille, mon souci maintenant, c'est que je doit exécuter cette commande à CHAQUE montage du VPN.. COmment je peux faire cela??

ip route change 10.114.0.0/21 dev ipsec0 src 192.168.0.254

Merci
shtroumf
Matelot
Matelot
 
Messages: 4
Inscrit le: 20 Août 2005 14:45

Messagepar mlpbinfo » 04 Juin 2008 16:33

shtroumf a écrit:J'ai trouvé une solution :
avec la commande suivante le tout fonctionne à merveille, mon souci maintenant, c'est que je doit exécuter cette commande à CHAQUE montage du VPN.. COmment je peux faire cela??

ip route change 10.114.0.0/21 dev ipsec0 src 192.168.0.254

Merci


Enfin je tombe sur le bon post, merci pour cette solution, c'est génial ça fait quelque jours que j'étais sur le même problème !

Concernant le lancement de la commande après chaque re-démarrage du vpn, c'est chaud car c'est ipsec qui gère cette reconnexion en auto (fonction appelée Dead Peer Detection cf http://www.openswan.com/docs/local/README.DPD suivant l'option que tu as cochée dans la config du vpn).

Y-a-t-il un spécialiste ipsec dans la salle ?


Je ne peux que te proposer du réchauffé (inspiré du newbie kit : http://forums.ixus.fr/viewtopic.php?p=192186#192186) c'est à dire faire un script lancé toutes les 5 min par ex qui vérifie que ton serveur répond au ping.

Si ce n'est pas le cas tu lances ta commande...

Question subsidiaire
la table de routage est modifié comme suit (ligne entre ****) avec la commande

Code: Tout sélectionner
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
rv11lo2.lnaub15 *               255.255.255.255 UH    0      0        0 ppp0
rv11lo2.lnaub15 *               255.255.255.255 UH    0      0        0 ipsec0
192.168.176.0   *               255.255.255.0   U     0      0        0 eth0
****192.168.161.0   rv11lo2.lnaub15 255.255.255.0   UG    0      0        0 ipsec0 ***
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
1.1.1.0         *               255.255.255.0   U     0      0        0 eth2
default         rv11lo2.lnaub15 0.0.0.0         UG    0      0        0 ppp0


Code: Tout sélectionner
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
rv11lo2.lnaub15 *               255.255.255.255 UH    0      0        0 ppp0
rv11lo2.lnaub15 *               255.255.255.255 UH    0      0        0 ipsec0
192.168.176.0   *               255.255.255.0   U     0      0        0 eth0
****192.168.161.0   *               255.255.255.0   U     0      0        0 ipsec0 ****
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
1.1.1.0         *               255.255.255.0   U     0      0        0 eth2
default         rv11lo2.lnaub15 0.0.0.0         UG    0      0        0 ppp0


Est-ce que cela peut avoir un impact ?

J'ai testé depuis les stations clientes derrière l'ipcop et tout semble ok !

Merci à vous tous ...ce forum est une mine d'or !
Faites ça encore bien :-)
mlpbinfo
Quartier Maître
Quartier Maître
 
Messages: 22
Inscrit le: 05 Juin 2002 00:00
Localisation: Brest 29-FR


Retour vers IPCop

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité

cron