|
List Info
Thread: One way tunnel
|
|
| One way tunnel |
|
2007-03-04 21:03:23 |
|
Hi all,
I'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.
First digression to note is that I have had this combination working previously prior to WR 0.9.
The tunnel works from the wrt end, through put is perfectly stable.
from the debian end I am unable to ping through the tunnel with errors ...reply from X.X.X.X destination net unreachable.
x.x.x.x is the next hop to the DSL router connected to the debian box, i.e. gateway to gateway.
This leads me to suspect that new traffic from the debian end is being forwarded unencrypted.
;
Other tunnels on the Debian box are OK.
Subnet A <==>DEB<=>;SHDSL <======================> CABLE MODEM<=> WRT==>Subnet B
;
In brief subnet B can access subnet A, but subnet A cannot access B.
Nothing trapped in firewall logs.
The route table is correct... Although it should be noted that tunnels look like they should.
Other thing to note is that traceroutes to and from the wrt to the debian ends indicate different IP for the nexthop on the wrt side.
When using the alternate 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.
Creating the route manually at the wrt end, results in successful throughput to the B subnet (wrt) to A Subnet (deb), but alas nothing from the A end to the B.
Has anyone ever seen such an anomoly?
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.
Running out of ideas, anyone have any suggestions?
;
Lew
|
| Re: One way tunnel |
 
Netherlands |
2007-03-04 22:09:17 |
On Mon, 5 Mar 2007, lewis shobbrook wrote:
> I'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.
>
> First digression to note is that I have had this
combination working
> previously prior to WR 0.9.
>
> The tunnel works from the wrt end, through put is
perfectly stable.
> from the debian end I am unable to ping through the
tunnel with errors
> ...reply from X.X.X.X destination net unreachable.
> x.x.x.x is the next hop to the DSL router connected to
the debian box, i.e.
> gateway to gateway.
"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/
> Other thing to note is that traceroutes to and from
the wrt to the debian
> ends indicate different IP for the nexthop on the wrt
side.
Thats bad Point-to-point routing of ISPs assigning our dhcp
paramters which
are theoretically incorrect.
Do a route -n on the openwrt. if you see two routes to reach
your gateway,
with one pointing into the ipsec device, delete the one
pointing into the
ipsec device.
> 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?
Paul
--
Building and integrating Virtual Private Networks with
Openswan:
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155
_______________________________________________
Users openswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan:
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155
|
|
| Re: One way tunnel |
|
2007-03-05 04:47:47 |
|
Hi Paul,
Thanks for the quick response.
On 3/5/07, Paul Wouters < paulxelerance.com">paulxelerance.com> wrote:
On Mon, 5 Mar 2007, lewis shobbrook wrote:
> I'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.
>
> First digression to note is that I have had this combination working
> previously prior to WR 0.9.
>
> The tunnel works from the wrt end, through put is perfectly stable.
> from the debian end I am unable to ping through the tunnel with errors
>; ...reply from
X.X.X.X destination net unreachable.
> x.x.x.x is the next hop to the DSL router connected to the debian box, i.e.
> gateway to gateway.
"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...
Doesn';t matter which side the tunnel is upped from.
> Other thing to note is that traceroutes to and from the wrt to the debian
> ends indicate different IP for the nexthop on the wrt side.
Thats bad Point-to-point routing of ISPs assigning our dhcp paramters which
are theoretically incorrect.
Do a route -n on the openwrt. if you see two routes to reach your gateway,
with one pointing into the ipsec device, delete the one pointing into the
ipsec device.
> 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.
Cheers & thanks,
Lew
|
| Re: One way tunnel |
|
2007-03-05 07:26:10 |
|
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.
|
[1-4]
|
|