public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Kernel 2.6.10 with IPSEC problems?
@ 2004-12-26 14:53 Joerg Platte
  2004-12-26 15:39 ` Patrick McHardy
  0 siblings, 1 reply; 4+ messages in thread
From: Joerg Platte @ 2004-12-26 14:53 UTC (permalink / raw)
  To: linux-kernel

Hi!

After an upgrade from 2.6.9 to 2.6.10 my IPSEC tunnel does not work as usual. 
My computer and the VPN-gateway can negotiate and build a tunnel and packets 
can use the tunnel. But then packets which must be routed get lost somewhere 
inside the kernel. tcpdump shows them first encrypted in ESP packets and then 
the unencrypted payload on the same interface. But they do not leave the 
kernel on the destination interface. Only packets with my computer as 
destination are processed. I did not change my IPSEC configuration and the 
kernel was configured using "make oldconfig".

Is there a problem in the routing layer somewhere inside the kernel or an 
internal change which requires a configuration change on my side? How can I 
determine, where and why the packets inside the kernel are thrown away?

To verify the problem I build a 2.6.10 kernel on the VPN gateway. And this 
kernel seems to have the same problem. Previously encrypted packets are not 
routed to th destination.

Downgrading to 2.6.9 solved the problem in both cases...

Regards,
Jörg

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel 2.6.10 with IPSEC problems?
  2004-12-26 14:53 Kernel 2.6.10 with IPSEC problems? Joerg Platte
@ 2004-12-26 15:39 ` Patrick McHardy
  2004-12-26 18:15   ` Joerg Platte
  0 siblings, 1 reply; 4+ messages in thread
From: Patrick McHardy @ 2004-12-26 15:39 UTC (permalink / raw)
  To: lists; +Cc: linux-kernel

Joerg Platte wrote:
> Hi!
> 
> After an upgrade from 2.6.9 to 2.6.10 my IPSEC tunnel does not work as usual. 
> My computer and the VPN-gateway can negotiate and build a tunnel and packets 
> can use the tunnel. But then packets which must be routed get lost somewhere 
> inside the kernel. tcpdump shows them first encrypted in ESP packets and then 
> the unencrypted payload on the same interface. But they do not leave the 
> kernel on the destination interface. Only packets with my computer as 
> destination are processed. I did not change my IPSEC configuration and the 
> kernel was configured using "make oldconfig".
> 
> Is there a problem in the routing layer somewhere inside the kernel or an 
> internal change which requires a configuration change on my side? How can I 
> determine, where and why the packets inside the kernel are thrown away?
> 
> To verify the problem I build a 2.6.10 kernel on the VPN gateway. And this 
> kernel seems to have the same problem. Previously encrypted packets are not 
> routed to th destination.
> 
> Downgrading to 2.6.9 solved the problem in both cases...

Since Linux 2.6.10-rcX. packets from a tunnel-mode SA are dropped if
no policy exists. You most likely only have an input policy, but no
forward policy. If you use setkey to configure your policies,
duplicate the input policy and replace "-P in" with "-P fwd". If you
let racoon generate the policy you need to upgrade to the latest
version. pluto should already get it right.

Regards
Patrick



> 
> Regards,
> Jörg
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel 2.6.10 with IPSEC problems?
  2004-12-26 15:39 ` Patrick McHardy
@ 2004-12-26 18:15   ` Joerg Platte
  2004-12-26 18:42     ` Patrick McHardy
  0 siblings, 1 reply; 4+ messages in thread
From: Joerg Platte @ 2004-12-26 18:15 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: linux-kernel

Am Sonntag, 26. Dezember 2004 16:39 schrieb Patrick McHardy:
Hi!

> Since Linux 2.6.10-rcX. packets from a tunnel-mode SA are dropped if
> no policy exists. You most likely only have an input policy, but no
> forward policy. If you use setkey to configure your policies,
> duplicate the input policy and replace "-P in" with "-P fwd". If you
> let racoon generate the policy you need to upgrade to the latest
> version. pluto should already get it right.

Thanks for the fast reply. It solved my problem. Is this change somewhere 
documented? Where can I get this kind of information, if I have problems in 
the future with the kernel IPSEC implementation?

Regards,
Jörg

-- 
Hi! I'm a .signature virus! Copy me into your signature to help me spread!.-.
PGP Key: send mail with subject 'SEND PGP-KEY' PGP Key-ID: FD 4E 21 1D    oo|
PGP Fingerprint: 388A872AFC5649D3 BCEC65778BE0C605                  _ // /`'\
I am Ohm of Borg. Resistance is voltage divided by current.         \X/ (\_;/)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel 2.6.10 with IPSEC problems?
  2004-12-26 18:15   ` Joerg Platte
@ 2004-12-26 18:42     ` Patrick McHardy
  0 siblings, 0 replies; 4+ messages in thread
From: Patrick McHardy @ 2004-12-26 18:42 UTC (permalink / raw)
  To: lists; +Cc: linux-kernel

Joerg Platte wrote:
> Thanks for the fast reply. It solved my problem. Is this change somewhere 
> documented? Where can I get this kind of information, if I have problems in 
> the future with the kernel IPSEC implementation?

The change was discussed on netdev before it went in. The
old behaviour was a security problem, so this change, which
breaks tunnel setups without forward policies, had to be
made. This will hopefully not happen again, but if you have
problems with IPsec and suspect a kernel bug, write to
netdev@oss.sgi.com.

Regards
Patrick

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-12-26 18:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-26 14:53 Kernel 2.6.10 with IPSEC problems? Joerg Platte
2004-12-26 15:39 ` Patrick McHardy
2004-12-26 18:15   ` Joerg Platte
2004-12-26 18:42     ` Patrick McHardy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox