Discussion:
[Openvpn-users] Moving all IPv6 traffic from client though server over vpn, can't ping from client lan?
j***@fastmail.com
2015-08-21 05:09:47 UTC
Permalink
I set up an OpenVpn Server & Client.

It's configured as IPv4 with IPv6 'inside'.

I'm trying to get ALL IPv6 traffic from the Client's LAN to go over the OpenVpn link and out to & in from the net.

Right now I can ping from the Client OpenVpn box out over the vpn link via IPv6.

I can't ping from the Client LAN. Not even to the Server end of the tunnel.

I can't figure out why :-/ and would appreciate any helpful hints!

For this 3 machine setup

REMOTE-SERVER / OpenVpn Server
eth0 X.X.X.X
2600:####:####:4d00::1/64
vpn0 10.0.0.1/24
2600:####:####:4dff::1/64

LOCAL-ROUTER / OpenVpn Client
eth0 Y.Y.Y.Y
vpn0 10.0.0.2/24
2600:####:####:4dff::2/64
eth1 10.128.128.1/24
2600:####:####:4d09::1/64

LAN-PC
eth1 10.128.128.20/24
2600:####:####:4d09::2/64

I'm using this configuration

OpenVPN server
server.conf
bind
ccd-exclusive
client-config-dir ccd/
client-to-client
dev tun1
mode server
proto udp
script-security 2
topology subnet

local X.X.X.X
server 10.0.0.0 255.255.255.0
server-ipv6 2600:####:####:4dff::/64
push "route 10.128.128.0 255.255.255.0"
route 10.128.128.0 255.255.255.0
...

ccd/client.conf
ifconfig-push 10.0.0.2 255.255.255.0
ifconfig-ipv6-push 2600:####:####:4dff::2/64 2600:####:####:4dff::1
push "route-ipv6 2000::/3"
push "redirect-gateway-ipv6 def1"
iroute 10.128.128.0 255.255.255.0
...

OpenVPN client
client.conf
bind
daemon
dev tun1
proto udp
pull

local Y.Y.Y.Y
<connection>
remote X.X.X.X udp
</connection>
...
From shell on the LOCAL-ROUTER, this works
ping6 -v -c 1 2600:####:####:4dff::1
PING 2600:####:####:4dff::1(2600:####:####:4dff::1) 56 data bytes
64 bytes from 2600:####:####:4dff::1: icmp_seq=1 ttl=64 time=27.5 ms

But this doesn't.

ping6 -v -c 1 -I 2600:####:####:4d09::1 2600:####:####:4dff::1
PING 2600:####:####:4dff::1(2600:####:####:4dff::1) from 2600:####:####:4d09::1 : 56 data bytes

Where the LAN side of my LOCAL-ROUTER is

ip -6 addr show eth1
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2600:####:####:4d09::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c2eb:87d3:fcc4:a3ce/64 scope link
valid_lft forever preferred_lft forever

ip -6 addr show tun1
***@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 100
inet6 2600:####:####:4dff::2/64 scope global
valid_lft forever preferred_lft forever

ip -6 route show
2600:####:####:4d09::/64 dev eth1 proto kernel metric 256 pref medium
2600:####:####:4dff::/64 dev tun1 proto kernel metric 256 pref medium
2000::/3 dev tun1 metric 1024 pref medium
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 pref medium
fe80::/64 dev ifb0 proto kernel metric 256 pref medium
From the PC-LAN I can ping the LOCAL-ROUTER tunnel endpoint, but can't get any further.
I'm not sure what's going wrong here & why I can't ping from the LAN.

Am I missing a route?

- John


------------------------------------------------------------------------------
Selva Nair
2015-08-21 14:19:56 UTC
Permalink
Post by j***@fastmail.com
REMOTE-SERVER / OpenVpn Server
eth0 X.X.X.X
2600:####:####:4d00::1/64
vpn0 10.0.0.1/24
2600:####:####:4dff::1/64
LOCAL-ROUTER / OpenVpn Client
eth0 Y.Y.Y.Y
vpn0 10.0.0.2/24
2600:####:####:4dff::2/64
eth1 10.128.128.1/24
2600:####:####:4d09::1/64
LAN-PC
Post by j***@fastmail.com
eth1 10.128.128.20/24
2600:####:####:4d09::2/64
How is that 4d09::/64 block routed to from the outside world? I guess its
delegated from a larger block routed to your server. If so you will need
ipv6 forwarding enabled on the server and a route on the server to the
4d09::/64 through the tunnel. Please show us the routes on the server too.

Just guessing, is the server on a Linode? I had once briefly tested a
similar setup and, for some reason, the throughput on ipv6 connections was
very poor. Once your setup is working I would love to hear about the
performance.

Selva
j***@fastmail.com
2015-08-21 14:46:15 UTC
Permalink
Hello Selva
Just guessing, is the server on a Linode? I had once briefly tested a similar setup and, for some reason, the throughput on ipv6 connections was very poor. Once your setup is working I would love to hear about the performance.
Yeah the Server that I'm getting access to is one he runs on a Linode VPS service.

He did do some comparing of IPv4 and IPv6 performance on his system. Throughput is "3-5% lower" on IPv6 than IPv4 according to him. I guess there's a little more overhead to IPv6.

Once I get all this working I can sure do some measurements here. Anyway it turns out I guess I have to live with possibly 'poor' still being better than 'none'. I only need this IPv6 acess for some work not all of my browsing etc.

The deal was I can use his system for nothing, but I'm going to have to do my homework and understand, get help with, and eventually maintain it myself. Totally reasonable so I can't complain.
How is that 4d09::/64 block routed to from the outside world? I guess its delegated from a larger block routed to your server.
I had to ask to be sure. The server got a big block, a "routed /56". Not as big as a Hurricane Electric /48, but for me I don't think it makes any difference at all. One piece of it, a /64, is used for the OpenVpn tunnel endpoints. Another slice, a different /64, is used for "me". In other words unique IPv6s for my LAN.
If so you will need ipv6 forwarding enabled on the server
On the server it already is

cat /proc/sys/net/ipv6/conf/{all,tun1}/forwarding
1
1
and a route on the server to the 4d09::/64 through the tunnel. Please show us the routes on the server too.
ip -6 route
2600:####:####:4d00::/64 dev eth0 proto kernel metric 256 pref medium
2600:####:####:4dff::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium

ip -4 route
default via X.X.X.1 dev eth0
10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1
X.X.X.0/24 dev eth0 proto kernel scope link src X.X.X.X
10.128.128.0/24 via 10.0.0.2 dev tun1

I don't see anything that's just for the 4d09::/64. So something like that's missing? Do I do that in the OpenVpn config?

I'm kind of confused why the ping6 without the "-I <address>" works but not without it. :-/

Selva

------------------------------------------------------------------------------
Selva Nair
2015-08-21 15:51:09 UTC
Permalink
Hi John,
and a route on the server to the 4d09::/64 through the tunnel. Please
show us the routes on the server too.
ip -6 route
2600:####:####:4d00::/64 dev eth0 proto kernel metric 256 pref medium
2600:####:####:4dff::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium
ip -4 route
default via X.X.X.1 dev eth0
10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1
X.X.X.0/24 dev eth0 proto kernel scope link src X.X.X.X
10.128.128.0/24 via 10.0.0.2 dev tun1
I don't see anything that's just for the 4d09::/64. So something like
that's missing? Do I do that in the OpenVpn config?
I was only testing, so manually added the route -- in your case that would
be

ip -6 route add 2600:x:x:4d09::/64 via 2600:x:x:4dff::y

where y is the v6 IP of the VPN client (the LAN router in your case) -- y
= 2 in your case?

To state the obvious, also make sure the traffic to this prefix is not
firewalled.

I don't know the best practice for handling routes to delegated prefixes; I
guess it depends on whether the delegation is handled by some service
running on the server or not. If the delegation is managed manually, the
route could be setup by in a client-connect script or be permanently added?


I'm kind of confused why the ping6 without the "-I <address>" works but not
without it. :-/
Ping from the router would work as long as the source address is 4dff::2
and not 4d09::1. As you wrote before
From shell on the LOCAL-ROUTER, this works
ping6 -v -c 1 2600:####:####:4dff::1
But this doesn't.
ping6 -v -c 1 -I 2600:####:####:4d09::1 2600:####:####:4dff::1
The first one uses 4dff::2 as the source and there is a route to it on the
server, the second one uses 4d09::1 as the source address but the server
doesn't know how to route back to it.

Selva

P.S. This may not be a problem in your case, but I had to set accept_ra = 2
on the Linode as otherwise ipv6_forward=1 disables "Accept Router
Advertisements".
j***@fastmail.com
2015-08-21 16:22:33 UTC
Permalink
Hi Selva

ip -6 route
2600:x:x:4d00::/64 dev eth0 proto kernel metric 256 pref medium
2600:x:x:4dff::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium

ip -4 route
default via X.X.X.1 dev eth0
10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1
X.X.X.0/24 dev eth0 proto kernel scope link src X.X.X.X
10.128.128.0/24 via 10.0.0.2 dev tun1
I was only testing, so manually added the route -- in your case that would be
ip -6 route add 2600:x:x:4d09::/64 via 2600:x:x:4dff::y
where y is the v6 IP of the VPN client (the LAN router in your case) -- y = 2 in your case?
Ok I added on the REMOTE-SERVER

ip -6 route add 2600:x:x:4d09::/64 via 2600:x:x:4dff::2

So now I have

ip -6 route
2600:x:x:4d00::/64 dev eth0 proto kernel metric 256 pref medium
2600:x:x:4d09::/64 via 2600:x:x:4dff::2 dev tun1 metric 1024 pref medium
2600:x:x:4dff::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium

But it doesn't make any difference. Still can't get out from the client side LAN.
To state the obvious, also make sure the traffic to this prefix is not firewalled.
Sure that's one of the FIRST things I was fumbling around with. While testing I turned on verbose logging in the firewalls on both ends and don't see anything being DROPd or REJECTd.

I don't really know if this is only a firewall or routing problem or both :-(
I don't know the best practice for handling routes to delegated prefixes; I guess it depends on whether the delegation is handled by some service running on the server or not. If the delegation is managed manually, the route could be setup by in a client-connect script or be permanently added?
Once I can get it working I guess there's a bunch of places to do it. Since its OpenVpn related probably in OpenVpn configuration.
P.S. This may not be a problem in your case, but I had to set accept_ra = 2 on the Linode as otherwise ipv6_forward=1 disables "Accept Router Advertisements".
I checked on the REMOTE-SERVER. Right now it's

cat /proc/sys/net/ipv6/conf/{all,tun1,eth0}/accept_ra
1
1
1

So I did

echo 2 > /proc/sys/net/ipv6/conf/all/accept_ra
echo 2 > /proc/sys/net/ipv6/conf/tun1/accept_ra
echo 2 > /proc/sys/net/ipv6/conf/eth0/accept_ra
cat /proc/sys/net/ipv6/conf/{all,tun1,eth0}/accept_ra
2
2
2

But it's still the same. No ping.

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 17:51:44 UTC
Permalink
Hi Selva
Can you ping from the server to the router's 4d09::1 address?
From the shell on the REMOTE-SERVER, I CAN'T ping6 to the LOCAL-ROUTER's internal eth1 interface IP
ping6 2600:x:x:4d09::1
PING 2600:x:x:4d09::1(2600:x:x:4d09::1) 56 data bytes

Just sits there. Doesn't even time out like a normal ping fail does. :-/

But I CAN ping6 to the LOCAL-ROUTER's end of the VPN tunnel

ping6 -c1 2600:x:x:4dff::2
PING 2600:x:x:4dff::2(2600:x:x:4dff::2) 56 data bytes
64 bytes from 2600:x:x:4dff::2: icmp_seq=1 ttl=64 time=30.4 ms

--- 2600:x:x:4dff::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 30.431/30.431/30.431/0.000 ms


Just to remind myself this is with

REMOTE-SERVER
eth0 (external)
tun1 (vpn tunnel)

LOCAL-ROUTER
eth0 (external)
tun1 (vpn tunnel)
eth1 (internal / LAN)

Where the related IPv6s are

REMOTE-SERVER
lo:
::1/128 scope host
eth0:
2600:x:x:4d00::1/64 scope global
fe80::.../64 scope link
***@NONE:
2600:x:x:4dff::1/64 scope global

LOCAL-ROUTER
lo:
::1/128 scope host
eth1:
2600:x:x:4d09::1/64 scope global
fe80::...
***@NONE:
2600:x:x:4dff::2/64 scope global

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 18:14:05 UTC
Permalink
Hi Selva
What about ip6tables settings on the router? On my asus router the default
was to DROP all, so I had to change those.
I have explicit blanket ACCEPT all enabled with verbose logging for all the prefixes we're dealing with :-/

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 18:33:32 UTC
Permalink
Some more info on what I see on the firewalls.

On the LOCAL-ROUTER, testing the 2 ping"types", with and without the added address


"without"

ping6 -c1 2600:x:x:4dff::1
PING 2600:x:x:4dff::1(2600:x:x:4dff::1) 56 data bytes
64 bytes from 2600:x:x:4dff::1: icmp_seq=1 ttl=64 time=27.4 ms

--- 2600:x:x:4dff::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.488/27.488/27.488/0.000 ms

firewall log @ LOCAL-ROUTER
Aug 21 11:19:20 local01 kernel: [96663.073933] SW:[P6][DBG]:ACCEPT IN= OUT=tun1 SRC=2600:x:x:4dff:0000:0000:0000:0002 DST=2600:x:x:4dff:0000:0000:0000:0001 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=20070 SEQ=1

firewall log @ REMOTE-SERVER
Aug 21 11:19:20 remote01 kernel: [ 5194.195094] SW:[P6][DBG]:ACCEPT IN=tun1 OUT= SRC=2600:x:x:4dff:0000:0000:0000:0002 DST=2600:x:x:4dff:0000:0000:0000:0001 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=20070 SEQ=1


"with"

ping6 -c 1 -I 2600:x:x:4d09::1 2600:x:x:4dff::1
PING 2600:x:x:4dff::1(2600:x:x:4dff::1) from 2600:x:x:4d09::1 : 56 data bytes
... NOTHING ...

firewall log @ LOCAL-ROUTER
Aug 21 11:20:33 local01 kernel: [96735.664650] SW:[P6][DBG]:ACCEPT IN= OUT=tun1 SRC=2600:x:x:4d09:0000:0000:0000:0001 DST=2600:x:x:4dff:0000:0000:0000:0001 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=20155 SEQ=1

firewall log @ REMOTE-SERVER
... NOTHING ...

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 18:55:28 UTC
Permalink
So the packet is dropped by the VPN? I dont have access to my config right
now, but may be an iroute is required in the config or ccd as in the ipv4
case of routing LAN clients through VPN. Please check the man page on
iroute.
I had added the the REMOTE-SERVER's ccd/client.conf

iroute 2600:x:x:4d09::/64

And that didn't help either.

But I just figured out that that has to be

iroute-ipv6 2600:x:x:4d09::/64

which isn't in any of the online examples I found. It's a newer version command AFAIK.

But, good news! Now it works!
From any machine on the LAN
ping6 google.com
PING google.com(nuq04s18-in-x09.1e100.net) 56 data bytes
64 bytes from nuq04s18-in-x09.1e100.net: icmp_seq=1 ttl=56 time=29.4 ms
64 bytes from nuq04s18-in-x09.1e100.net: icmp_seq=2 ttl=56 time=28.9 ms
...

I'm gonna do some more test, with the online IPv6 tester sites, but that may have done the trick!

THanks :-)

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 18:56:18 UTC
Permalink
Crossed in the mail! :-)
may be an iroute is required
Just checked the man page -- it should be iroute-ipv6 in the ccd. I also
realized you could use route-ipv6 in the same ccd file to set up the route
to 4d09 in the system routing table.
------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 18:48:24 UTC
Permalink
P.S. By the way, if you are doing this only for ipv6 traffic (ie.,
encryption is not required), its much easier to manage a 6in4 tunnel to the
Linode. That's what I ended up doing although I still have some performance
issues..
I can't because we figured out that the ISP blocks "protocol 41". I can't do any 6in4 tunnels. I checked with Hurricane Electric who I had used in other situtations and they said I'm out of luck unfortunately. :-(

So that's why we're doing this "IPv6 inside" an OpenVpn IPv4 tunnel.

- John

------------------------------------------------------------------------------
j***@fastmail.com
2015-08-21 19:59:42 UTC
Permalink
Doing a quick & dirty (one run only) download comparison from my LAN (that's behind the router, firewall, switch, etc etc).

In this test, the IPv4 traffic is going out locally, through my ISP, and the IPv6 traffic is going over the VPN.

rm -f linux*tar.gz && \
time wget -4 --no-check-certificate \
https://tiz-korg-pub.kernel.org/pub/linux/kernel/v3.x/linux-3.19.8.tar.gz && \
rm -f linux*tar.gz && \
time wget -6 --no-check-certificate \
https://tiz-korg-pub.kernel.org/pub/linux/kernel/v3.x/linux-3.19.8.tar.gz

Returns decent, not great results for

IPv4

real 0m44.052s
user 0m3.908s
sys 0m4.768s

& IPv6

real 0m50.019s
user 0m5.316s
sys 0m6.920s


- John

------------------------------------------------------------------------------
Gert Doering
2015-08-22 12:34:20 UTC
Permalink
Hi,
Post by j***@fastmail.com
I'm trying to get ALL IPv6 traffic from the Client's LAN to go over the OpenVpn link and out to & in from the net.
Without having read the thread fully, what you need is the same you'd need
for an IPv4 setup:

- route the client LAN on the server side (route-ipv6, iroute-ipv6)
- turn on routing on the client (ipv6forward=1, depending on the
client OS)
- configure the client LAN address on all client LAN interfaces
- set up a default route on the "other boxes" to point to the client LAN
interface

the last two can be automated by running radvd on the client, announcing
an IPv6 default and prefix towards the LAN.

[..]
Post by j***@fastmail.com
local X.X.X.X
server 10.0.0.0 255.255.255.0
server-ipv6 2600:####:####:4dff::/64
push "route 10.128.128.0 255.255.255.0"
route 10.128.128.0 255.255.255.0
The server config is missing the "route-ipv6 ...:4d09::/64" to make the
/64 go into the tunnel.
Post by j***@fastmail.com
ccd/client.conf
ifconfig-push 10.0.0.2 255.255.255.0
ifconfig-ipv6-push 2600:####:####:4dff::2/64 2600:####:####:4dff::1
push "route-ipv6 2000::/3"
push "redirect-gateway-ipv6 def1"
iroute 10.128.128.0 255.255.255.0
...
This is missing the "iroute-ipv6 ... 4d09::/64" so OpenVPN knows that
this /64 is on the client side.

You have the iroute for IPv4, so adding iroute-ipv6 for IPv6 *should*
be the logical conclusion... :-)

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ***@greenie.muc.de
fax: +49-89-35655025 ***@net.informatik.tu-muenchen.de
j***@fastmail.com
2015-08-22 14:24:27 UTC
Permalink
Hello Gert
Post by Gert Doering
the last two can be automated by running radvd on the client, announcing
an IPv6 default and prefix towards the LAN.
So far I got it all working without the radvd. But I did read about it. Once I figure out about ULA addresses and if and when I should use them in this situation I'll work on putting it in place. Got to be easier than setting all these IPv6's by hand!
Post by Gert Doering
You have the iroute for IPv4, so adding iroute-ipv6 for IPv6 *should*
be the logical conclusion... :-)
When you look BACK at it yeah it's logical :-) I read a bunch of examples & tutorials online to get started just because they're easier to read for me as a noob than the manpages. Bits and pieces were missing that I didn't realize were missing until this thread discussion :-/.

Now at least I understand enough for the manpages to be a good guide too.

Thanks!!

- John

------------------------------------------------------------------------------
Gert Doering
2015-08-22 19:15:30 UTC
Permalink
Hi,
Post by j***@fastmail.com
Post by Gert Doering
You have the iroute for IPv4, so adding iroute-ipv6 for IPv6 *should*
be the logical conclusion... :-)
When you look BACK at it yeah it's logical :-) I read a bunch of examples & tutorials online to get started just because they're easier to read for me as a noob than the manpages. Bits and pieces were missing that I didn't realize were missing until this thread discussion :-/.
Yeah, in hindsight, everything is totally easy :-)

One of the problems we have with online tutorials is that OpenVPN is so
old and so widely used - so there's a gazillion of (good) third party
documentation out there, which works, but is not necessarily updated to
cover "fairly new" stuff like IPv6...

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ***@greenie.muc.de
fax: +49-89-35655025 ***@net.informatik.tu-muenchen.de
Loading...