[Openswan Users] Fwd: Fwd: Tunnel working "one way only"

[Antonio Ávila]

Ok, I forgot to tell you something, I have tried that configuration before
(same files)
between another two boxes (pcs) and worked quite well, but since I put the
config
file into the openwrt router, I haven't seen the tunnel full working. The
thing that
really intrigates me is that the tunnel work one-way only. I mean, Could it
be
a missing iptable rule? Has kernel 2.6.19 any known bug with ipsec? Maybe a
route
problem?

> conn tunnconn
> >       type=tunnel
> >       left=192.168.2.2
> >       leftnexthop=192.168.2.1
> >       right= 192.168.2.1
>
> Try type=%direct


Thank Paul, I tried but when I change the configuration, now I can't even seen
the negotiation of the tunnel :(

The situation when using two IPsec machines in the same subnet is
> fundamentally
> different from having two IPsec machines with a box (or a whole internet)
> in
> the middle. If you are doing this for testing a real world deployment,
> change
> the network and add a machine in the middle that's just a router.
>
> Paul


Yes, you are right, this is not a good test for real situations, but the
only thing I
want to test now is that openswan is
working well in the openwrt device. Once I see it
working I will try different scenarios.

I have also tried some workarounds about the MTU size and they did not work
for me.

I have another question also, sometimes (but not always) when I "turn on"
the tunnel
I have some strange routes added, I mean "things like those":

### See the table with a monospace font...
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.12.27.33 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.228.79.201 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
198.41.0.4 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
193.0.14.129 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.5.5.241 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
128.8.10.90 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.112.36.4 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.203.230.10 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.58.128.30 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
128.63.2.53 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.36.148.17 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
198.32.64.12 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.33.4.12 192.168.2.2 255.255.255.255 UGH 0 0 0 ipsec0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.0
0.0.0.0 192.168.2.2 128.0.0.0 UG 0 0 0 ipsec0
128.0.0.0 192.168.2.2 128.0.0.0 UG 0 0 0 ipsec0
0.0.0.0 192.168.2.2 0.0.0.0 UG 0 0 0 eth0.1

Well this happened me before and the tunnel was working perfectly, but I
don't
know what the hell ipsec put some of this routes into the table.

Any help would be appreciated.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070403/24d2e31e/attachment-0001.html