Bonjour, je commence à m'arracher les cheveux sur un problème de communication VPN entre deux réseaux.
 
D'un côté, donnant sur le net, j'ai un routeur/firewall sous Debian, sur lequel est branché un serveur VPN (qui se trouve être un routeur Netopia, mais qui n'est utilisé que pour le VPN) ainsi que le réseau local.
 
De l'autre côté, un modem/routeur Speedtouch.
 
Tout cela fonctionnait à merveille, jusqu'à ce que... ça ne marche plus. J'en viens à suspecter une mise à jour de Debian, qui aurait désactivé quelque chose. Ce routeur utilise iptables pour gérer le nat. Les protocoles AH et ESP ainsi que le port UDP 500 sont redirigés vers le serveur VPN
 
Voici la trame capturée sur le routeur Debian lors du redémarrage du modem Speedtouch (distant) :
 
où 22.22.22.22 est l'IP publique du routeur Speedtouch
11.11.11.11 est l'IP publique du routeur/firewall sous Debian
192.168.0.3 est l'IP interne du serveur VPN Netopia
# tcpdump -i any -n host 22.22.22.22
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
09:42:21.781324 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 1 I ident
09:42:21.781397 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 1 I ident
09:42:21.787651 IP 192.168.0.3.500 > 22.22.22.22.500: isakmp: phase 1 ? ident
09:42:21.787679 IP 11.11.11.11.500 > 22.22.22.22.500: isakmp: phase 1 R ident
09:42:22.271300 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 1 I ident
09:42:22.271321 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 1 I ident
09:42:26.281597 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 1 I ident
09:42:26.281619 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 1 I ident
09:42:27.757487 IP 192.168.0.3.500 > 22.22.22.22.500: isakmp: phase 1 ? ident
09:42:27.757507 IP 11.11.11.11.500 > 22.22.22.22.500: isakmp: phase 1 R ident
09:42:28.319837 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 1 I ident[E]
09:42:28.319857 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 1 I ident[E]
09:42:32.323343 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 1 I ident[E]
09:42:32.323370 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 1 I ident[E]
09:42:34.674475 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x76f551c0,seq=0x338), length 260
09:42:34.674491 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x76f551c0,seq=0x338), length 260
09:42:34.722875 IP 192.168.0.3.500 > 22.22.22.22.500: isakmp: phase 1 ? ident[E]
09:42:34.722891 IP 11.11.11.11.500 > 22.22.22.22.500: isakmp: phase 1 R ident[E]
09:42:35.220016 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 2/others I oakley-quick[E]
09:42:35.220035 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 2/others I oakley-quick[E]
09:42:39.234085 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 2/others I oakley-quick[E]
09:42:39.234113 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 2/others I oakley-quick[E]
09:42:45.353663 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 2/others I oakley-quick[E]
09:42:45.353699 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 2/others I oakley-quick[E]
09:42:47.700589 IP 192.168.0.3.500 > 22.22.22.22.500: isakmp: phase 2/others ? oakley-quick[E]
09:42:47.700617 IP 11.11.11.11.500 > 22.22.22.22.500: isakmp: phase 2/others R oakley-quick[E]
09:42:47.795774 IP 22.22.22.22.500 > 11.11.11.11.500: isakmp: phase 2/others I oakley-quick[E]
09:42:47.795804 IP 22.22.22.22.500 > 192.168.0.3.500: isakmp: phase 2/others I oakley-quick[E]
09:42:54.499967 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x1), length 260
09:42:54.499987 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x1), length 260
09:43:02.066786 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x2), length 260
09:43:02.066802 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x2), length 260
09:43:04.412700 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x3), length 260
09:43:04.412713 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x3), length 260
09:43:35.927834 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x4), length 260
09:43:35.927857 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x4), length 260
09:44:05.915642 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x5), length 276
09:44:05.915659 IP 192.168.0.3 > 22.22.22.22: ESP(spi=0x86c0f51f,seq=0x5), length 276
 
En somme, ça me semble négocier sans problème les deux premières phases. Mais les paquets ESP ne semblent pas obtenir de réponse. Ceci dit, j'en vois passer quelques fois dans l'autre sens, mais ils semblent un peu perdus, ne pas être des réponses.
 
Du côté du serveur VPN, il indique qu'il a envoyé 36000 paquets mais qu'il en a reçu 0
 
J'ai eu des troubles avec les VPN PPTP en même temps, que j'ai résolu en activant les modules ip_conntrack_pptp et ip_nat_pptp existe-t-il l'équivalent pour IPsec ? j'ai l'impression que le problème vient d'iptables qui ne sait pas gérer le truc. Sinon, cela peut-il être un problème de routage ? voire un problème d'adressage ?