[Openswan Users]

[Paul Wouters]

On Fri, 20 Jan 2006, Joern Bredereck wrote:

> Yes, of course. And the tunnel through ipsec1 work fine, when the traffic for
> those tunnels come from ipsec0. If I had no working tunnels on ipsec1 then I
> would have a real problem. :-)

I still don't understand your problem and sitaution

> > > 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?
>
> firegate:~# ipsec eroute
> 4715       0.0.0.0/0          -> 213.30.233.64/28   => > tun0x95b3 at 192.168.151.65
> 0          10.0.0.0/8         -> 192.168.27.0/24    => > tun0x9475 at 194.231.29.121
> 2939       10.10.0.0/16       -> 192.168.5.0/24     => > tun0x9447 at 192.168.151.97
> 0          10.11.1.0/24       -> 192.168.0.0/16     => > tun0x944d at 192.168.151.97
> 0          172.16.0.0/24      -> 192.168.0.0/16     => > tun0x9425 at 192.168.151.97
> 0          192.168.0.0/16     -> 172.16.0.0/24      => > tun0x9485 at 217.146.142.98
> 52         192.168.0.0/16     -> 192.168.27.0/24    => > tun0x9474 at 194.231.29.121
> 7          192.168.0.0/16     -> 192.168.170.0/24   => tun0x9659 at 84.56.238.219
> 0          192.168.0.0/16     -> 192.168.200.0/24   => > tun0x94a9 at 217.146.142.98
> 0          192.168.5.0/24     -> 10.10.94.0/24      => > tun0x962b at 194.231.29.120
> 0          192.168.5.0/24     -> 10.10.98.0/24      => > tun0x9657 at 194.231.29.119
> 9          192.168.27.0/24    -> 192.168.0.0/16     => > tun0x9642 at 192.168.151.97
> 1866       192.168.170.0/24   -> 192.168.0.0/16     => > tun0x9507 at 192.168.151.97
> 0          192.168.200.0/24   -> 192.168.0.0/16     => > tun0x948b at 192.168.151.97

> > > 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?

> 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
>
> > 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.

Paul