[Openswan Users]

[Paul Wouters]

On Fri, 20 Jan 2006, Joern Bredereck wrote:

> I would be glad, if someone could help me with the following problem
> (sorry, for my poor English, btw).
>
> A Linux router (Debian Linux with 2.4 kernel and FreeS/WAN2.x) connects
> several IPSec tunnels on 2 physical interfaces (eth0,eth1) from several
> peers (other linux router or hardware routers such as Draytek Vigor).

Note: We ofcourse recommend upgrading to openswan, but....

> The routing between subnets, which are connected through ipsec0 and
> subnets which are connected through ipsec1 works without any problems.
>
> What doesn't work is the routing between subnets, which are only
> connected through ipsec1 for in- and outbound traffic

You are aware you cannot just add routes to go over an ipsec interface
using route add -net, and that you have to build a new tunnel for those
routes instead?

> firegate:~# ip route show
> 213.xxx.xxx.64/28 via 192.168.153.1 dev ipsec0
> 192.168.5.0/24 via 192.168.153.1 dev ipsec0
> 192.168.151.0/24 via 192.168.153.1 dev eth0
> 172.16.0.0/24 via 213.xxx.xxx.3 dev ipsec1
> 10.10.98.0/24 via 213.xxx.xxx.3 dev ipsec1
> 192.168.170.0/24 via 213.xxx.xxx.3 dev ipsec1
> 192.168.154.0/24 via 192.168.153.1 dev eth0
> 192.168.200.0/24 via 213.xxx.xxx.3 dev ipsec1
> 10.10.94.0/24 via 213.xxx.xxx.3 dev ipsec1
> 192.168.153.0/24 dev eth0  proto kernel  scope link  src 192.168.153.99
> 192.168.153.0/24 dev ipsec0  proto kernel  scope link  src 192.168.153.99
> 192.168.152.0/24 via 192.168.153.1 dev eth0
> 213.xxx.xxx.0/24 dev eth1  proto kernel  scope link  src 213.xxx.xxx.23
> 213.30.205.0/24 dev ipsec1  proto kernel  scope link  src 213.xxx.xxx.23
> 192.168.27.0/24 via 213.xxx.xxx.3 dev ipsec1
> 192.168.0.0/16 via 192.168.153.1 dev ipsec0
> 172.16.0.0/12 via 192.168.153.1 dev eth0
> 10.0.0.0/8 via 192.168.153.1 dev eth0
> default via 213.xxx.xxx.3 dev eth1

What does 'ipesc eroute' shows? Are there entries there for the "broken"
routes?

> 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

Looks like there is just no policy for those routes defined, and they go
out cleartext.

I am not sure if I understand your problem or situation entirely though.

Paul