Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-13 Thread David S. Miller
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Jan 2006 22:51:09 +0100 > Great, here is a properly signed off patch without the extra > hunks. Yeah, I noticed that bug fix snuck in there last time :-) Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" i

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Patrick McHardy
David S. Miller wrote: From: Herbert Xu <[EMAIL PROTECTED]> Date: Fri, 13 Jan 2006 08:06:00 +1100 The only reason I mentioned doing it in userspace is that it gives us a little bit more flexibility since userspace can choose a different method to pick the source address. Note that userspace

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread David S. Miller
From: Herbert Xu <[EMAIL PROTECTED]> Date: Fri, 13 Jan 2006 08:06:00 +1100 > The only reason I mentioned doing it in userspace is that it gives us > a little bit more flexibility since userspace can choose a different > method to pick the source address. Note that userspace could override and do

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Herbert Xu
On Thu, Jan 12, 2006 at 01:35:35PM +0100, Patrick McHardy wrote: > > That shouldn't be the deciding reason. although its certainly true. > The advantage of doing this in the kernel is that it hopefully works > transparently with any keying daemon, but as the racoon patch shows, > its quite easy to

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Ingo Oeser
Hi Patrick, hi Herbert, To summarize the advantages of the in-kernel variant: - it behaves similiar to an specific tunnel - you fix it there for ALL IKE daemons - It works with future and current racoon variants so it can go away, when other blocking racoon bugs are fixed and current racoon

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Patrick McHardy
Ingo Oeser wrote: Patrick McHardy wrote: When moving around with my notebook I got annoyed by having to change the IPsec policies whenever I get a new address. This patch handles a tunnel source of 0.0.0.0 as special case and using routing to get the real source address for the acquire message.

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Ingo Oeser
Patrick McHardy wrote: > When moving around with my notebook I got annoyed by having > to change the IPsec policies whenever I get a new address. > This patch handles a tunnel source of 0.0.0.0 as special case > and using routing to get the real source address for the > acquire message. I've tested

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-12 Thread Patrick McHardy
Herbert Xu wrote: On Thu, Jan 12, 2006 at 07:06:45AM +0100, Patrick McHardy wrote: When moving around with my notebook I got annoyed by having to change the IPsec policies whenever I get a new address. This patch handles a tunnel source of 0.0.0.0 as special case and using routing to get the re

Re: [RFC]: IPsec tunnel wildcard addresses

2006-01-11 Thread Herbert Xu
On Thu, Jan 12, 2006 at 07:06:45AM +0100, Patrick McHardy wrote: > When moving around with my notebook I got annoyed by having > to change the IPsec policies whenever I get a new address. > This patch handles a tunnel source of 0.0.0.0 as special case > and using routing to get the real source addr

[RFC]: IPsec tunnel wildcard addresses

2006-01-11 Thread Patrick McHardy
When moving around with my notebook I got annoyed by having to change the IPsec policies whenever I get a new address. This patch handles a tunnel source of 0.0.0.0 as special case and using routing to get the real source address for the acquire message. I've tested with racoon and it works fine.