[Openswan Users] Problem of routing under openswan

Dominique Blas ml at blas.net
Wed Jun 30 02:30:24 CEST 2004


Le mardi 29 Juin 2004 04:23, Herbert Xu a écrit :
> Paul Wouters <paul at xelerance.com> wrote:
> > 
> >> 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.
> > 
> > This is a known limitation of the current 2.6 native ipsec stack. Use KLIPS
> > instead. KLIPS for openswan is planned for version 2.3. You can try Nate's
> 
> This is not a limitation at all.  It's a feature.
Yep, I reread (a new time) different docs on Kernel 2.6.

In fact, I had understood this way of working the first time I came to 2.6.
But then, as I didn't find the way
to write such a null policy in racoon (by the time I was involved) I only kept in mind
a buggy behaviour of kernel 2.6 about the longest match algorithm.

Well, Herbert, I tried this config (replacing 192.168.4.[12] by 127.0.0.[12] no matter)
and it works now.

But what I would insist on is that I switched to openswan (instead of racoon) (and openswan using native IPSEC) because :
	- I was using freeswan 1.x in kernel 2.4 (a bit of conservatism, uh) ;

	- pluto ssems not to have a memory leak as racoon has (even the latest version keeps on leaking memory compelling me
		to keep an eye on racoon's memory and kill it if it goes above 6 MB then restarts it) ;

	- pluto has now DPD which didn't exist in freeswan 1.X and doesn't exist in racoon either compelling me to watch permanently 
		the  link (doing pings) and restart pluto if the opposite side vanishes ;

	- openswan eats up much less memory (about 2MB less) than racoon and on a 64 MB machine that is very important ;

	- last but not least : pluto now is able to set kernel IPSEC policies of its own cancelling the needs of a previous setkey command
		and configuration.


> 
> If you want to make an exception for a subrange, you should setup
> a pass policy in Openswan/Racoon.  For example, 
> 
> conn workaround
> 	left=192.168.4.1
> 	leftsubnet=10.2.0.0/16
> 	right=192.168.4.2
> 	rightsubnet=10.3.0.0/16
> 	type=passthrough
> 	auto=add

BTW, do you have the translation for such a policy in racoon syntax ?

Thanks to all again,

db


More information about the Users mailing list