[Openswan Users] One way tunnel

[lewis shobbrook]

Hi Paul/viewers,

I've done a little more testing/searching...


> >
> > "destination net unreachable" means the tunnel is not up, and the
> > subnet=
> > is not reacahble. To get better logging in the openwrt, add to config
> > setup:
> >
> >         plutostderrlog=/tmp/pluto.log
> >
> > Then check the logs in /tmp/
>
>
> Not sure how the tunnel can not be up? If  I can connect through from one
> subnet to another on th other end then it must be up.
> Logs state IPSEC SA established at both ends.  Routes are also modified to
> indicate the tunnel is up.  On the wrt the ipsec0 interface clocks rx & tx
> packets...
>

Traces from the Debian sub-net end is not routing packets, this must be a
routing issue.
Packets originating on "the unsuccessful" subnet end are not going where
they should.
For all other tunnels, when you trace from one subnet through the VPN to the
subnet on the other side, you always get response from the local gateway, a
row of time-outs *** & then complete at the destination.
In this instance, I see the above for traces from the subnet that is
"working"  (has full connectivity to the VPN'd subnet on the other side"),
but from the "bad" end the packets escape out with replies coming from the
local gateway, but  additionally the nexthop (the shdsl router), and then we
see the destination net unreachable from the hop after that.

> I'm wondering if it might have something to do with the protocol 4 bug in
> > > 2.6.17 that has been reported previously?
> >
> > > I've had to modify iptables on this box to accomodate the IP in IP
> > > protocol bug.
> >
> > I have no idea what this bug is. Can you provide a link to information?
>
>
> I can't seem to re-find any posts, but from memory it was a netfilter
> connection tracking issue with ipsec.
> Basically when upgrading from earlier 2.6 kernels,  you'd start finding
> protocol 4 packets in your iptables logs.
> I'll do a bit more digging and let you know what I can find on it.
>
Here's some entries concerning the netfilter issue, there were others that I
can't seem to find still that traced to a couple of accepted bugs, with one
of the id's eventually being canned as a duplicate of the other...

http://marc.theaimsgroup.com/?l=netfilter-devel&m=115395673408037&w=2
http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2
http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023420.html
http://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025145.html

I am seeing the same problem here, unless protocol 4 is allowed to and fro
the VPN endpoints we get no fun at the "good" wrt end of the tunnel.
Regardless of whether we allow -p 4 out form the "BAD" end or not makes no
difference, nothing is logged as blocked/dropped, and the "wrong" route
persists  with the through VPN traces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070306/4f54bd9e/attachment.html