Probleme VPN entre Ipcop

par **eric_car** » 30 Mars 2007 00:03

Bonjour

je gère actuellement plusieurs Ipcop.

J'ai un probleme de VPN avec un Ipcop 1.4.15 (install 1.4.10 mis a jour)

Le VPN a déja fonctionner sur ce serveur, j'ai refait la configuration des 2 serveurs sans resultat.
Il y a un topic avec cette erreur, la 'solution' a ete de formatter et reinstall, j'aimerais comprendre ?

voila le log IPSEC qui boucle sur l'Ipcop qui pose problème

23:54:36 pluto[696] packet from 217.128.139.55:500: initial Main Mode message received on 217.128.13 9.61:500 but no connection has been authorized with policy=RSASIG
23:54:36 pluto[696] packet from 217.128.139.55:500: received Vendor ID payload [Dead Peer Detection]
23:54:36 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-00]
23:54:36 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-02]
23:54:36 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-03]
23:54:36 pluto[696] packet from 217.128.139.55:500: received Vendor ID payload [RFC 3947]
23:53:56 pluto[696] packet from 217.128.139.55:500: initial Main Mode message received on 217.128.13 9.61:500 but no connection has been authorized with policy=RSASIG
23:53:56 pluto[696] packet from 217.128.139.55:500: received Vendor ID payload [Dead Peer Detection]
23:53:56 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-00]
23:53:56 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-02]
23:53:56 pluto[696] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-03]
23:53:56 pluto[696] packet from 217.128.139.55:500: received Vendor ID payload [RFC 3947]
23:53:16 pluto[696] packet from 217.128.139.55:500: initial Main Mode message received on 217.128.13 9.61:500 but no connection has been authorized with policy=RSASIG

Avez vous une idée du problème, je sèche.
Merci de vos conseils

par **Titofe** » 30 Mars 2007 09:34

J’ai eu un problème similaire cette semaine, celui ou j’avais fait les mise à jour de IPCop 1.4.13 à 1.4.15 pas eu de problème, mais sur celui ou j’ai tout réinstaller, quand j’ai reparametrer mon VPN il n’à pas fonctionner la première fois, je me suis dit que je me suis tromper mais au bout d’un dizaine de fois, la je me suis dit pourquoi ne pas relancer les deux machine, depuis ça marche.
Tu peux toujours essayer …

Titofe

par **eric_car** » 30 Mars 2007 13:08

J'ai déja essayer le reboot, a plusieur reprise, toujour le même problème

Merci quand même

par **eric_car** » 30 Mars 2007 13:26

J'ai trouvé dans le log, la source de l'erreur

13:22:19 pluto[712] packet from 217.128.139.55:500: initial Main Mode message received on 217.128.13 9.61:500 but no connection has been authorized with policy=RSASIG
13:22:19 pluto[712] packet from 217.128.139.55:500: received Vendor ID payload [Dead Peer Detection]
13:22:19 pluto[712] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-00]
13:22:19 pluto[712] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-02]
13:22:19 pluto[712] packet from 217.128.139.55:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat -t-ike-03]
13:22:19 pluto[712] packet from 217.128.139.55:500: received Vendor ID payload [RFC 3947]
13:22:04 vpn-watch 'montunel': start watching 217.128.139.55
13:22:04 pluto[712] "montunel": we have no ipsecN interface for either end of this connection
13:22:04 pluto[712] added connection description "montunel"
13:22:04 pluto[712] loaded host cert file '/var/ipcop/certs/montunelcert.pem' (1204 bytes)
13:22:04 pluto[712] loaded host cert file '/var/ipcop/certs/hostcert.pem' (1147 bytes)

Que veut dire cet erreur, comment la corrigée, merci de vos conseils

par **Poupou94** » 30 Mars 2007 15:10

Bonjour,

Tu es sur qu'il est démarré à l'autre bout ?

Pascal.

par **eric_car** » 30 Mars 2007 15:45

Oui de l'autre coté c'est OK

Voivi le log du deuxième Ipcop

15:25:35 pluto[1953] "kerlut" #97: initiating Main Mode to replace #95
15:25:35 pluto[1953] "kerlut" #95: starting keying attempt 72 of an unlimited number
15:25:35 pluto[1953] "kerlut" #95: max number of retransmissions (20) reached STATE_MAIN_I1. No acce ptable response to our first IKE message

Sur ce deuxième Ipcop, j'ai réussi a faire un VPN vers un troisième
Par contre du premier vers le troisième j'ai la même erreur. Ce qui me fait dire que le problème vient du premier.

par **Poupou94** » 30 Mars 2007 15:54

tu as certainement raison, mais pour info j'ai fais il y a une semaine la même manip que toi migration de version 1.4.10 vers 1.4.15 d'un coté puis de l'autre sans rencontrer le moindre problème ( je passais par le VPN pour les mises à jour du distant... j'ai donc eu peut être de la chance
Plus sérieusement je pense qu'il faut chercher ailleurs que dans la mise à jour.

Pascal.

par **Poupou94** » 30 Mars 2007 19:20

Bonsoir,

il y a pas mal de topic dans google pour ton problème

Un qui est pas mal

http://freespace.virgin.net/christiaan. ... v1.02.html

Basé sur IPCop en plus

Pascal.

par **eric_car** » 30 Mars 2007 21:06

La mise à jour n'est pas la source du problème, j'ai eu le probleme en 1.4.10, puis j'ai mis a jour mes serveurs en espérant resoudre le probleme. Mais pas mieux? J'ai fait un RAZ de mes vpn et tout reconfigurer, mais rien n'y fait.

Au fait je n'arrive pas a accèder au lien ci dessus,

Merci quand même.

par **fgth** » 31 Mars 2007 17:10

UP UP j'ai exactement le même problème, mêmes messages sur 2 IPCop 1.4.15 tous frais installé. Ils restent fermé, j'ai les messages du premier post d'eric_car, ("...no connection have benn authorized...", "..no IPsecN...", etc).
Je suis bloqué, et bien sûr la mise en place urge, il y a une install d'appli lundi qui est sensé utiliser ce VPN...

Help. Quelqu'un a-t-il une idée ?????

par **fgth** » 31 Mars 2007 17:56

Bien en relisant ce post, j'ai fait un tour sur http://freespace.virgin.net/christiaan.theron1/....
Il semble que je rentre dans un des cas, mais la solution donnée ne fonctionne pas.

Voici la config :

left : IPCop RED via un modem paramétré en bridge (RED prend la valeur de l'IP publique fixe)

right : IPCop via une Livebox... plus compliqué. IPCop RED est en 192.168.87.128, discutant avec la Livebox en 192.168.87.254. Puis la livebox a un IP dynamique côté internet.
La DMZ de la livebox est dirigée vers 192.168.87.128 (IPCop RED) : ça marche, les ssh, 4445 et autres accès externes passent la livebox comme si elle n'existait pas : c'est le but.
Par contre il y a du NAT pour sortir de là : donc l'IPCop left reçoit des paquets qui lui arrivent de "192.168.87.128" alors qu'il attend l'IP dynamic (via dyndns) en 90.24.xx.xx....

J'ai donc ajouté comme indique un "rightid" dans l'ipsec.conf de left, avec 192.168.87.128, mais pas mieux.

Je sèche. HELP.

par **fgth** » 31 Mars 2007 19:07

Rien à faire. Je viens de tout refaire avec des clés PSK pour aller plus vite, j'ai fait les modifs de l'ipsec.conf et .secret du left, mais toujours ce même message sur le right :

"packet from 82.127.35.96:500: initial Main Mode message received on 192.168.87.1 28:500 but no connection has been authorized with policy=PSK"

Je pleure ? Bôf même plus envie.

par **igo** » 01 Avr 2007 01:29

bonjours,

chez moi ca ne fonctionne pas non plus,
mais je remarke que sur la 1.415 il n'est plus mention de left ou de right

a la place j ai mis RED(toto.moi.fr) sur les 2 ipcop

cela pause t'il problem ?

j'ai editer le ipsec.conf du premier ipcop et ai remplacé left par right et right par left

mais ca na rien arangé du tout...

c'est mon premier essai de montage d'un vpn, alors j'ai suivis le tuto du newbe kit, mais il est plus a jour.

ce genre de details me perturbe assez je dois dire car je ne sais pas qui de moi ou d'ipcop déconne...

par **Franck78** » 01 Avr 2007 02:46

Left ou right ne change rien à la configuration IPSec.
Il faut plutôt penser
LEFT=Local
RIGHT=Remote

Dans 99% des cas le VPN est fait vers l'internet donc à partir de RED.

Une chose de sure pour un IPCop derrière un équipement qui natte, il ne sait pas quoi faire car le paquet est source IP=IP du remote normal, et DEST IP=192.168.x.x (ou autre mais nattée), et si la config PSK est faite avec les IP publiques, il donne le message NO connection authorized...

C'est à ce moment que les IDs servent (pas sur à 100% mais si ils ne servent pas à ce stade...). Il faut mettre autre chose que l'IP. Un nom FQDN convient.

par **igo** » 01 Avr 2007 11:32

merci pour l'explication, sur left et right

cela me fait dire que peut-être le newbe kit a ce sujet est faut ?

puisqu'il mentionne, de metre left sur le premier ipcop et right sur le deuxieme.....
d'ou ma confusion plus haut.

dans mon cas 2 ipcop 1.4.13 upgradés à 1.4.15, tous 2 derriere une freebox en bridge
la carte red recupérent bien l ip publique, ip synchronisées avec un dyndns

mon probleme a moi serrai plutot du genre :

01:23:38 pluto[5311] "ipcop" #2: X.509 certificate rejected
01:23:38 pluto[5311] "ipcop" #2: Certificate is invalid

la franchement je ne peux pas faire grand chose si les certificats ne sont pas reconnus

ce message n'apparait que sur un des 2 ipcop
historique de cet ipcop install 1.4.13 + bot + squidguard + advanced qos, puis maj 1.4.14 puis 1.4.15

a l'heure actuelle j'attends la disponibilité d'un 3eme site pour faire des essai avec un autre ipcop
afin de determiner lequel pause probleme

Probleme VPN entre Ipcop

Probleme VPN entre Ipcop

Qui est en ligne ?