Hi Paul/viewers,<br><br>I&#39;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>&quot;destination net unreachable&quot; 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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&nbsp; 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.&nbsp; Routes are also modified to indicate the tunnel is up.&nbsp; On the wrt the ipsec0 interface clocks rx &amp; 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 &quot;the unsuccessful&quot; subnet end  are not going where they should.&nbsp; <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 *** &amp; then complete at the destination.
<br>In this instance, I see the above for traces from the subnet that is &quot;working&quot;&nbsp; (has full connectivity to the VPN&#39;d subnet on the other side&quot;), but from the &quot;bad&quot; end the packets escape out with replies coming from the local gateway, but&nbsp; 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;">
&gt; I&#39;m wondering if it might have something to do with the protocol 4 bug in<br>&gt; 2.6.17 that has been reported previously?
<br><br>&gt; I&#39;ve had to modify iptables on this box to accomodate the IP in IP<br>&gt; 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&#39;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,&nbsp; you&#39;d start finding protocol 4 packets in your iptables logs. <br>I&#39;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&#39;s some entries concerning the netfilter issue, there were others that I can&#39;t seem to find still that traced to a couple of accepted bugs, with one of the id&#39;s eventually being canned as a duplicate of the other...
<br><br><a href="http://marc.theaimsgroup.com/?l=netfilter-devel&amp;m=115395673408037&amp;w=2">http://marc.theaimsgroup.com/?l=netfilter-devel&amp;m=115395673408037&amp;w=2</a><br><a href="http://marc.theaimsgroup.com/?l=netfilter-devel&amp;m=114010374229806&amp;w=2">
http://marc.theaimsgroup.com/?l=netfilter-devel&amp;m=114010374229806&amp;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 &quot;good&quot; wrt end of the tunnel.&nbsp; Regardless of whether we allow -p 4 out form the &quot;BAD&quot; end or not makes no difference, nothing is logged as blocked/dropped, and the &quot;wrong&quot; route persists&nbsp; with the through VPN traces.
<br><br><br><br>&nbsp;<br></div></div>