RPVs ipcop à ipcop FERMÉ

[secure]

Bonjour,
Je rencontre un problème de connexion d'une liaison VPN IPSEC entre deux IPCOP.
Je passe par le module RPVs.
Mes deux IPCOP sont en version 1.4.21 et sont tout deux en IP Publique fixe sur le port eth1.
Mes deux sous réseau sont bien différent l'un de l'autre 192.168.1.0/24 et 192.168.0.0/24.
Sur mes deux IPCOP dans ETAT/CONNEXIONS je vois bien la connexion IPCOP-->IP DISTANTE sur le port 500 comme ASSURED.
Sur mes deux IPCOP dans LOG/PAREFEU je vois bien la connexion INPUT IP DISTANTE sur le port 500(ISAKMP).

Je précise que le tunnel utilise des certificats qui ont bien été contrôlé même réinitialisé, que l'Encryptage IKE, Intégrité IKE... sont bien similaires des deux côtés. Que les liaison internet sont deux SDSL avec BUSINESS PRO 1000 (orange business) en mode bridge (normalement).

Mon problème est que, malgré tout cela, mon tunnel reste FERMÉ.

Est-ce un problème de NAT-Transversal lié à BUSINESS PRO 1000?
Dois-je faire une translation de port 500,4500...?

Pour les plus experts, voici le log IPSEC (chronologique inverse)

08:59:08 ipsec__plutorun ...could not start conn "OPHLMtoGIELL"
08:59:08 ipsec__plutorun 000 "OPHLMtoGIELL" #2: starting keying attempt 2 of an unlimited number, but rel easing whack
08:59:08 ipsec__plutorun 031 "OPHLMtoGIELL" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
08:59:08 ipsec__plutorun 010 "OPHLMtoGIELL" #2: STATE_QUICK_I1: retransmission; will wait 40s for respons e
08:59:08 ipsec__plutorun 010 "OPHLMtoGIELL" #2: STATE_QUICK_I1: retransmission; will wait 20s for respons e
08:59:08 ipsec__plutorun 122 "OPHLMtoGIELL" #2: STATE_QUICK_I1: initiate
08:59:08 ipsec__plutorun 004 "OPHLMtoGIELL" #1: STATE_MAIN_I4: ISAKMP SA established
08:59:08 ipsec__plutorun 108 "OPHLMtoGIELL" #1: STATE_MAIN_I3: sent MI3, expecting MR3
08:59:08 ipsec__plutorun 003 "OPHLMtoGIELL" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
08:59:08 ipsec__plutorun 106 "OPHLMtoGIELL" #1: STATE_MAIN_I2: sent MI2, expecting MR2
08:59:08 ipsec__plutorun 003 "OPHLMtoGIELL" #1: received Vendor ID payload [Dead Peer Detection]
08:59:08 ipsec__plutorun 003 "OPHLMtoGIELL" #1: received Vendor ID payload [RFC 3947]
08:59:08 ipsec__plutorun 104 "OPHLMtoGIELL" #1: STATE_MAIN_I1: initiate
08:59:08 pluto[20468] "OPHLMtoGIELL" #3: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS to replace #2
08:59:08 pluto[20468] "OPHLMtoGIELL" #2: starting keying attempt 2 of an unlimited number, but releasi ng whack
08:59:08 pluto[20468] "OPHLMtoGIELL" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no prop osal
08:59:00 pluto[20468] "OPHLMtoGIELL" #1: sending encrypted notification INVALID_ID_INFORMATION to 217.217.217.217:500
08:59:00 pluto[20468] "OPHLMtoGIELL" #1: cannot respond to IPsec SA request because no connection is k nown for 192.168.0.0/24===194.206.245.237[C=FR, O=GIELL, CN=199.199.199.199]:17/ 1701...217.108.178.245[C=FR, O=OPHLM, CN=217.217.217.217]:17/1701
08:58:28 pluto[20468] "OPHLMtoGIELL" #1: received and ignored informational message
08:58:28 pluto[20468] "OPHLMtoGIELL" #1: ignoring informational payload, type INVALID_MESSAGE_ID
08:58:20 pluto[20468] packet from 217.217.217.217:500: Quick Mode message is for a non-existent (expir ed?) ISAKMP SA
08:58:08 pluto[20468] "OPHLMtoGIELL" #1: received and ignored informational message
08:58:08 pluto[20468] "OPHLMtoGIELL" #1: ignoring informational payload, type INVALID_MESSAGE_ID
08:58:01 pluto[20468] packet from 217.217.217.217:500: Quick Mode message is for a non-existent (expir ed?) ISAKMP SA
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: received and ignored informational message
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: ignoring informational payload, type INVALID_ID_INFORMATION
08:57:58 pluto[20468] "OPHLMtoGIELL" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: ISAKMP SA established
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: Issuer CRL not found
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: Issuer CRL not found
08:57:58 pluto[20468] "OPHLMtoGIELL" #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=FR, O=OPHLM, CN=217.217.217.217'
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: received Vendor ID payload [Dead Peer Detection]
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: received Vendor ID payload [RFC 3947]
08:57:57 pluto[20468] "OPHLMtoGIELL" #1: initiating Main Mode
08:57:57 pluto[20468] loaded private key file '/var/ipcop/certs/hostkey.pem' (887 bytes)
08:57:57 pluto[20468] loading secrets from "/etc/ipsec.secrets"
08:57:57 pluto[20468] adding interface ipsec0/eth1 199.199.199.199:4500
08:57:57 pluto[20468] adding interface ipsec0/eth1 199.199.199.199
08:57:57 pluto[20468] listening for IKE messages
08:57:57 pluto[20468] added connection description "OPHLMtoGIELL"
08:57:57 pluto[20468] loaded host cert file '/var/ipcop/certs/OPHLMtoGIELLcert.pem' (1139 bytes)
08:57:57 pluto[20468] loaded host cert file '/var/ipcop/certs/hostcert.pem' (1139 bytes)
08:57:57 pluto[20468] | from whack: got --ike=aes256-sha2_512-modp1536,aes256-sha2_256-modp1536,aes256 -sha-modp1536,aes128-sha2_512-modp1536,aes128-sha2_256-modp1536,aes128-sha-modp1 536!
08:57:57 pluto[20468] | from whack: got --esp=aes256-sha2_512,aes256-sha2_256,aes256-sha1,aes128-sha2_ 512,aes128-sha2_256,aes128-sha1!;modp1536
08:57:57 pluto[20468] OpenPGP certificate file '/etc/pgpcert.pgp' not found
08:57:57 pluto[20468] loaded crl file 'cacrl.pem' (560 bytes)
08:57:57 pluto[20468] Changing to directory '/etc/ipsec.d/crls'
08:57:57 pluto[20468] loaded cacert file 'OPHLMcert.pem' (1261 bytes)
08:57:57 pluto[20468] loaded cacert file 'cacert.pem' (1261 bytes)
08:57:57 ipsec_setup ...Openswan IPsec started
08:57:57 pluto[20468] Changing to directory '/etc/ipsec.d/cacerts'
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_SSH_PRIVATE_65289: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_CAST_CBC: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
08:57:57 pluto[20468] ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
08:57:57 pluto[20468] including NAT-Traversal patch (Version 0.6)
08:57:57 pluto[20468] including X.509 patch with traffic selectors (Version 0.9.42)
08:57:57 pluto[20468] Starting Pluto (Openswan Version 1.0.10)
08:57:57 ipsec__plutorun Starting Pluto subsystem...
08:57:57 ipsec_setup KLIPS ipsec0 on eth1 199.199.199.199/255.255.255.248 broadcast 199.199.199.200
08:57:57 ipsec_setup KLIPS debug `none'
08:57:57 ipsec_setup Starting Openswan IPsec 1.0.10...

[jdh]

Il y a un certain nombre d'incompréhensions !

- Red est en ip publique statique : NON !
- la Livebox est en bridge : NON !
- les extrémités sont bien désignées : NON !

De façon évidente, les livebox ne sont pas en bridge (ce qui serait bien) !
Site 1 : Red 199.199.199.199 <-> Livebox 194.2x6.2x5.2x7
Site 2 : Red 217.217.217.217 <-> Livebox 217.1x8.1x8.2x5
=> passez dans un adressage NORMAL : Red = 192.168.101.1/24 <-> 192.168.101.254/24 Box et .102. pour l'autre site
+ réglage de le DMZ de la box qui va bien.
Les extrémités seront OBLIGATOIREMENT l'adresse ip publique.

Il n'est pas sûr qu'un lien IPSEC fonctionne avec une Livebox (=cela dépend du modèle exact).
Si vous n'avez pas besoin de la ligne téléphonique, il est plus économique de remplacer la livebox par un modem/bridge (genre Dlink DSL320-B).
=> on économise 3€/mois, il faut configurer le DSL320-B en bridge RFC1483 et Red d'Ipcop en PPPoE (avec identifiant fti/xxxx + mdp).

Ipsec n'impose pas d'utiliser des certificats, il est possible d'utiliser une clé statique = peut être plus simple.

Question : les ip publiques sont elles fixes ? Un nom dns ne serait-il pas meilleur ?


NB : "sending encrypted notification INVALID_ID_INFORMATION to 217.217.217.217:500" montre que vous croyez que l'extrémité est 217.217.217.217 alors que c'est forcément l'ip publique.

[Franck78]

cannot respond to IPsec SA request because no connection is k nown for 192.168.0.0/24===194.206.245.237[C=FR, O=GIELL, CN=199.199.199.199]:17/ 1701...217.108.178.245[C=FR, O=OPHLM, CN=217.217.217.217]:17/1701

Hello,

@jdh, pour arriver là (state main I4) , il n'y a pas de problème avec les box ip (le réseau).

C'est donc la config des REDS et GREENS qu'il faut chercher. Peut être même les certificats.

Je commence TOUJOURS par une clé psk.

[ccnet]

Je commencerai aussi avec une configuration utulisant une psk.

[secure]

Désolé de répondre si tard.

Précisions:
- Les pattes RED des deux IPCOP sont en IP publiques fixes (comme précisé plus haut). Je dispose d'un poule d'IP pour les deux sites.
- Les "box" ne sont pas des box maison (pour "jdh"). Il s'agit de routeurs SDSL de chez mon fournisseur d'accès et ils se nomment Business Livebox Pro 1000. Ils disposent tout deux d'une IP publique fixe de mon pool.
- Les IP 217.217.217.217 et 199.199.199.199 sont fausses, j'ai juste modifié les IP pour ne pas publier les vraies.

Comme vous me le conseillez, j'ai également testé avec une PSK. Le problème est le même.
Côté LAN (GREEN) je ne vois pas se qui pourrait causer le problème (192.168.1.x d'un côté et 192.168.0.x de l'autre).
Si quelqu'un à une idée.

[jdh]

Ok pour les adresses ip publiques : je recommande de plutôt indiquer les 2 premiers vrais nombres : 194.206.xxx.xxx et 217.108.yyy.yyy
Voyant cette ligne, rappelée par franck78, cela m'avait laissé pensé que ...

La box (Business Livebox Pro) transmet-elle bien le flux à destination de l'ip publique sur la patte Red (Wan) ?
Le CN indiqué ne devrait-il pas correspondre à la vraie ip publique ?
Les masques et adresses réseaux de green sont elles bien en phase avec les réglages Ipsec ?

Je ne suis pas compétent et surtout assez précis en Ipcop. J'ai cependant réalisé des liens Ipsec sur des linux et sur pfSense.
Franck78 a lui la connaissance d'Ipcop et de lien Ipsec réalisé au travers d'Ipcop.

(Ma remarque sur les Green vaut toujours : évitez les trop classiques 192.168.0.x 192.168.1.x.)

[Franck78]

Quand je vois parler de poule, je ne résiste pas ! :

http://forums.ixus.net/viewtopic.php?f= ... 5&start=15
(ce n'est pas le seul topic).

Pour le VPN qui monte à moitié, il faut après le ISAKMP SA established
obtenir la IPSec SA

xxx transition from state (null) to state STATE_QUICK_R1
xxx Dead Peer Detection (RFC3706) enabled
xxx transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
xxx IPsec SA established

or tu as:

Code : Tout sélectionner

cannot respond to IPsec SA request because no connection is k nown for 192.168.0.0/24===194.206.245.237[C=FR, O=GIELL, CN=199.199.199.199]:17/ 1701...217.108.178.245[C=FR, O=OPHLM, CN=217.217.217.217]:17/1701


C'est toujours du à un problème de dialecte de chaque coté, option requise, interdite de l'autre. Revérifie encore.

Il faut les log des deux cotés (tout est en double).

J'ai un petit problème avec les IP publiques, le pool, RED et la livebox.
Mais si tu veux pas détailler tant pis.

Je me souviens de ça qui est très bavard.
#ipsec barf

ou encore
#ipsec verify

[secure]

Je remercie tout le monde et surtout Franck78 pour son aide.

Après plusieurs tentatives j'ai réussi, partiellement, à résoudre le problème.

Il semble que sur l'un des IPCOP, L2TP est installé (besoin antérieur). J'ai trouvé une archive nommée "l2tpd-0.69-9jdl_ipcop140-b1.tar.gz" contenant entre autre un fichier l2tpd.conf de configuration de L2TP over IPSEC (processus? désinstallation possible?).
Je ne sais pas si le problème vient de là mais lorsque je compare mes fichiers /etc/ipsec.conf, j'ai des différences.
L'IPCOP avec L2TP contient une ligne "leftprotoport", "rightprotoport" et il manque "leftsubnet".

Après quelques modifications cela fonctionne.

conn OPHLMtoGIELL #RED
left=217.xxx.xxx.217
leftnexthop=%defaultroute
leftprotoport=17/1701 supprimé et remplacé par leftsubnet=192.168.1.0/255.255.255.0
right=194.xxx.xxx.194
rightsubnet=192.168.0.0/255.255.255.0
rightnexthop=%defaultroute
rightprotoport=17/1701 supprimé
ike=aes128-sha-modp1536
esp=aes128-sha1
pfsgroup=modp1536
ikelifetime=1h
keylife=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
pfs=yes
authby=secret
auto=start

Le problème est que les modifications apportées au fichier ne sont pas permanentes. Toutes modifications du menu RPV en mode graphique, annulent le reste.

Mes questions sont donc les suivantes:

- Comment modifier définitivement ce fichier ou éviter qu'il se "restaure".

- Quelles sont les différences entre "leftprotoport" et "leftsubnet" dans l'établissement de la liaison. Est ce lié à une différence entre IPSEC et L2TP?
(pour ma culture générale)

[Franck78]

Je pense que les protoport n'on rien à voir dans l'histoire. D'autant qu'il son identiques. N'y touche pas.

Leftsubnet et rightsubnet sont (de mémoire)
-déduit de la conf réseau, ou
-simplement les valeurs inscrites dans la page de conf du vpn

Donc erreur de config. Vérifie les masques réseau.

[secure]

Voici les deux fichiers ipsec.conf après un reparamétrage. Ils sont différents.

IPCOP 1

conn OPHLMtoGIELL #RED
left=194.xxx.xxx.194
leftnexthop=%defaultroute
leftsubnet=192.168.0.0/255.255.255.0
right=217.xxx.xxx.217
rightsubnet=192.168.1.0/255.255.255.0
rightnexthop=%defaultroute
ike=aes128-sha-modp1536
esp=aes128-sha1
pfsgroup=modp1536
ikelifetime=1h
keylife=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
pfs=yes
authby=secret
auto=start

IPCOP2 (L2TP over IPSEC)

conn OPHLMtoGIELL #RED
left=217.xxx.xxx.217
leftnexthop=%defaultroute
leftprotoport=17/1701
right=194.xxx.xxx.194
rightsubnet=192.168.0.0/255.255.255.0
rightnexthop=%defaultroute
rightprotoport=17/1701
ike=aes128-sha-modp1536
esp=aes128-sha1
pfsgroup=modp1536
ikelifetime=1h
keylife=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
pfs=yes
authby=secret
auto=start

Si je modifie ipsec.conf de IPCOP 1 en ajoutant leftprotoport, cela ne fonctionne pas.

Si dans ipsec.conf de IPCOP 2 je supprime leftprotoport et ajoute leftsubnet, cela fonctionne. Le tunnel est ouvert mais je ne peux faire de ping d'un côté à l'autre. Et les modifications du fichiers disparaissent si je touche à la configuration en mode graphique.
Je pense sincèrement que le problème vient de ce L2TP over IPSEC mais je ne sais pas comment le supprimer. Est ce un processus que je doit tuer? Ou un addon à désinstaller?