Hi Paul,<br>Thanks for the quick response.<br><br><div><span class="gmail_quote">On 3/5/07, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 5 Mar 2007, lewis shobbrook wrote:<br><br>> I've set-up a tunnel between an openwrt White Russian 0.9 release and debian<br>> sid with openswan 2.4.6 with a 2.6.17 kernel.<br>><br>> First digression to note is that I have had this combination working
<br>> previously prior to WR 0.9.<br>><br>> The tunnel works from the wrt end, through put is perfectly stable.<br>> from the debian end I am unable to ping through the tunnel with errors<br>> ...reply from
X.X.X.X destination net unreachable.<br>> x.x.x.x is the next hop to the DSL router connected to the debian box, i.e.<br>> gateway to gateway.<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><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...<br><br>Doesn't matter which side the tunnel is upped from.
<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;">> Other thing to note is that traceroutes to and from the wrt to the debian
<br>> ends indicate different IP for the nexthop on the wrt side.<br><br>Thats bad Point-to-point routing of ISPs assigning our dhcp paramters which<br>are theoretically incorrect.<br><br>Do a route -n on the openwrt. if you see two routes to reach your gateway,
<br>with one pointing into the ipsec device, delete the one pointing into the<br>ipsec device.<br><br>> 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><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.
<br> </div>Cheers & thanks,<br><br>Lew<br></div>