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@cttc.es
