Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #202765 > unrolled thread

Fwd: openvpn over ipv6 /65

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-26 11:50 +0100
    Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-26 12:50 +0100
      Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-26 13:50 +0100
        Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-26 17:00 +0100
          Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-26 18:00 +0100
            Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-26 18:20 +0100
              Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 11:40 +0100
              Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-27 11:50 +0100
                Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 12:00 +0100
                  Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-27 12:00 +0100
                    Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 12:30 +0100
                      Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-27 12:50 +0100
                        Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 13:30 +0100
                          Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-27 13:40 +0100
                            Re: Fwd: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 14:00 +0100
                              Re: Fwd: openvpn over ipv6 /65 Reco <recoverym4n@enotuniq.net> - 2018-11-27 15:10 +0100
                                [SOLVED]: openvpn over ipv6 /65 tony <lists@vanderhoff.org> - 2018-11-27 15:30 +0100

#202765 — Fwd: openvpn over ipv6 /65

Sorry, hit the wrong button!


-------- Forwarded Message --------
Subject: Re: openvpn over ipv6 /65
Date: Mon, 26 Nov 2018 11:25:09 +0100
From: tony <lists@vanderhoff.org>
To: Reco <recoverym4n@enotuniq.net>

On 23/11/2018 15:24, Reco wrote:
> 	HI.
> 
> On Fri, Nov 23, 2018 at 03:07:01PM +0100, tony wrote:
>> Thanks for your quick response, Reco,
>>
>> On 23/11/2018 13:33, Reco wrote:
>>> 	Hi.
>>>
>>> On Fri, Nov 23, 2018 at 01:18:45PM +0100, tony wrote:
>>>> Hi,
>>>>
>>>> I have a Stretch VPServer with a /64 netbloch, of which only the first 2
>>>> addresses are used. I've been struggling for some time to get the right
>>>> stanza to split that into two /65s, using the upper half for openvpn.
>>>
>>> I'd check first that some other addresses from this /64 range are routed
>>> by your VPS provider.
>>>
>> I'm not sure I understand what you mean. As far as I'm aware, my VPS
>> provider furnishes a full native /64 netblock for my exclusive use.
>> They'll provide more, at a cost, but I see no point in that.
>>>
>> [snip]
> 
> Assign some other IPv6 address from your range to your VPS.
> Ensure that it's reachable from the outside world.
> For instance, I do not get any response from your gateway while I'm
> pinging 2a03:9800:10:54::dead (which you do not have), and get a reply
> from 2a03:9800:10:54::2 (which belongs to your VPS).
> 
> 
>>> Ad-hoc configuration:
>>>
>>> ### check this on your OS!
>>> # ip a d igb0 2001:db8:0:123::/64
>>> # ip a a igb0 2001:db8:0:123::/65
>>> ###
>>> ### re-assign the other aliases previously set under the /64 block
>>> # ip a a igb0 2001:db8:0:123::dead/128
>>> # ip a a igb0 2001:db8:0:123::ea:beef/128
>>>
>> I'm not using any addresses other than the ::1 and ::2 in the /64 block,
>> so presumably the last two lines are redundant.
> 
> Yes, you do not need them.
> 
> 
>>> As for the persistent configuration, that depends on the contents of
>>> /etc/network/interfaces. Can be static (it's straightforward then),
>>> DHCPv6 (you won't be able to do the split) or RA (ditto).
>>>
>> No, it's all static:
> 
> That simplifies things greatly.
> Replace this:
> 
> iface eth0 inet6 static
>            address 2a03:9800:10:54::2
>            netmask 64
>            gateway 2a03:9800:10:54::1
> 
> with this:
> 
> iface eth0 inet6 static
>            address 2a03:9800:10:54::2
>            netmask 65
>            gateway 2a03:9800:10:54::1
> 
> Leave all the other entries intact.
> Then invoke this as root (one-time only):
> 
> ip a d dev eth0 2a03:9800:10:54::2/64
> ip a a dev eth0 2a03:9800:10:54::2/65
> ip ro d default via 2a03:9800:10:54::1
> 
> 
>> So what is igb0?
> 
> A name of interface that's used in OpenVPN documentation. Yours is called eth0.
> 
> 
>> What do you mean by ad-hoc and persistent configuration?
> 
> ad-hoc means that you're using certain OS binaries (in this case - ip)
> to create a network configuration that does not survive the reboot.
> persistent means the opposite - you're trying to create a configuration
> that should reproduce itself after the reboot (in this case - e/n/i).
> 
> Reco
> 

Thanks so much, Reco. This has got me well on the way to setting up a
IPv6 VPN. It has also greatly enhanced my unserstanding of OpenVPN.

So, I've assigned 2a03:9800:10:54:8000::/65 to the VPN, and this appears
to work. The logs are showing the tunnel having been established.
However, I can't get any IPv6 connectivity to the internet unless I stop
OpenVPN. Have you any further suggestions as to what I might try?

Cheers, Tony

[toc] | [next] | [standalone]

#202767

	Hi.

On Mon, Nov 26, 2018 at 11:49:13AM +0100, tony wrote:
> >>> As for the persistent configuration, that depends on the contents of
> >>> /etc/network/interfaces. Can be static (it's straightforward then),
> >>> DHCPv6 (you won't be able to do the split) or RA (ditto).
> >>>
> >> No, it's all static:
> > 
> > That simplifies things greatly.
> > Replace this:
> > 
> > iface eth0 inet6 static
> >            address 2a03:9800:10:54::2
> >            netmask 64
> >            gateway 2a03:9800:10:54::1
> > 
> > with this:
> > 
> > iface eth0 inet6 static
> >            address 2a03:9800:10:54::2
> >            netmask 65
> >            gateway 2a03:9800:10:54::1
> > 
> > Leave all the other entries intact.
> > Then invoke this as root (one-time only):
> > 
> > ip a d dev eth0 2a03:9800:10:54::2/64
> > ip a a dev eth0 2a03:9800:10:54::2/65
> > ip ro d default via 2a03:9800:10:54::1
>
> Thanks so much, Reco. This has got me well on the way to setting up a
> IPv6 VPN. It has also greatly enhanced my unserstanding of OpenVPN.
> 
> So, I've assigned 2a03:9800:10:54:8000::/65 to the VPN, and this appears
> to work. The logs are showing the tunnel having been established.

That's great.

> However, I can't get any IPv6 connectivity to the internet unless I stop
> OpenVPN.

You mean, you lose IPv6 connectivity on the VPS?
Or your host where OpenVPN client is has some other means of connecting
via IPv6, and this other host loses IPv6 connectivity once OpenVPN's
tunnel is up?


> Have you any further suggestions as to what I might try?

I'd like to see your IPv6 routing tables from your VPS and the OpenVPN client.
Two simple 'ip -6 ro l' will do.
And, for the sake of the completeness, the same 'ip -6 ro l' once OpenVPN is down.

Reco

[toc] | [prev] | [next] | [standalone]

#202768

On 26/11/2018 12:48, Reco wrote:
> 	Hi.
> 
> On Mon, Nov 26, 2018 at 11:49:13AM +0100, tony wrote:
>>>>> As for the persistent configuration, that depends on the contents of
>>>>> /etc/network/interfaces. Can be static (it's straightforward then),
>>>>> DHCPv6 (you won't be able to do the split) or RA (ditto).
>>>>>
>>>> No, it's all static:
>>>
>>> That simplifies things greatly.
>>> Replace this:
>>>
>>> iface eth0 inet6 static
>>>            address 2a03:9800:10:54::2
>>>            netmask 64
>>>            gateway 2a03:9800:10:54::1
>>>
>>> with this:
>>>
>>> iface eth0 inet6 static
>>>            address 2a03:9800:10:54::2
>>>            netmask 65
>>>            gateway 2a03:9800:10:54::1
>>>
>>> Leave all the other entries intact.
>>> Then invoke this as root (one-time only):
>>>
>>> ip a d dev eth0 2a03:9800:10:54::2/64
>>> ip a a dev eth0 2a03:9800:10:54::2/65
>>> ip ro d default via 2a03:9800:10:54::1
>>
>> Thanks so much, Reco. This has got me well on the way to setting up a
>> IPv6 VPN. It has also greatly enhanced my unserstanding of OpenVPN.
>>
>> So, I've assigned 2a03:9800:10:54:8000::/65 to the VPN, and this appears
>> to work. The logs are showing the tunnel having been established.
> 
> That's great.
> 
>> However, I can't get any IPv6 connectivity to the internet unless I stop
>> OpenVPN.
> 
> You mean, you lose IPv6 connectivity on the VPS?
> Or your host where OpenVPN client is has some other means of connecting
> via IPv6, and this other host loses IPv6 connectivity once OpenVPN's
> tunnel is up?
> 
Yes, I have here in France an IPv6 connection to the outside world. over
which I successfully run a IPv4 tunnel to my server in the UK. I am
trying to set up a IPV6 VPN tunnel, to avoid various geolocation
hassles. When I activatre OpenVpn, I lose all IPv6 connectivity,
including the native one.
> 
>> Have you any further suggestions as to what I might try?
> 
> I'd like to see your IPv6 routing tables from your VPS and the OpenVPN client.
> Two simple 'ip -6 ro l' will do.
> And, for the sake of the completeness, the same 'ip -6 ro l' once OpenVPN is down.
> 
Thank you.

With the VPN up:
On the host:
13:07:11 tony@tony-fr:~$ ip -6 ro l
2a01:cb19:851f:ea00::/64 dev enp3s0 proto ra metric 100  pref medium



2a03:9800:10:54::2 via fe80::a63e:51ff:fe32:f85d dev enp3s0 metric 1
pref medium
2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
2a03:9800:10:54:8000::/65 dev tun0 metric 1024  pref medium
2a03:9800:10:54:8000::/65 dev tun0 metric 1029  pref medium
2000::/3 dev tun0 metric 1024  pref medium
2000::/3 dev tun0 metric 1028  pref medium
fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100  pref medium
fe80::/64 dev enp3s0 proto kernel metric 256  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium
default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100
 pref medium

on the server:
root@shell:~# ip -6 ro l
2a03:9800:10:54::/65 dev eth0 proto kernel metric 256  pref medium
2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium
default via 2a03:9800:10:54::1 dev eth0 metric 1024  pref medium

Now with OpenVPN down:
on the host:
root@tony-fr:~# ip -6 ro l
2a01:cb19:851f:ea00::/64 dev enp3s0 proto ra metric 100  pref medium
fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100  pref medium
fe80::/64 dev enp3s0 proto kernel metric 256  pref medium
default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100
 pref medium

On the server:
root@shell:~# ip -6 ro l
2a03:9800:10:54::/65 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via 2a03:9800:10:54::1 dev eth0 metric 1024  pref medium


I hope that is sufficient information

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#202777

	Hi.

It's been a long and an eventful day. But, 

On Mon, Nov 26, 2018 at 01:40:22PM +0100, tony wrote:
> >> Have you any further suggestions as to what I might try?
> > 
> > I'd like to see your IPv6 routing tables from your VPS and the OpenVPN client.
> > Two simple 'ip -6 ro l' will do.
> > And, for the sake of the completeness, the same 'ip -6 ro l' once OpenVPN is down.
> > 

That's weird:

> With the VPN up:
> On the host:
> 13:07:11 tony@tony-fr:~$ ip -6 ro l
...
> 2a03:9800:10:54::2 via fe80::a63e:51ff:fe32:f85d dev enp3s0 metric 1 pref medium

I understand why this route is here (openvpn needs it for its own
traffic), but routing public IPv6 through the link-local does not seem
right.


> 2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
> 2a03:9800:10:54:8000::/65 dev tun0 metric 1024  pref medium
> 2a03:9800:10:54:8000::/65 dev tun0 metric 1029  pref medium

A simple route here would be enough. It seems that you're announcing
your /65 prefix through the openvpn, but at the same time you're
allocating IPv6 with full /65 mask to each openvpn client. That's
redundant.


> 2000::/3 dev tun0 metric 1024  pref medium
> 2000::/3 dev tun0 metric 1028  pref medium

Er, wat? Exterminate this travesty, you should never announce things
like these through openvpn even once, let alone twice. If you really
need to do things like GeoIP spoofing, you should announce an IPv6
default gateway with low metric.


> default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100
>  pref medium

And add 'less than 100 metric' to the previous sentence.


> I hope that is sufficient information

More or less. Server's routing table is good, assuming that you have
net.ipv6.conf.all.forwarding set to 1 there.

Client's routing table is a mess. What you should get with openvpn
stared is (order may be different):

2a03:9800:10:54::2 via fe80::a63e:51ff:fe32:f85d dev enp3s0 metric 1 pref medium
2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
2a01:cb19:851f:ea00::/64 dev enp3s0 proto ra metric 100  pref medium
fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100  pref medium
fe80::/64 dev tun0 proto kernel metric 256  pref medium
fe80::/64 dev enp3s0 proto kernel metric 256  pref medium
default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100 pref medium
default via tun0 metric 99

And that means that it's time to see your openvpn's server configuration
file. Can I see one, please?

Reco

[toc] | [prev] | [next] | [standalone]

#202783

On 26/11/2018 16:55, Reco wrote:
> 	Hi.
> 
> It's been a long and an eventful day. But, 
> 
Sorry to ruin your day. I'm truly grateful for your help.

> On Mon, Nov 26, 2018 at 01:40:22PM +0100, tony wrote:
>>>> Have you any further suggestions as to what I might try?
>>>
>>> I'd like to see your IPv6 routing tables from your VPS and the OpenVPN client.
>>> Two simple 'ip -6 ro l' will do.
>>> And, for the sake of the completeness, the same 'ip -6 ro l' once OpenVPN is down.
>>>
> 
> That's weird:
> 
>> With the VPN up:
>> On the host:
>> 13:07:11 tony@tony-fr:~$ ip -6 ro l
> ...
>> 2a03:9800:10:54::2 via fe80::a63e:51ff:fe32:f85d dev enp3s0 metric 1 pref medium
> 
> I understand why this route is here (openvpn needs it for its own
> traffic), but routing public IPv6 through the link-local does not seem
> right.
> 
> 
>> 2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
>> 2a03:9800:10:54:8000::/65 dev tun0 metric 1024  pref medium
>> 2a03:9800:10:54:8000::/65 dev tun0 metric 1029  pref medium
> 
> A simple route here would be enough. It seems that you're announcing
> your /65 prefix through the openvpn, but at the same time you're
> allocating IPv6 with full /65 mask to each openvpn client. That's
> redundant.
> 
> 
>> 2000::/3 dev tun0 metric 1024  pref medium
>> 2000::/3 dev tun0 metric 1028  pref medium
> 
> Er, wat? Exterminate this travesty, you should never announce things
> like these through openvpn even once, let alone twice. If you really
> need to do things like GeoIP spoofing, you should announce an IPv6
> default gateway with low metric.
> 
I did wonder about that. I have cobbled together stanzas from many
'tutorials' on the web. the 2000::/3 stanza came from one of those.
Someone seemed to think it was a good idea.
> 
>> default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100
>>  pref medium
> 
> And add 'less than 100 metric' to the previous sentence.
> 
> 
>> I hope that is sufficient information
> 
> More or less. Server's routing table is good, assuming that you have
> net.ipv6.conf.all.forwarding set to 1 there.
> 
I assume that's in /etc/sysctl.conf. And no, it's commented out, so
presumably 0.

> Client's routing table is a mess. What you should get with openvpn
> stared is (order may be different):
> 
> 2a03:9800:10:54::2 via fe80::a63e:51ff:fe32:f85d dev enp3s0 metric 1 pref medium
> 2a03:9800:10:54:8000::/65 dev tun0 proto kernel metric 256  pref medium
> 2a01:cb19:851f:ea00::/64 dev enp3s0 proto ra metric 100  pref medium
> fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100  pref medium
> fe80::/64 dev tun0 proto kernel metric 256  pref medium
> fe80::/64 dev enp3s0 proto kernel metric 256  pref medium
> default via fe80::a63e:51ff:fe32:f85d dev enp3s0 proto static metric 100 pref medium
> default via tun0 metric 99
> 
> And that means that it's time to see your openvpn's server configuration
> file. Can I see one, please?
>


Certainly:

script-security 2
port 1194
proto udp
proto udp6
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh1024.pem

server 10.8.0.0 255.255.255.0
server-ipv6 2a03:9800:10:54:8000::/65

ifconfig-pool-persist ipp.txt
push "route-ipv6 2a03:9800:10:54:8000::/65"
push "route-ipv6 2000::/3"

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 208.67.222.222"

# DNS servers provided by portfast.net.
push "dhcp-option DNS 193.108.199.130"
push "dhcp-option DNS 85.158.46.77"

keepalive 10 120

comp-lzo
max-clients 10

user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn-status.log

log		/var/log/openvpn.log

verb 4

I have cut out a load of useless commentary in that file

[toc] | [prev] | [next] | [standalone]

#202784

	Hi.

On Mon, Nov 26, 2018 at 05:53:27PM +0100, tony wrote:
> >> 2000::/3 dev tun0 metric 1024  pref medium
> >> 2000::/3 dev tun0 metric 1028  pref medium
> > 
> > Er, wat? Exterminate this travesty, you should never announce things
> > like these through openvpn even once, let alone twice. If you really
> > need to do things like GeoIP spoofing, you should announce an IPv6
> > default gateway with low metric.
> > 
> I did wonder about that. I have cobbled together stanzas from many
> 'tutorials' on the web. the 2000::/3 stanza came from one of those.
> Someone seemed to think it was a good idea.

Either that someone solved their own specific task, or did not give it
much thought. A bad idea.


> >> I hope that is sufficient information
> > 
> > More or less. Server's routing table is good, assuming that you have
> > net.ipv6.conf.all.forwarding set to 1 there.
> > 
> I assume that's in /etc/sysctl.conf.

"sysctl net.ipv6.conf.all.forwarding" to check it, and yes,
/etc/sysctl.conf to implement it.

> And no, it's commented out, so presumably 0.

This ain't right. You need your openvpn server to route IPv6 from and to
you, so set it to 1.


> > Client's routing table is a mess. What you should get with openvpn
> > stared is (order may be different):
> > 
...
> > And that means that it's time to see your openvpn's server configuration
> > file. Can I see one, please?
> 
> Certainly:

So, without further ado,

> proto udp
> proto udp6

Choose one here. Either you connect to your openvpn server via IPv4, or
you do it via IPv6.
Whatever protocol you encapsulate into openvpn tunnel isn't relevant
here.


> dev tun

L3 tunnel, eh? A good choice, if you ask me.


> push "route-ipv6 2a03:9800:10:54:8000::/65"
> push "route-ipv6 2000::/3"
> push "redirect-gateway def1 bypass-dhcp"

Remove these. Use this instead:

push "redirect-gateway def1"
push "route-ipv6 ::/0 metric 99"

Reco

[toc] | [prev] | [next] | [standalone]

#202811

On 26/11/2018 18:13, Reco wrote:
> 	Hi.
> 
> On Mon, Nov 26, 2018 at 05:53:27PM +0100, tony wrote:
>>>> 2000::/3 dev tun0 metric 1024  pref medium
>>>> 2000::/3 dev tun0 metric 1028  pref medium
>>>
>>> Er, wat? Exterminate this travesty, you should never announce things
>>> like these through openvpn even once, let alone twice. If you really
>>> need to do things like GeoIP spoofing, you should announce an IPv6
>>> default gateway with low metric.
>>>
>> I did wonder about that. I have cobbled together stanzas from many
>> 'tutorials' on the web. the 2000::/3 stanza came from one of those.
>> Someone seemed to think it was a good idea.
> 
> Either that someone solved their own specific task, or did not give it
> much thought. A bad idea.
> 
It actually came from https://community.openvpn.net/openvpn/wiki/IPv6, a
site one would expect to be trustworthy. In fairness it doesn't actually
require this, but in my confusion it just slipped in. Gone now ;)
> 
>>>> I hope that is sufficient information
>>>
>>> More or less. Server's routing table is good, assuming that you have
>>> net.ipv6.conf.all.forwarding set to 1 there.
>>>
>> I assume that's in /etc/sysctl.conf.
> 
> "sysctl net.ipv6.conf.all.forwarding" to check it, and yes,
> /etc/sysctl.conf to implement it.
> 
>> And no, it's commented out, so presumably 0.
> 
> This ain't right. You need your openvpn server to route IPv6 from and to
> you, so set it to 1.
> 
> 
>>> Client's routing table is a mess. What you should get with openvpn
>>> stared is (order may be different):
>>>
> ...
>>> And that means that it's time to see your openvpn's server configuration
>>> file. Can I see one, please?
>>
>> Certainly:
> 
> So, without further ado,
> 
>> proto udp
>> proto udp6
> 
> Choose one here. Either you connect to your openvpn server via IPv4, or
> you do it via IPv6.
> Whatever protocol you encapsulate into openvpn tunnel isn't relevant
> here.
> 
> 
>> dev tun
> 
> L3 tunnel, eh? A good choice, if you ask me.
> 
> 
>> push "route-ipv6 2a03:9800:10:54:8000::/65"
>> push "route-ipv6 2000::/3"
>> push "redirect-gateway def1 bypass-dhcp"
> 
> Remove these. Use this instead:
> 
> push "redirect-gateway def1"
> push "route-ipv6 ::/0 metric 99"

Well, there's an improvement: I'm now able to resolve v6 addresses with
the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
the remote end is still seeing the native V6 address.

I'm seeing this in my host's OVPN log:
Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
AES-256-GCM'
Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
gateway 'metric' must be a valid address
Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
because modern operating systems do not need special IPv6 tun handling
anymore.

I'm assuming it doesn't like the ::/0 address, nor do I understand that.

Please indulge my ignorance a little longer; I feel we're getting there.

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#202813

	Hi.

On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
> >> push "route-ipv6 2a03:9800:10:54:8000::/65"
> >> push "route-ipv6 2000::/3"
> >> push "redirect-gateway def1 bypass-dhcp"
> > 
> > Remove these. Use this instead:
> > 
> > push "redirect-gateway def1"
> > push "route-ipv6 ::/0 metric 99"
> 
> Well, there's an improvement: I'm now able to resolve v6 addresses with
> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
> the remote end is still seeing the native V6 address.
> 
> I'm seeing this in my host's OVPN log:
> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
> AES-256-GCM'
> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
> gateway 'metric' must be a valid address
> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
> because modern operating systems do not need special IPv6 tun handling
> anymore.
> 
> I'm assuming it doesn't like the ::/0 address, nor do I understand that.

Nah, it does not like "metric" part, which is crucial here.
But try this:

push "redirect-gateway def1 ipv6"


> Please indulge my ignorance a little longer; I feel we're getting there.

Sure. One cannot learn unless one's doing.

Reco

[toc] | [prev] | [next] | [standalone]

#202814

On 27/11/2018 11:43, Reco wrote:
> 	Hi.
> 
> On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
>>>> push "route-ipv6 2a03:9800:10:54:8000::/65"
>>>> push "route-ipv6 2000::/3"
>>>> push "redirect-gateway def1 bypass-dhcp"
>>>
>>> Remove these. Use this instead:
>>>
>>> push "redirect-gateway def1"
>>> push "route-ipv6 ::/0 metric 99"
>>
>> Well, there's an improvement: I'm now able to resolve v6 addresses with
>> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
>> the remote end is still seeing the native V6 address.
>>
>> I'm seeing this in my host's OVPN log:
>> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
>> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
>> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
>> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
>> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
>> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
>> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
>> AES-256-GCM'
>> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
>> gateway 'metric' must be a valid address
>> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
>> because modern operating systems do not need special IPv6 tun handling
>> anymore.
>>
>> I'm assuming it doesn't like the ::/0 address, nor do I understand that.
> 
> Nah, it does not like "metric" part, which is crucial here.
> But try this:
> 
> push "redirect-gateway def1 ipv6"
> 
> 
Nope:

Tue Nov 27 11:48:03 2018 us=205080 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 ipv6,route-ipv6 ::/0 metric
99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher
AES-256-GCM'
Tue Nov 27 11:48:03 2018 us=205203 Options error: route-ipv6 parameter
gateway 'metric' must be a valid address

Sorry

[toc] | [prev] | [next] | [standalone]

#202815

On Tue, Nov 27, 2018 at 11:53:07AM +0100, tony wrote:
> On 27/11/2018 11:43, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
> >>>> push "route-ipv6 2a03:9800:10:54:8000::/65"
> >>>> push "route-ipv6 2000::/3"
> >>>> push "redirect-gateway def1 bypass-dhcp"
> >>>
> >>> Remove these. Use this instead:
> >>>
> >>> push "redirect-gateway def1"
> >>> push "route-ipv6 ::/0 metric 99"
> >>
> >> Well, there's an improvement: I'm now able to resolve v6 addresses with
> >> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
> >> the remote end is still seeing the native V6 address.
> >>
> >> I'm seeing this in my host's OVPN log:
> >> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
> >> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
> >> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
> >> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
> >> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
> >> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
> >> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
> >> AES-256-GCM'
> >> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
> >> gateway 'metric' must be a valid address
> >> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
> >> because modern operating systems do not need special IPv6 tun handling
> >> anymore.
> >>
> >> I'm assuming it doesn't like the ::/0 address, nor do I understand that.
> > 
> > Nah, it does not like "metric" part, which is crucial here.
> > But try this:
> > 
> > push "redirect-gateway def1 ipv6"
> > 
> > 
> Nope:

Ok, keep 

push "redirect-gateway def1"

but remove 

push "route-ipv6 ::/0 metric 99"

Reco

[toc] | [prev] | [next] | [standalone]

#202817

On 27/11/2018 11:55, Reco wrote:
> On Tue, Nov 27, 2018 at 11:53:07AM +0100, tony wrote:
>> On 27/11/2018 11:43, Reco wrote:
>>> 	Hi.
>>>
>>> On Tue, Nov 27, 2018 at 11:19:12AM +0100, tony wrote:
>>>>>> push "route-ipv6 2a03:9800:10:54:8000::/65"
>>>>>> push "route-ipv6 2000::/3"
>>>>>> push "redirect-gateway def1 bypass-dhcp"
>>>>>
>>>>> Remove these. Use this instead:
>>>>>
>>>>> push "redirect-gateway def1"
>>>>> push "route-ipv6 ::/0 metric 99"
>>>>
>>>> Well, there's an improvement: I'm now able to resolve v6 addresses with
>>>> the VPN up, presumably because IPv6 forwarding now being enabled, BUT,
>>>> the remote end is still seeing the native V6 address.
>>>>
>>>> I'm seeing this in my host's OVPN log:
>>>> Tue Nov 27 10:24:58 2018 us=429309 PUSH: Received control message:
>>>> 'PUSH_REPLY,redirect-gateway def1,route-ipv6 ::/0 metric
>>>> 99,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
>>>> 208.67.222.222,dhcp-option DNS 193.108.199.130,dhcp-option DNS
>>>> 85.158.46.77,tun-ipv6,route 10.8.0.1,topology net30,ping 10,ping-restart
>>>> 120,ifconfig-ipv6 2a03:9800:10:54:8000::1000/65
>>>> 2a03:9800:10:54:8000::1,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher
>>>> AES-256-GCM'
>>>> Tue Nov 27 10:24:58 2018 us=429418 Options error: route-ipv6 parameter
>>>> gateway 'metric' must be a valid address
>>>> Tue Nov 27 10:24:58 2018 us=429472 Note: option tun-ipv6 is ignored
>>>> because modern operating systems do not need special IPv6 tun handling
>>>> anymore.
>>>>
>>>> I'm assuming it doesn't like the ::/0 address, nor do I understand that.
>>>
>>> Nah, it does not like "metric" part, which is crucial here.
>>> But try this:
>>>
>>> push "redirect-gateway def1 ipv6"
>>>
>>>
>> Nope:
> 
> Ok, keep 
> 
> push "redirect-gateway def1"
> 
> but remove 
> 
> push "route-ipv6 ::/0 metric 99"
> 
> Reco
> 

OK, that fixed it, thanks. Almost there. I had expected the host's
openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
server's address:

tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
2a03:9800:10:54::2

Is that fixable?

Cheers, Tony

[toc] | [prev] | [next] | [standalone]

#202818

	Hi.

On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
> OK, that fixed it, thanks. Almost there. I had expected the host's
> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
> server's address:
> 
> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
> 2a03:9800:10:54::2
> 
> Is that fixable?

Probably. My suspicion is that openvpn has configured NAT66 for you,
along with the routing.
Can I see the result of "ip6tables-save" from your openvpn server?

Reco

[toc] | [prev] | [next] | [standalone]

#202819

On 27/11/2018 12:44, Reco wrote:
> 	Hi.
> 
> On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
>> OK, that fixed it, thanks. Almost there. I had expected the host's
>> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
>> server's address:
>>
>> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
>> 2a03:9800:10:54::2
>>
>> Is that fixable?
> 
> Probably. My suspicion is that openvpn has configured NAT66 for you,
> along with the routing.
> Can I see the result of "ip6tables-save" from your openvpn server?
> 
>

OK:
root@shell:~# ip6tables-save
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*nat
:PREROUTING ACCEPT [12346:1595144]
:INPUT ACCEPT [1726:141923]
:OUTPUT ACCEPT [743:66648]
:POSTROUTING ACCEPT [743:66648]
-A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
2a03:9800:10:54::2
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*raw
:PREROUTING ACCEPT [2472612:400710422]
:OUTPUT ACCEPT [3139829:2958344820]
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*mangle
:PREROUTING ACCEPT [2472612:400710422]
:INPUT ACCEPT [2456362:396255430]
:FORWARD ACCEPT [5708:3070874]
:OUTPUT ACCEPT [3139831:2958345100]
:POSTROUTING ACCEPT [3145539:2961415974]
COMMIT
# Completed on Tue Nov 27 11:50:18 2018
# Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [165:76753]
:OUTPUT ACCEPT [3135467:2956504072]
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4000 -j ACCEPT
-A INPUT -s 2001:8b0:ff60:6a91::/64 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 123 -j ACCEPT
-A INPUT -s ::1/128 -d ::1/128 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "ip6tables denied: "
--log-level 7
-A INPUT -j DROP
-A INPUT -p ipv6-icmp -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 2a03:9800:10:54::/64 -i tap0 -o eth0 -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT
# Completed on Tue Nov 27 11:50:18 2018


If I remove the line
-A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
2a03:9800:10:54::2
I lose any ipv6 routing

[toc] | [prev] | [next] | [standalone]

#202820

	Hi.

On Tue, Nov 27, 2018 at 01:20:25PM +0100, tony wrote:
> On 27/11/2018 12:44, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
> >> OK, that fixed it, thanks. Almost there. I had expected the host's
> >> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
> >> server's address:
> >>
> >> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
> >> 2a03:9800:10:54::2
> >>
> >> Is that fixable?
> > 
> > Probably. My suspicion is that openvpn has configured NAT66 for you,
> > along with the routing.
> > Can I see the result of "ip6tables-save" from your openvpn server?
> 
> OK:
> root@shell:~# ip6tables-save
> # Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
> *nat
> :PREROUTING ACCEPT [12346:1595144]
> :INPUT ACCEPT [1726:141923]
> :OUTPUT ACCEPT [743:66648]
> :POSTROUTING ACCEPT [743:66648]
> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> 2a03:9800:10:54::2

Yep. Good old NAT, in this case in IPv6 form. What they call NAT66.


> If I remove the line
> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> 2a03:9800:10:54::2
> I lose any ipv6 routing

Strictly speaking, that's expected. Outside world does not know about
your network topology. What is does know is to send packets to
2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
The problem is - how your IPv6 gateway (54::1) can possibly know that
your custom subnet (:8000::/65) is reachable if you have not announced a
route?

That's something that I need to think about.

Reco

[toc] | [prev] | [next] | [standalone]

#202821

On 27/11/2018 13:34, Reco wrote:
> 	Hi.
> 
> On Tue, Nov 27, 2018 at 01:20:25PM +0100, tony wrote:
>> On 27/11/2018 12:44, Reco wrote:
>>> 	Hi.
>>>
>>> On Tue, Nov 27, 2018 at 12:26:03PM +0100, tony wrote:
>>>> OK, that fixed it, thanks. Almost there. I had expected the host's
>>>> openVPN ip (2a03:9800:10:54:8000::1000) to propagate, but I'm seeing my
>>>> server's address:
>>>>
>>>> tony@tony-fr:~$ dig +short any myip.opendns.com @resolver1.opendns.com
>>>> 2a03:9800:10:54::2
>>>>
>>>> Is that fixable?
>>>
>>> Probably. My suspicion is that openvpn has configured NAT66 for you,
>>> along with the routing.
>>> Can I see the result of "ip6tables-save" from your openvpn server?
>>
>> OK:
>> root@shell:~# ip6tables-save
>> # Generated by ip6tables-save v1.6.0 on Tue Nov 27 11:50:18 2018
>> *nat
>> :PREROUTING ACCEPT [12346:1595144]
>> :INPUT ACCEPT [1726:141923]
>> :OUTPUT ACCEPT [743:66648]
>> :POSTROUTING ACCEPT [743:66648]
>> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
>> 2a03:9800:10:54::2
> 
> Yep. Good old NAT, in this case in IPv6 form. What they call NAT66.
> 
> 
>> If I remove the line
>> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
>> 2a03:9800:10:54::2
>> I lose any ipv6 routing
> 
> Strictly speaking, that's expected. Outside world does not know about
> your network topology. What is does know is to send packets to
> 2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
> The problem is - how your IPv6 gateway (54::1) can possibly know that
> your custom subnet (:8000::/65) is reachable if you have not announced a
> route?
> 
> That's something that I need to think about.

thanks very much for spending so much time on my problem.

[toc] | [prev] | [next] | [standalone]

#202826

On Tue, Nov 27, 2018 at 01:56:34PM +0100, tony wrote:
> >> If I remove the line
> >> -A POSTROUTING -s 2a03:9800:10:54:8000::/65 -o eth0 -j SNAT --to-source
> >> 2a03:9800:10:54::2
> >> I lose any ipv6 routing
> > 
> > Strictly speaking, that's expected. Outside world does not know about
> > your network topology. What is does know is to send packets to
> > 2a03:9800:10:54::1 (*not* :2) in hope of reaching your :8000::/65.
> > The problem is - how your IPv6 gateway (54::1) can possibly know that
> > your custom subnet (:8000::/65) is reachable if you have not announced a
> > route?
> > 
> > That's something that I need to think about.
> 
> thanks very much for spending so much time on my problem.

So, I thought about all this, and came to the following:

1) You can try announcing your own /65 route, but there's 100% chance
that your IPv6 gateway will reject it. I'd do it too if I was your VPS
provider.

2) Currently you have two different network segments - one on eth0, and
another one on tun0 (that one).
Even if you make your openvpn encapsulate L2 traffic (don't), unless you
want to risk losing all network connectivity to your VPS by bridging
eth0 and tun0 *and* hacking openvpn scripts - I see no easy way to
bridge those two segments.

3) Likewise, you *could* put your eth0 in the promiscous mode, and write
some set of netfilter rules to traverse the gap between eth0 and tun0,
but that's wrong on so many levels that I don't know where to begin to
describe it.

In conclusion, your current NAT66 setup is probably the best you can
achieve without a risk to your VPS or your sanity ;)

Reco

[toc] | [prev] | [next] | [standalone]

#202828 — [SOLVED]: openvpn over ipv6 /65

On 27/11/2018 15:03, Reco wrote:

> In conclusion, your current NAT66 setup is probably the best you can
> achieve without a risk to your VPS or your sanity ;)
> 
OK Reco, that's great. I'm announcing a valid IPv6 address, so it's
achieving its objective. I can route traffic from any of my IOT boxes
over IPv6 to any other box. I can include a marker in any message to
indicate its origin. I can then communicate with them via their native
IPv6 addresses. I don't think I can want for any more, so I've marked
this as [SOLVED].

My next task is to write this all up, and try to understand what we've
been doing.

Thanks a million for your assistance, without which I'd still be
floundering.

Cheers, Tony.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web