Hello, My name is Fermín Galán and I'm currently working with IPSec tunnels. Recently, I was setting a IPSec tunnelling sample scenario (maybe the simplest one :), where I observed some strange behaviour that I like to describe in the list, just in the case somebody knows what can be the cause, please. The scenario involves four hosts configured in the following way: C1-(NET1)-R1-(BONE)-R2-(NET2)-C2 NET1: 10.70.1.0/24 BONE: 10.1.1.0/24 NET2: 10.70.3.0/24 Facts: - C1 (10.70.1.2) is directly connected to R1 (10.70.1.1). - C2 (10.70.3.2) is directly connected to R2 (10.70.3.1) - R1 (10.1.1.123) is directly connected to R2 (10.1.1.106). - Forwarding is enabled in R1 and R2 (I mean, 'echo 1 > /proc/sys/net/ipv4/ip_forward') - Route in C1: 10.70.3.0/24->10.70.1.1 (I mean, 'route add -net 10.70.3.0/24 gw 10.70.1.1' was executed in C1) - Route in C2: 10.70.1.0/24->10.70.3.1 (I mean, 'route add -net 10.70.1.0/24 gw 10.70.3.1' was executed in C2) - Using Linux kernel 2.6.14.2 in all hosts. R1 and R2 use with native IPSec support, ipsec-tool version 0.5.2, racoon version 0.5.2. - A IPSec tunnel is configured R1-R2. Configuration for setkey in R1: #!/usr/sbin/setkey -f flush; spdflush; spdadd 10.70.1.0/24 10.70.3.0/24 any -P out ipsec esp/tunnel/10.1.1.123-10.1.1.106/require; spdadd 10.70.3.0/24 10.70.1.0/24 any -P in ipsec esp/tunnel/10.1.1.106-10.1.1.123/require; Configuration for setkey in R2. #!/usr/sbin/setkey -f flush; spdflush; spdadd 10.70.1.0/24 10.70.3.0/24 any -P in ipsec esp/tunnel/10.1.1.123-10.1.1.106/require; spdadd 10.70.3.0/24 10.70.1.0/24 any -P out ipsec esp/tunnel/10.1.1.106-10.1.1.123/require; - Using racoon for IKE negotation based on automatic keying with pre-shared secrets. The test I performed in this scenario consists pinging from C1 to C2 (I mean, 'ping 10.70.3.2' executed in C1). When I do so, racoon negociates the SAs for the tunnel, but the ping doesn't work end to end. I've checked with Ethereal that ICMP request goes C1 to R1, R1 sent a packet with ESP payload and the this packets is received by R2. However, R2 doesn't deencapsulate it and forward to C2. The strange fact is that if I establish a route in R1 to reach NET2 and other in R2 to reach NET1 (I mean, executing 'route add -net 10.70.3.0/24 gw 10.1.1.106' in R1 and 'route add -net 10.70.1.0/24 gw 10.1.1.123' in R2) the ping works perfectly! Therefore, it seems that each peer of the tunnel needs to know the routes "behind" the other peer (using that peer as gateway), not for encapsulate-and-forward (note that R1 encapsulates and forward to R2 properly) but for deencapsulate-and-forward. I found this behaviour a bit anoying, because the tunnel definition contains all the routing information (specifying in the setkey configuration the source-dest maching of the packets that will be pushed into the tunnel). Why then R2 needs a route (in the kernel route table) to 10.70.1.0/24 when de-encapsulates a packet comming from that network? Maybe my setkey configuration is wrong, my reasoning is wrong or I'm missing something... Please, any help/futher test ideas/comments is really welcome in order to understand how tunnels are actually working. Thanks in advance! :) Best regards, -------------------- Fermín Galán Márquez CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia, Av. del Canal Olímpic s/n, 08860 Castelldefels, Spain Room 1.02 Tel : +34 93 645 29 12 Fax : +34 93 645 29 01 Email address: fermin.galan@xxxxxxx _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
