[Openswan Users]

[Joern Bredereck]

On Fri, 20 Jan 2006, Paul Wouters wrote:

>>>> Pinging from subnet 192.168.170.0 to subnet 192.168.27.0 I can see an
>>>> echo request with tcpdump on the router:
>>>>
>>>> 03:44:40.393518 192.168.170.99 > 192.168.27.1: icmp: echo request
>>>> 03:44:40.393582 192.168.170.99 > 192.168.27.1: icmp: echo request
>
> this is tcpdump on an ipsec device?

Yes, this is tcpdump on ipsec1.

ipsec1 connects the following subnets to the router:

firegate:~# ipsec look |grep ipsec1
ipsec1->eth1 mtu=16260(1443)->1500
10.10.94.0      213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
10.10.98.0      213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
172.16.0.0      213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
192.168.170.0   213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
192.168.200.0   213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
192.168.27.0    213.30.205.3    255.255.255.0   UG        0 0          0 
ipsec1
213.30.205.0    0.0.0.0         255.255.255.0   U         0 0          0 
ipsec1


It should be possible, to route traffic between each of those subnets. For 
instance, it should be possible to ping a host within the 192.168.27.0-network 
from a host in the 192.168.170.0-network.

This doesn't work. tcpdump on the central router shows the incoming echo 
request from thhe 192.168.170.0-network but according to tcpdump on the router 
of the 192.168.27.0-network this echo request is not being forwarded through 
the corresponding tunnel.

>> this should be the right policy:
>>
>> 52         192.168.0.0/16     -> 192.168.27.0/24    => > tun0x9474 at 194.231.29.121
>>
>> And this tunnel works like a charme, when the traffic comes from an
>> ipsec0-tunnel:
>>
>> 03:58:41.549279 192.168.2.98 > 192.168.27.1: icmp: echo request
>> 03:58:41.619835 192.168.27.1 > 192.168.2.98: icmp: echo reply

and as you can see the tunnel itself is working, because otherwise it wouldn't 
be possible to ping 192.168.27.1 from 192.168.2.98.

The difference between 192.168.2.0 and 192.168.170 is the following: 
192.168.2.0 is connected to the central router on ipsec0 while on the other 
hand 192.168.170.0 is connected via ipsec1. I can't see a reason why this 
should make a diffrence. Can you?

>>> I am not sure if I understand your problem or situation entirely though.
>
> Okay. I think i need some ascii art or digram, I just do not understand
> what you are trying to do, whether it had worked and broke, or whether it
> ever worked at all, or whether what you want is possible at all.


I'm not good in ascii art, but I will try:


The following works fine:

firegate is the central frees/wan router:
moody is the ipsec-router of the 192.168.2.0/24 net
leo is the ipsec-router of the 192.168.27.0/24 net



 			"firegate"
 			/	\
 		ipsec0		ipsec1
 		|		|
 		eth0		eth1
 		|		|
----------------------------------------------------------------
 		MPLS	/	INTERNET
----------------------------------------------------------------
 		|		|
 		eth0		eth0
 		|		|
 		ipsec0		ipsec0
 		|		|
 		"moody"		"leo"
 		|		|
  eth1 (192.168.2.0/24)		eth1 (192.168.27.0/24)


Every host in the 192.168.2.0/24-network can reach any host in the 
192.168.27.0/24-network and vice versa. Nothing wrong here.


The following doesn't work:

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.


Currently my tests brought the following 4 facts on the surface:

1. All networks tunneled via ipsec1 on firegate cannot ping each other.

2. All networks tunneled via ipsec1 can ping every network tunneld via ipsec0

3. All networks tunneled via ipsec0 can ping each other.

4. ICMP-echo-requests come in via ipsec1 but are not being forwarded to the 
destination network via ipsec1.


Looks like the ip forwarding on firegate is broken for ipsec1 internal 
traffic. But why? How can I fix this?

Thanks,

Joern