Hi Paul/viewers,<br><br>I've done a little more testing/searching...<br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>"destination net unreachable" means the tunnel is not up, and the subnet=
<br>is not reacahble. To get better logging in the openwrt, add to config setup:<br><br> plutostderrlog=/tmp/pluto.log<br><br>Then check the logs in /tmp/</blockquote></span><div><br>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.
<br>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...</div></div></blockquote><div><br>Traces from the Debian sub-net end is not routing packets, this must be a routing issue.
<br>Packets originating on "the unsuccessful" subnet end are not going where they should. <br>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.
<br>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.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I'm wondering if it might have something to do with the protocol 4 bug in<br>> 2.6.17 that has been reported previously?
<br><br>> I've had to modify iptables on this box to accomodate the IP in IP<br>> protocol bug.<br><br>I have no idea what this bug is. Can you provide a link to information?</blockquote></span><div><br>I can't seem to re-find any posts, but from memory it was a netfilter connection tracking issue with ipsec.
<br>Basically when upgrading from earlier 2.6 kernels, you'd start finding protocol 4 packets in your iptables logs. <br>I'll do a bit more digging and let you know what<span style="font-style: italic;"> </span>
I can find on it.
</div></div></blockquote><div>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...
<br><br><a href="http://marc.theaimsgroup.com/?l=netfilter-devel&m=115395673408037&w=2">http://marc.theaimsgroup.com/?l=netfilter-devel&m=115395673408037&w=2</a><br><a href="http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2">
http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2</a><br><a href="http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023420.html">http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023420.html
</a><br><a href="http://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025145.html">http://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025145.html</a><br><br>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.
<br><br><br><br> <br></div></div>