Ipsec et Ipcomp

Support Debian
#1

Bonjour à tous,

Je teste IPsec avec le paquet APT ipsec-tools (donc setkey) sur 2 pc en debian 4.0.

J’ai testé AH, ESP et les 2 combinés en mode TRANSPORT avec succès.
Cependant, je n’arrive pas à faire fonctionner IPCOMP.

iptables sur PC1 et PC2 :
iptables –A INPUT –i eth0 –p ah –j ACCEPT
iptables –A OUTPUT –o eth0 –p ah –j ACCEPT
iptables –A INPUT –i eth0 –p esp –j ACCEPT
iptables –A OUTPUT –o eth0 –p esp –j ACCEPT
iptables –A INPUT –i eth0 –p ipcomp –j ACCEPT
iptables –A OUTPUT –o eth0 –p ipcomp –j ACCEPT

/etc/ipsec-tools.conf sur PC1 :
…
add 10.0.0.91 10.0.0.92 ipcomp 25000 -C deflate -R ;
spdadd 10.0.0.91 10.0.0.92 any -P out ipsec ipcomp/transport//require ;

/etc/ipsec-tools.conf sur PC2 :
…
add 10.0.0.91 10.0.0.92 ipcomp 25000 -C deflate -R ;
spdadd 10.0.0.91 10.0.0.92 any -P in ipsec ipcomp/transport//require ;

–> simple liaison unidirectionnelle de PC1 vers PC2.
–> testé avec et sans le –R de deflate.
–> “lsmod | grep ipcomp” sur PC1 et PC2, montre bien la présence de ipcomp.

sur PC1 et PC2 :
/etc/init.d/setkey restart

Sur PC1 :
Ping 10.0.0.92 ne répond pas !

Pourtant, sur PC2 :
avec tcpdump, je vois le ICMP ECHO REQUEST et ICMP ECHO REPLY!!!

–> je vois le ICMP ECHO REQUEST sans entête ipcomp ?!? Le noyau de PC1 ne peut pas l’envoyer en clair puisque policy en “require”. Par ailleurs, c’est peut être tcpdump qui n’interprète pas IPCOMP. J’ai donc essayé avec Wireshark. Mais je ne vois pas d’entête IPCOMP non plus. Remarquez, l’entête IPCOMP n’est qu’un simple incrément si j’ai bien compris : le CPI.

–> avec “while true ; do clear ; iptables –L –v –n ; sleep 1 ; done” je vois que les paquets du ping incrémente le total de paquets des paires de règles INPUT et OUTPUT spécifique a ICMP et définie en –j ACCEPT sur PC1 et PC2. On dirait donc que le paquet passe malgré tout en ICMP normal (sans être encapsulé dans IPCOMP et compressé). Les totaux des paquets des politiques par défaut sur DROP pour INPUT, OUTPUT et FORWARD ne bougent pas pendant le ping. Je pense donc que ce n’est pas un problème de firewall.

–> tcpdump sur PC1 n’affiche pas le ICMP ECHO REPLY. Je pense donc que quelque part dans le noyau de PC1, le paquet est détruit. Mais où ? et surtout pourquoi ?

J’ai l’impression que soit il s’agit d’une variable de sysctl.conf a modifier, soit IPCOMP ne fonctionne pas en mode transport, soit le noyau interprète mal le flag ICP de IPComp. J’ai beaucoup cherché sur Internet, mais je ne trouve rien de bien intéressant à me mettre sous la dent.

Voilou voilou, je ne comprends pas et je ne sais plus où chercher. Si vous avez, des idées, des pistes, des conseils je suis preneur.

Merci d’avance,

nico

#2

Up

Personne n’a une idée ?

Je pense tenir une piste. Je refais un test entre 2 routeurs debian 4.0 avec IPsec en mode tunnel et IPComp mais ça ne va toujours pas… La config est des plus simple :

Ip publique de R1 : IP_R1
Ip publique de R2 : IP_R2
Network LAN 1 : 192.168.1.0/24
Network LAN 2 : 192.168.2.0/24

Voilà ce que je vois avec tcpdump sur R2 pendant que je ping R2 depuis R1 :

19:29:20.783823 IP IP_R1 > IP_R2: IP IP_R1 > IP_R2: ICMP echo request, id 35600, seq 508, length 64 (ipip-proto-4) 19:29:20.783907 IP IP_R1 > IP_R2: ICMP echo request, id 35600, seq 508, length 64 19:29:21.783753 IP IP_R1 > IP_R2: IP IP_R1 > IP_R2: ICMP echo request, id 35600, seq 509, length 64 (ipip-proto-4) 19:29:21.783753 IP IP_R1 > IP_R2: ICMP echo request, id 35600, seq 509, length 64

On constate bien que le paquet ip est encapsulé dans autre paquet ip : mode tunnel.

On constate que la pile TCP-IP de R2 détecte bien qu’il s’agit d’un paquet IPSec puisqu’elle extrait le paquet contenu dans le premier paquet et qu’elle le replace sur la pile TCP-IP sans son enveloppe IPSec.

On remarque que le contenu est intelligible : pas compression… Pourtant les SA et les politiques de sécurité des 2 routeurs imposent l’usage d’IPComp.

On constate qu’il n’y a pas d’entête IPComp, qu’il n’y a pas de SPI lisible dans le paquet. Ceci est intrigant car il n’y a aucune référence à IPSec. Seulement a une encapsulation ip sur ip.

On constate que R2 ne répond pas aux requêtes icmp echo request !!! Là est tout mon problème. R2 devrait répondre aux ping de R1.

Ma SAD a été configurée par :

[code]# SA pour aller de R1 vers R2
add IP_R1 IP_R2 ipcomp 25003 -m tunnel -C deflate ;

SA pour aller de R2 vers R1

add IP_R2 IP_R1 ipcomp 26003 -m tunnel -C deflate ;[/code]

En faisant un setkey –D pour afficher le contenu de la SAD de R2, je découvre avec étonnement que setkey m’a généré Deux SA sans prévenir :

R2:~# setkey -D IP_R1 IP_R2 ipcomp mode=tunnel spi=25003(0x000061ab) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 28 09:43:51 2007 current: Jul 30 19:39:22 2007 diff: 208531(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3 pid=6989 refcnt=0 IP_R1 IP_R2 unspec mode=tunnel spi=1053130331(0x3ec57e5b) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 28 09:43:51 2007 current: Jul 30 19:39:22 2007 diff: 208531(s) hard: 0(s) soft: 0(s) last: Jul 30 18:31:53 2007 hard: 0(s) soft: 0(s) current: 93660(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1115 hard: 0 soft: 0 sadb_seq=2 pid=6989 refcnt=0 IP_R2 IP_R1 ipcomp mode=tunnel spi=26003(0x00006593) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 28 09:43:51 2007 current: Jul 30 19:39:22 2007 diff: 208531(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=6989 refcnt=0 IP_R2 IP_R1 unspec mode=tunnel spi=1053130332(0x3ec57e5c) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 28 09:43:51 2007 current: Jul 30 19:39:22 2007 diff: 208531(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=6989 refcnt=0

Il s’agit des SA ayant les SPI 1053130331 et 1053130332. Question intermédiaire : Pourquoi ?

En regardant sur R1, j’ai également 2 SA générées automatiquement avec des SPI différents. Ca ne saurait évidement pas marcher si ce sont ces SA là qui sont sélectionnées par IPSec…

Par ailleurs, on constate que les SA générées automatiquement n’exploitent aucun protocole d’IPSec : AH, ESP ou IPComp. En gros ce sont des SA qui ne servent à rien puisqu’elle ne font rien.

J’ai tendance a penser que le noyau utilise ces SA là au lieu d’utiliser mes SA IPComp. Pourtant les règles de la SPD sont formelles et requièrent l’usage de IPComp ou la destruction du paquet.

Voici pour exemple le contenu de la SPD de R2 :

R2:~# setkey -DP IP_R1[any] IP_R2[any] any in ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: Jul 30 19:42:07 2007 lifetime: 0(s) validtime: 0(s) spid=744 seq=11 pid=7058 refcnt=2 192.168.1.0/24[any] 192.168.2.0/24[any] any in ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=768 seq=10 pid=7058 refcnt=1 192.168.1.0/24[any] IP_R2[any] any in ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=792 seq=9 pid=7058 refcnt=1 IP_R1[any] 192.168.2.0/24[any] any in ipsec ipcomp/tunnel/IP_R2-IP_R1/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=824 seq=8 pid=7058 refcnt=1 IP_R2[any] IP_R1[any] any out ipsec ipcomp/tunnel/IP_R2-IP_R1/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=761 seq=7 pid=7058 refcnt=1 192.168.2.0/24[any] 192.168.1.0/24[any] any out ipsec ipcomp/tunnel/IP_R2-IP_R1/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=785 seq=6 pid=7058 refcnt=1 IP_R2[any] 192.168.1.0/24[any] any out ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=809 seq=5 pid=7058 refcnt=1 192.168.2.0/24[any] IP_R1[any] any out ipsec ipcomp/tunnel/IP_R2-IP_R1/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=817 seq=4 pid=7058 refcnt=1 IP_R1[any] IP_R2[any] any fwd ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=754 seq=3 pid=7058 refcnt=1 192.168.1.0/24[any] 192.168.2.0/24[any] any fwd ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=778 seq=2 pid=7058 refcnt=1 192.168.1.0/24[any] IP_R2[any] any fwd ipsec ipcomp/tunnel/IP_R1-IP_R2/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=802 seq=1 pid=7058 refcnt=1 IP_R1[any] 192.168.2.0/24[any] any fwd ipsec ipcomp/tunnel/IP_R2-IP_R1/require created: Jul 28 09:43:51 2007 lastused: lifetime: 0(s) validtime: 0(s) spid=834 seq=0 pid=7058 refcnt=1

Je n’arrive vraiment pas à comprendre ce comportement de setkey.

Merci d’avance pour vos idées.

Nico

#3

Non désolé, j’ai pas encore eu le temps de tester Ipsec. Demande aux gouroux de la liste netfilter, il devraient pouvoir te renseigner.