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
