<div id="mb_0">
<div>Hi all,</div>
<div>&nbsp;</div>
<div>I&#39;ve set-up a tunnel between an openwrt White Russian 0.9 release and debian sid with openswan 2.4.6 with a 2.6.17 kernel.</div>
<div>&nbsp;</div>
<div>First digression to note is that I have had this combination working previously prior to WR 0.9.</div>
<div>&nbsp;</div>
<div>The tunnel works from the wrt end, through put is perfectly stable.&nbsp; </div>
<div>from the debian end I am unable to ping through the tunnel with errors ...reply from X.X.X.X destination net unreachable.</div>
<div>x.x.x.x is the next hop to the DSL router connected to the debian box, i.e. gateway to gateway.</div>
<div>&nbsp;</div>
<div>This&nbsp;leads me to suspect that new&nbsp;traffic from the debian end is being forwarded unencrypted.</div>
<div>&nbsp;</div>
<div>Other tunnels on the Debian box are OK.</div>
<div>&nbsp;</div>
<div>&nbsp;Subnet A &lt;==&gt;DEB&lt;=&gt;SHDSL &lt;======================&gt; CABLE MODEM&lt;=&gt; WRT==&gt;Subnet B</div>
<div>&nbsp;</div>
<div>In brief subnet B can access subnet A, but subnet A cannot access B.</div>
<div>Nothing trapped in firewall logs.</div>
<div>&nbsp;</div>
<div>The route table is correct... Although it should be noted that&nbsp;&nbsp;tunnels look like they should.</div>
<div>&nbsp;</div>
<div>Other thing to note is that&nbsp; traceroutes to and from the wrt to the debian ends indicate&nbsp;different IP for the nexthop&nbsp;on the wrt side.</div>
<div>When using the alternate&nbsp;nexthop address from the debian end in both conf files, the tunnel succeeds, but automatic addition of the associated route fails at the wrt end. </div>
<div>Creating the route manually at the wrt end, results in successful throughput to the B subnet<font style="BACKGROUND-COLOR: #ffffff">&nbsp;(wrt) to A Subnet (deb)</font>, but alas nothing from the A end to the B.</div>
<div>&nbsp;</div>
<div>Has anyone ever seen such an anomoly?</div>
<div>&nbsp;</div>
<div>I&#39;m wondering if it might have something to do with the protocol 4 bug in 2.6.17 that has been reported previously?</div>
<div>&nbsp;</div>
<div>I&#39;ve had to modify iptables on this box to accomodate the IP in IP protocol&nbsp;bug.</div>
<div>&nbsp;</div>
<div>Running out of ideas, anyone have any suggestions?</div>
<div>&nbsp;</div>
<div>Lew</div></div>