26sec+forwarding, bug or PEBKAC?

26sec+forwarding, bug or PEBKAC?

[rsnel]

Hello list,

I hope this is the right list, as my problem appears to be about both
iptables and (native (as in: managed with setkey)) IPSec.

Short version: 

packets from ipsec tunnel seem to get lost before they enter the the 
FORWARD chain with kernel 2.6.11. There is no problem with 2.6.8-2-k6 
(Debian kernel with 26sec) and there is no problem with ipsec turned 
off.

Long version:

Two networks:

192.168.2.0/24 wired home network
192.168.3.0/30 wireless network

Three hosts

cube, router/firewall: eth1 192.168.2.2 wlan0 192.168.3.1 eth0 82.157.. 
eniac, workstation: eth0 192.168.2.1 
toppie, laptop: wlan0 192.168.3.2 

On 192.168.3.0/30 ipsec is used, relevant excerpt: ipsec.conf (cube):
spdflush;

spdadd 192.168.3.0/30 0.0.0.0/0 any -P in ipsec
        esp/tunnel/192.168.3.2-192.168.3.1/require;

spdadd 0.0.0.0/0 192.168.3.0/30 any -P out ipsec
        esp/tunnel/192.168.3.1-192.168.3.2/require;

the firewall on cube is configured as follows (only
for testing, the usual config is more complicated but it
exhibits the same problem).

all the policies are 'ACCEPT'
and traffic from eth0 is DROPped at INPUT (and forwarding
is enabled at /proc/sys/net/ipv4/ip_forward).

cube and toppie can ping eachother, cube and eniac also. But eniac and 
toppie can't ping eachother.

For example:

eniac pings toppie: (REQ=echo request, RPL=echo reply and ESP=encryped 
packet) the log is aquired on cube by prepending a LOG target to all 
chains using a script much alike 
http://iptables-tutorial.frozentux.net/scripts/rc.test-iptables.txt 
and by removing information that I think isn't important, to make it 
fit on 80 cols

Eniac sends an echo-request.

REQ mangle PRE_R:IN=eth1 OUT= SRC=192.168.2.1 DST=192.168.3.2 LEN=84 
REQ nat    PRE_R:IN=eth1 OUT= SRC=192.168.2.1 DST=192.168.3.2 LEN=84 
REQ mangle FWD:IN=eth1 OUT=wlan0 SRC=192.168.2.1 DST=192.168.3.2 LEN=84 
REQ filter FWD:IN=eth1 OUT=wlan0 SRC=192.168.2.1 DST=192.168.3.2 LEN=84 

From here on the packet gets encrypted.

ESP mangle POST_R:IN= OUT=wlan0 SRC=192.168.3.1 DST=192.168.3.2 LEN=152 
ESP nat    POST_R:IN= OUT=wlan0 SRC=192.168.3.1 DST=192.168.3.2 LEN=152 

It leaves cube and toppie sends a reply.

ESP mangle PRE_R:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152 
ESP mangle INPUT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152
ESP filter INPUT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152

The packet gets decrypted.

RPL mangle PRERT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.2.1 LEN=84

After this the echo reply from toppie does not appear in the log; the 
packet does not enter the INPUT chain and it also does not enter the 
(expected) FORWARD chain.

This happens with linux-2.6.11 (vanilla). The ping works if IPSec is 
turned off (i.e. setkey -F -P on cube and toppie). And it also works 
in 2.4.27-2-k6 (a Debian kernel (which has 26sec patched in)). 

So, is it a bug, feature, or just misconfiguration? Can you reproduce?
I would appreciate any insight on this problem.

Thanks.

Greetings,

Rik.

Re: 26sec+forwarding, bug or PEBKAC?

[Allain Yoann]

On Tue, 31 Mar 2005 22:16:40, rsnel at cube.dyndns.org wrote
 
>Hello list,
> 
>I hope this is the right list, as my problem appears to be about both
>iptables and (native (as in: managed with setkey)) IPSec.
> 
>Short version: 
> 
>packets from ipsec tunnel seem to get lost before they enter the the 
>FORWARD chain with kernel 2.6.11. There is no problem with 2.6.8-2-k6 
>(Debian kernel with 26sec) and there is no problem with ipsec turned 
>off.
> 
>Long version:
> 
>Two networks:
> 
>192.168.2.0/24 wired home network
>192.168.3.0/30 wireless network
> 
>Three hosts
> 
>cube, router/firewall: eth1 192.168.2.2 wlan0 192.168.3.1 eth0 82.157..

>eniac, workstation: eth0 192.168.2.1 
>toppie, laptop: wlan0 192.168.3.2 
> 
>On 192.168.3.0/30 ipsec is used, relevant excerpt: ipsec.conf (cube):
>spdflush;
> 
>spdadd 192.168.3.0/30 0.0.0.0/0 any -P in ipsec
>        esp/tunnel/192.168.3.2-192.168.3.1/require;
> 
>spdadd 0.0.0.0/0 192.168.3.0/30 any -P out ipsec
>        esp/tunnel/192.168.3.1-192.168.3.2/require;
> 
>the firewall on cube is configured as follows (only
>for testing, the usual config is more complicated but it
>exhibits the same problem).
> 
>all the policies are 'ACCEPT'
>and traffic from eth0 is DROPped at INPUT (and forwarding
>is enabled at /proc/sys/net/ipv4/ip_forward).
> 
>cube and toppie can ping eachother, cube and eniac also. But eniac and 
>toppie can't ping eachother.
> 
>For example:
> 
>eniac pings toppie: (REQ=echo request, RPL=echo reply and ESP=encryped 
>packet) the log is aquired on cube by prepending a LOG target to all 
>chains using a script much alike 
>http://iptables-tutorial.frozentux.net/scripts/rc.test-iptables.txt 
>and by removing information that I think isn't important, to make it 
>fit on 80 cols
> 
>Eniac sends an echo-request.
> 
>REQ mangle PRE_R:IN=eth1 OUT= SRC=192.168.2.1 DST=192.168.3.2 LEN=84 
>REQ nat    PRE_R:IN=eth1 OUT= SRC=192.168.2.1 DST=192.168.3.2 LEN=84 
>REQ mangle FWD:IN=eth1 OUT=wlan0 SRC=192.168.2.1 DST=192.168.3.2 LEN=84

>REQ filter FWD:IN=eth1 OUT=wlan0 SRC=192.168.2.1 DST=192.168.3.2 LEN=84

> 
From here on the packet gets encrypted.
> 
>ESP mangle POST_R:IN= OUT=wlan0 SRC=192.168.3.1 DST=192.168.3.2 LEN=152

>ESP nat    POST_R:IN= OUT=wlan0 SRC=192.168.3.1 DST=192.168.3.2 LEN=152

> 
>It leaves cube and toppie sends a reply.
> 
>ESP mangle PRE_R:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152 
>ESP mangle INPUT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152
>ESP filter INPUT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.3.1 LEN=152
> 
>The packet gets decrypted.
> 
>RPL mangle PRERT:IN=wlan0 OUT= SRC=192.168.3.2 DST=192.168.2.1 LEN=84
> 
>After this the echo reply from toppie does not appear in the log; the 
>packet does not enter the INPUT chain and it also does not enter the 
>(expected) FORWARD chain.
> 
>This happens with linux-2.6.11 (vanilla). The ping works if IPSec is 
>turned off (i.e. setkey -F -P on cube and toppie). And it also works 
>in 2.4.27-2-k6 (a Debian kernel (which has 26sec patched in)). 
> 
>So, is it a bug, feature, or just misconfiguration? Can you reproduce?
>I would appreciate any insight on this problem.
> 
>Thanks.
> 
>Greetings,
> 
>Rik. 
 
Hello Rik,
 
I got the same problem, with the same kernel version. So I'm asking you
if you resolved it and if someone of the kernel has been awared of this
problem.
I've tried to debug it with an UML version but didn't succeed.
 
Greetz
 
Yoann

RE: 26sec+forwarding, bug or PEBKAC?

[Allain Yoann]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Allain Yoann
> Sent: mercredi 6 avril 2005 10:54
> To: netfilter@lists.netfilter.org
> Subject: Re: 26sec+forwarding, bug or PEBKAC?
> 
> On Tue, 31 Mar 2005 22:16:40, rsnel at cube.dyndns.org wrote
> 
> >Hello list,
> >
> >I hope this is the right list, as my problem appears to be about both
> >iptables and (native (as in: managed with setkey)) IPSec.
> >
> >Short version:
> >
> >packets from ipsec tunnel seem to get lost before they enter the the
> >FORWARD chain with kernel 2.6.11. There is no problem with 2.6.8-2-k6
> >(Debian kernel with 26sec) and there is no problem with ipsec turned
> >off.
> >

...

> >This happens with linux-2.6.11 (vanilla). The ping works if IPSec is
> >turned off (i.e. setkey -F -P on cube and toppie). And it also works
> >in 2.4.27-2-k6 (a Debian kernel (which has 26sec patched in)).
> >
> >So, is it a bug, feature, or just misconfiguration? Can you
reproduce?
> >I would appreciate any insight on this problem.
> >
> >Thanks.
> >
> >Greetings,
> >
> >Rik.
> 
> Hello Rik,
> 
> I got the same problem, with the same kernel version. So I'm asking
you
> if you resolved it and if someone of the kernel has been awared of
this
> problem.
> I've tried to debug it with an UML version but didn't succeed.
> 
> Greetz
> 
> Yoann

Hi again,

I solved the problem:
Since the kernel 2.6.10, we must set a "fwd" policy in the same way we
did for the "in" policy on each host-end of the tunnel.

I just found one reference on the web:
http://www.ipsec-howto.org/x277.html (one line in the middle)

I hope others newbies like me won't lose too much time on it...

Yoann

Re: 26sec+forwarding, bug or PEBKAC?

[rsnel]

Hi,

On Wed, Apr 06, 2005 at 02:36:10PM +0200, Allain Yoann wrote:
> > On Tue, 31 Mar 2005 22:16:40, rsnel at cube.dyndns.org wrote
> > >
> > >packets from ipsec tunnel seem to get lost before they enter the the
> > >FORWARD chain with kernel 2.6.11. There is no problem with 2.6.8-2-k6
> > >(Debian kernel with 26sec) and there is no problem with ipsec turned
> > >off.
> > > [...]
> > >So, is it a bug, feature, or just misconfiguration? Can you reproduce?
> > >I would appreciate any insight on this problem.
> 
> I solved the problem:
> Since the kernel 2.6.10, we must set a "fwd" policy in the same way we
> did for the "in" policy on each host-end of the tunnel.
> 
> I just found one reference on the web:
> http://www.ipsec-howto.org/x277.html (one line in the middle)
> 
> I hope others newbies like me won't lose too much time on it...

Many thanks Allain for your solution. (I didn't try it out yet, but I
expect it to work) And so problem turned out to be misconfiguration of a
new feature...

Greetings,

Rik.