[Openswan Users]

[Joern Bredereck]

On Fri, 20 Jan 2006, Paul Wouters wrote:

>> firegate is the central frees/wan router:
>> kah is the ipsec-router of the 192.168.200.0/24 net
>> leo is the ipsec-router of the 192.168.27.0/24 net
>>
>>
>>
>> 			"firegate"
>> 			/	\
>> 		ipsec1		ipsec1
>> 		|		|
>> 		eth1		eth1
>> 		|		|
>> ----------------------------------------------------------------
>> 		INTERNET	INTERNET
>> ----------------------------------------------------------------
>> 		|		|
>> 		eth2		eth0
>> 		|		|
>> 		ipsec0		ipsec0
>> 		|		|
>> 		"kah"		"leo"
>> 		|		|
>>  eth1 (192.168.200.0/24)	eth1 (192.168.27.0/24)
>>
>>
>> Hosts of the 192.168.200.0/24-network cannot reach ony hosts on the
>> 192.168.27.0/24-network and vice versa.
>>
>> The same problem with other tunnels which are connected via ipsec1.
>
> And you do have:
> a) an ipsec tunnel on "kah" to "firegate" for 192.168.200.0/24 <===> 192.168.0.0/16 (or 192.168.27.0/24)
> b) an ipsec tunnel on "leo" to "firegate" for 192.168.27.0/24 <===> 192.168.0.0/16 (or 192.168.200.0/24)

yes, otherwise I couldn't ping from 192.168.200.0 to all subnets on ipsec0 of 
firegate.

> c) ip_forwarding enabled and no firewalling and rp_filter disabled on firegate?

yes. (You read my first mail?)

> d) if firegate is a 2.6 kernel, that it is NOT sending/soliciting icmp redirect packets since it
>   is receiveing / sending the packets over the same interface

it's a 2.4 kernel. What would be the neccessary /proc-entry?

> You should verify:
>
> a) kah is sending encrypted packet to firegate for the leo network (tcpdump on eth2)

it is.

> b) firegate is decrypting these packets (tcpdump on ipsec1)

it is.

> c) firegate is re-encrypting these packets (tcpdump on ipsec1)

it is not.

> d) firegate is sending encrypted packets (tcpdump on eth1)

it is not because of c

> e) leo is receiving encrypted packets (tcpdump on eth0)

it is not because of c+d

> f) leo is decrypting these packets (tcpdump on ipsec0)

it is not because of c+d+e

> g) leo is forwarding these packets (tcpdump on eth1)

it is not because of c+d+e+f

I mentioned in my very first mail to this list, that packets are being 
received on firegate but that they are not being forwarded to the other tunnel 
on ipsec1. But because I don't know how to find out WHY I was posting my mail 
to this list.

So, the question is: How can I find out, why FreeS/Wan does not encrypt 
packets which arrived through ipsec1 for a tunnel going out on ipsec1? How to 
debug this behavior?

>> 4. ICMP-echo-requests come in via ipsec1 but are not being forwarded to the
>> destination network via ipsec1.
>
> This could be rp_filter or 2.6's bogus redirect packets.

rp_filter ist turned off for all interfaces and this is a 2.4 kernel.

firegate:~# for i in `ls /proc/sys/net/ipv4/conf`; do echo "$i: `cat
/proc/sys/net/ipv4/conf/$i/rp_filter`"; done
all: 0
default: 0
eth0: 0
eth1: 0
ipsec0: 0
ipsec1: 0
lo: 0

firegate:~# uname -a
Linux firegate 2.4.28 #4 Thu Mar 31 13:38:53 CEST 2005 i686 unknown




Joern