Re: 26sec+forwarding, bug or PEBKAC?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux