fe80 is link local, consider it doesn't exist for your case.
And yet, according to the provider, it should have Your VPN IPv6: fde6:7a: etc etc
Somehow, OpenVPN is supposed to get it. If it is not pushed, is OpenVPN supposed to ask for it?
On my Windows-OpenVPN it does get pushed. By the same server even. It pushes both an ifconfig for the IPv6 and a DNS6 option.
EDIT: I just copied the vpn provider's conf file over to the OpenWRT and execute it manually from the CLI: openvpn --cd /etc/openvpn --config /etc/openvpn/AirVPN.conf
Lo and behold:
PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.7.148.1,dhcp-option DNS6 fde6:7a:7d20:38e::1,tun-ipv6,route-gateway 10.7.148.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:38e::1054/64 fde6:7a:7d20:38e::1,ifconfig 10.7.148.86 255.255.255.0,peer-id 4,cipher AES-256-GCM'
GDG6: remote_host_ipv6=2a00:1678:2460:29:1636:4986:4c28:ca88
GDG6: NLMSG_ERROR: error Permission denied
ROUTE6: 2000::/4 overlaps IPv6 remote 2a00:1678:2460:29:1636:4986:4c28:ca88, adding host route to VPN endpoint
ROUTE6: IPv6 route overlaps with IPv6 remote address, but could not determine IPv6 gateway address + interface, expect failure
/sbin/ifconfig tun0 10.7.148.86 netmask 255.255.255.0 mtu 1500 broadcast 10.7.148.255
/sbin/ifconfig tun0 add fde6:7a:7d20:38e::1054/64
/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.7.148.1
/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.7.148.1
add_route_ipv6(::/3 -> fde6:7a:7d20:38e::1 metric -1) dev tun0
/sbin/route -A inet6 add ::/3 dev tun0
add_route_ipv6(2000::/4 -> fde6:7a:7d20:38e::1 metric -1) dev tun0
/sbin/route -A inet6 add 2000::/4 dev tun0
add_route_ipv6(3000::/4 -> fde6:7a:7d20:38e::1 metric -1) dev tun0
/sbin/route -A inet6 add 3000::/4 dev tun0
add_route_ipv6(fc00::/7 -> fde6:7a:7d20:38e::1 metric -1) dev tun0
/sbin/route -A inet6 add fc00::/7 dev tun0
Initialization Sequence Completed
This push is a lot bigger. But since I copied the conf file option-by-option to uci, it should - in theory - respond the same. Unless OpenWRT is neglecting to pass some of the options through to OpenVPN. I will investigate some more.
Can somebody explain those 2 errors?
So, I checked. Literally did a cat /etc/openvpn/AirVPN.conf and translated each of those options to UCI format. No IPv6 push. So, I am going to create a bug report for the maintainers of the openvpn-openssl package. Part of the config is not getting pushed to OpenVPN. My guess is the setenv 'UV_IPV6 yes' since it is the only one that explicitly states IPv6.
First, I'll try and create a UCI config that refers to the config file though. It's not my preferred way, but if it works, at least I am yet another step closer to being back online and one step further away from yet another sleepless night figuring stuff out that should have just worked....
This is NUTS!
I completely removed both the openvpn package and config from my system, but as soon as I install the package, openvpn starts again on boot with a config that doesn't even exist anymore. I can't set any config active because he will always start this one first.
What is going on with this thing?!
the way it has been implemented is similar to;
- use traditional ( daemon general ) init... so if you have an .ovpn in /etc/openvpn/XYZ a starting daemon will fire that up.
- !if! there is a uci reference to that config... ( /etc/confg/openvpn -> "connection" -> enabled=1 ) then use that to either enable or disable the specific connection.
So,
- when you uninstalled... because your /etc/openvpn/XYZ.ovpn was not part of the original package install, it left it there... ( remove and ls -lah /etc/openvpn/
to verify this behavior ) - when you re-installed... it created a new /etc/config/openvpn ( uci config ) which has no reference to that .ovpn so it defaulted to the native daemon behavior.
( another thing is that files in /etc/openvpn/ named .conf VS .ovpn are treated differently... but the meaning escapes me right now )
If I recall correctly, one of them gets imported upon being loaded. Something like that.
Well since I couldn't get rid of it I just did a reset to defaults. My config is stored in a uci-script anyways.
At this point, avoiding previously made mistakes, it still won't route correctly:
cat /tmp/resolv.conf.vpn
nameserver 10.7.158.1
nameserver fde6:7a:7d20:38e::1
ping6 fde6:7a:7d20:38e::1
PING fde6:7a:7d20:38e::1 (fde6:7a:7d20:38e::1): 56 data bytes
--- fde6:7a:7d20:38e::1 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
ip -6 addr; ip -6 ru; ip -6 ro
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 532
inet6 fe80::6288:e0ff:feda:5316/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 532
inet6 fe80::6088:e0ff:feda:5316/64 scope link
valid_lft forever preferred_lft forever
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd30:89fc:4487::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::6088:e0ff:feda:5316/64 scope link
valid_lft forever preferred_lft forever
9: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:1c00:f24:fe00:6288:e0ff:feda:5316/64 scope global dynamic noprefixroute
valid_lft 47418sec preferred_lft 18618sec
inet6 2001:1c00:f24:fe00:8b10:e71d:7176:c6ad/128 scope global dynamic noprefixroute
valid_lft 52880sec preferred_lft 24080sec
inet6 fe80::6288:e0ff:feda:5316/64 scope link
valid_lft forever preferred_lft forever
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 100
inet6 fde6:7a:7d20:38e::1054/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::8c85:c6e1:3990:5c8d/64 scope link stable-privacy
valid_lft forever preferred_lft forever
0: from all lookup local
32766: from all lookup main
4200000001: from all iif lo failed_policy
4200000007: from all iif br-lan failed_policy
4200000009: from all iif eth1.2 failed_policy
4200000009: from all iif eth1.2 failed_policy
default from 2001:1c00:f24:fe00:8b10:e71d:7176:c6ad via fe80::ae22:5ff:fe50:6cc0 dev eth1.2 proto static metric 384 pref medium
default from 2001:1c00:f24:fe00::/64 via fe80::ae22:5ff:fe50:6cc0 dev eth1.2 proto static metric 384 pref medium
::/3 dev tun0 metric 1 pref medium
2001:1c00:f24:fe00::/64 dev eth1.2 proto static metric 256 pref medium
2001:1c00:f24:fe00::/64 via fe80::ae22:5ff:fe50:6cc0 dev eth1.2 proto static metric 512 pref medium
2000::/4 dev tun0 metric 1 pref medium
3000::/4 dev tun0 metric 1 pref medium
fd30:89fc:44e7::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd30:89fc:44e7::/48 dev lo proto static metric 2147483647 error 4294967183 pref medium
fde6:7a:7d20:38e::/64 dev tun0 proto kernel metric 256 pref medium
fc00::/7 dev tun0 metric 1 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth1.2 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
EDIT: Could something to do with the public ipv6 gateway endpoint setting ( tunnel outside )
or
Do you have a vpnfirewall stanza in /etc/config/firewall... that is set to masq=1?
Would you be really upset and refuse to help any further if I told you that after working on this for 13 hours straight and being extremely frustrated at what is now almost 6 in the morning... I forgot to add the TUN-interface and associated firewall rules?
I have now set the vpn over IPv4 using a static IP address without passing me any IPv6 information. I am going to slowly, very slowly re-add IPv6.
By the way, that error has been appearing since the start. I have no clue what it means...
I wouldn't stress too much at this point... there is enough info for a guru to spot what is going on... so take a break me thinks... give it a day or two for learnered eyes to spot the glitch.
( there are known working ipv6(only) configs... but i'm not sure about dual stack... )
This one keeps popping up too:
odhcpd[1596]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Oh, and as soon as I tell the VPN server to give me an IPv6 address, it stops working. So I can build an IPv6 tunnel just fine, but I can't have an IPv6 address at the end of that tunnel, it will stop all form of routing.
I also tried vpn-policy-routing with IPv6 support enabled. But nothing seems to work.
I really hope somebody can help out. It shouldn't be this hard to get this working.
I have not used IPv6 over OpenVPN tunnel like this, but I can spot a few things.
- You are still getting IPv6 from your provider and the default route you receive from VPN overlaps with that. It might be nothing, but if you decide to use only VPN for IPv6, you could disable wan6 in total.
- In principal default gateway will not be advertised if there is no public prefix. The error from odhcpd can be bypassed by instructing to always announce the default route (under lan interface, dhcp server tab, ipv6 settings)
@trendy
My ISP Hands out a public /64 range to its clients. OpenWRT by default requests a /60 block to hand out to its clients. As a matter of fact, I can't even disable the modem's DHCP6 server. I could - in theory - change the range my modem hands out into a private range, much like how it hands out a 192.168 address to OpenWRT. I have no idea what that would do to Internet connectivity though.
I would think that the scenario where an Internet-facing OpenWRT has a publicly routable IP but still would like to route certain traffic over the VPN tunnel is not uncommon and can be made to work.
If I disable WAN6, I would get no more IPv6 address, which would prevent me from establishing an IPv6 tunnel to my VPN provider. The reason why I got a new modem was to get an IPv6 address from my ISP and take advantage of it to build an IPv6 tunnel.
So the fact that the tunnel is pushing routes for 2000 and 3000 is causing a conflict then because my OpenWRT is 2001? Of course, there's little to do about the fe80's everywhere.
@anon50098793
My body took your advice a little too literally. I was so stressed out at that point I slept for almost 24 hours straight. I feel very weak right now.
Correction, I'm not allowed to set an fd-range on my ISP's modem. Guess I am stuck with the public IPv6 addresses. So how do I work around that? There has to be a way, right?
This is a joke, not an allocation.
I think by default doesn't have any preference and will just ask a prefix.
It doesn't make much difference if you setup the tunnel over v4 or v6.
I think it is more like a warning than anything serious.
These are link locals.
People keep saying that. Either way, 18,446,744,073,709,551,616 hosts is enough for my modest home. And short of filling a 19 inch rack, I doubt I have enough switch ports for it.
I do believe I read somewhere that /64 is considered common for residential connections.
Correct, it is set to auto. At which point the ISP's modem gives OpenWRT an address in the /64 range (or allow it to pick one, since it is stateless) and provides a /60 range to play with.
I figured IPv6 was a more resilient and efficient protocol, allowing for better negotiation and larger packets. Although I suppose since all hardware is still working dual-stack, it's still limited to 1500. To my annoyance, even an IPv6 tunnel still generates them nasty AEAD errors in OpenVPN as all my packets get fragmented.
Either way, this is what I've got now and I have to find a way to make it work. My home network has been disconnected for days now while I'm trying to get the VPN to work well.
So it's not that the router doesn't know if it should send a packet over the WAN or the TUN because they both exist in the same range?
I still would love to suppress them if it is fine this way. They are polluting a perfectly decent log.
I know. Which is why I said there was little to do about them. The vpn-policy-routing package loves them too when it creates a firewall table for the WAN.
I already disabled all the extra IP's that Windows makes by default. It's crazy to do an ipconifg and be confronted with at least 6 different IPv6 addresses.
In completely unrelated news, my VPN provider asked me to switch from UDP to TCP because of all my AEAD errors. If I establish the VPN tunnel on my PC while connected to the router, I reach 100Mbit, if I establish it on the router I reach 60Mbit. At that point the router is "only" using about 30% CPU. Odd.
That is incorrect, you might have enough plain IPv6 addresses - but you don't have prefixes to route or segment your network. The smallest prefix possible (without breaking SLAAC and more) is a /64, and if you need to route (such as in your case right now), you need at least two /64 prefixes (yes, that means one is wasted with just 1 active device, but that's still the nature of routing). of those.
Therefore recommendation for residential connections is at least /56, up to /48 on request (but without any justification needed). As trendy mentioned, an ISP only handing out a single /64 is a bad joke, be it because their mandatory router doesn't support DHCPv6-PD properly or because they've messed up their configuration, it makes it virtually impossible to use IPv6.
1 Like
If you say so, I obviously have a lot to learn about IPv6. I guess I'll have to make it work, and right now as soon as I tell the VPN provider to give me an IPv6 endpoint, I lose my route to said endpoint. But if I disable WAN6, I lose my ability to set up a tunnel over IPv6 (or get to sites running on 6 outside of the tunnel). If there is a way to make it work, I would love to learn.
That is not exactly true. You can have jumbo frames regardless of the IP protocol.
But this is not your issue here.
The router knows where to send the packet, don't worry about that.
Unless there is an issue, I don't think you are going to read the logs. This could be suppressed if you reduced the logging verbosity.
I'm an IT infra admin, I love reading logs. 
Unfortunately, my CCNA is a bit... outdated.
So, to get back to the issue. The problem exists the instant my VPN provider gives me an IPv6 address as an exit point. At that point OpenWRT is no longer able to reach anything, thus also unable to reach the VPN server to renew its keys. A few minutes later, the tunnel is gone. Barely enough time to test anything.
As far as the Jumbo frames go, I do believe the IPv6 frames can go a teensy bit higher compared to IPv4. But it's a moot point if everything in between uses 1500. It's the main reason I haven't turned them on in my home network. I don't know what the performance impact is if OpenWRT has to fragment all those packages every time my computers want to talk to the Internet.