[Openswan Users] Problem of routing under openswan

[Dominique Blas]

Hi,

I have the same problem with racoon so I've supposed it's a kernel related problem but it only appears
when using native IPSEC !

Here it is :
	kernel is 2.6.5 with native IPSEC inside.
I have several netvorks and 3 Ethernet interfaces.

	eth0 : 10.1.0.0/16 and a route towards 10.1.10.0/24, 10.1.11.0/24, etc
	eth1 : default and 10.1.1.0/24
	eth2 : 10.1.2.0/24

A tunnel is established through eth1 with subnet 10.2.0.0/16. Since on the opposite side of this tunnel there is another tunnel towards 10.3.0.0/16
I had an idea, a few years ago, to say that the first tunnel is established with subnet 10.0.0.0/8 (an no more with 10.2.0.0/16).
Why ? In order to see (to ping and reach the SNMP agent) every other machine from the headquarters.
And, of course, according to the longest match algorithm that worked ... with FreesWan 1.99.x

When I upgraded to kernel 2.6 (and racoon) I'd had liked to do the same thing : using 10.0.0.0/8 as subnet for the tunnel beginning
at the headquarters. The result ? Everything goes through the tunnel : the whole route 10.0.0.0/8 eats up everything and works against
the longest match algorithm !
Same behaviour with openswan 2.2.0dr1.
And, of course, if I applied the route manually (10.0.0.0/8 on eth1 without tunnel) the other routes continue to work perfectly.
There seems to have something related between the manner the ipsec kernel apply the route.
Normally, in kernel 2.6, routing policy and ipsec policy are unrelated. But, of course, here we can see that there is more than a self ignorance
and It's bad for me.

                                                                                         Headquarter
                                          10.2.0.0/16                            10.1.0.0/16
10.3.0.0/16  <----------------> ==+=== <---------------------> ======= -> 10.1.10.0/24, 10.1.11.0/24, etc
   Site A                                 Site B                                     Site H

With a route-only towards 10.2.0.0/16 as established with the tunnel, headquarter can only reach the site B not the site A.
With a 10.0.0.0/8 route forced onto the tunnel interface (ipsec0 in freeswan 1.x) headquarter can reach directly sites
B and A.

Any idea ?

db