Wireguard Session Manager - Discussion (2nd) thread

[archiel]

Still wgm doesnt add a default route for ipv6. Are you client in default (ALL auto=y/n) mode or Policy (auto=p) mode. Looks like default, so you could add the route manually meanwhile:

ip -6 route add 0::/1 dev wg11
ip -6 route add 8000::/1 dev wg11

For now I am in default mode, with the intention of swapping to policy mode once I have the former working.
Adding the routes now means that browsing to Azire shows me as connected with no signs of any DNS leaks (IPv4 or IPv6) but Diversion is no longer working on any LAN devices.

I am also getting some other issues:
test-ip6.com ‘your DNS server (possibly run by your ISP) appears to have no access to the IPv6 internet or is not configured to use it.
ipleak.net shows an IPv6 address but only the IPv4 server
broswerleaks.com shows an IPv6 address but only the IPv4 DNS server
ipv6-test.com DNS4+IP6, DNS6 + IP4 reachable, DNS6 + IP6 unreachable

However this may be to do with the Azire setup as disabling Wireguard and running it just on my phone (android 12) and a couple of PCs (Windows 10 & 11) has the same results, but on a Ubuntu 20.04 LTS VM, running on Windows Hyper-V both test-ip6.com and ipv6-test.com are fine. I am going to setup a Mullvad connection to test whether the issue is generic or Azire specific.

 

[ZebMcKayhan]

For now I am in default mode, with the intention of swapping to policy mode once I have the former working.
Adding the routes now means that browsing to Azire shows me as connected with no signs of any DNS leaks (IPv4 or IPv6) but Diversion is no longer working on any LAN devices.

I am also getting some other issues:
test-ip6.com ‘your DNS server (possibly run by your ISP) appears to have no access to the IPv6 internet or is not configured to use it.
ipleak.net shows an IPv6 address but only the IPv4 server
broswerleaks.com shows an IPv6 address but only the IPv4 DNS server
ipv6-test.com DNS4+IP6, DNS6 + IP4 reachable, DNS6 + IP6 unreachable

However this may be to do with the Azire setup as disabling Wireguard and running it just on my phone (android 12) and a couple of PCs (Windows 10 & 11) has the same results, but on a Ubuntu 20.04 LTS VM, running on Windows Hyper-V both test-ip6.com and ipv6-test.com are fine. I am going to setup a Mullvad connection to test whether the issue is generic or Azire specific.

Maybee this helps shed some light:
https://github.com/ZebMcKayhan/WireguardManager#why-is-diversion-not-working-for-wg-clients

 

[archiel]

Maybee this helps shed some light:
https://github.com/ZebMcKayhan/WireguardManager#why-is-diversion-not-working-for-wg-clients

Thanks, I will try this shortly and see if it is compatible with Azire / Mullvad

In respect of
test-ip6.com ‘your DNS server (possibly run by your ISP) appears to have no access to the IPv6 internet or is not configured to use it.
ipleak.net shows an IPv6 address but only the IPv4 server
broswerleaks.com shows an IPv6 address but only the IPv4 DNS server
ipv6-test.com DNS4+IP6, DNS6 + IP4 reachable, DNS6 + IP6 unreachable

It looks like Mullvad may not help (I have contacted their support desk) as their default conf files do not provide any IPV6 DNS and the IPV6 addresses they use for the tunnel are ULA rather than GUA.

 

[ZebMcKayhan]

Thanks, I will try this shortly and see if it is compatible with Azire / Mullvad

In respect of
test-ip6.com ‘your DNS server (possibly run by your ISP) appears to have no access to the IPv6 internet or is not configured to use it.
ipleak.net shows an IPv6 address but only the IPv4 server
broswerleaks.com shows an IPv6 address but only the IPv4 DNS server
ipv6-test.com DNS4+IP6, DNS6 + IP4 reachable, DNS6 + IP6 unreachable

It looks like Mullvad may not help (I have contacted their support desk) as their default conf files do not provide any IPV6 DNS and the IPV6 addresses they use for the tunnel are ULA rather than GUA.

Well, Thats too bad, altough you dont actually need an ipv6 dns. You get ipv6 lookup on ipv4 dns as well.
Howabout using Unbound, it will solve all these problems.

Edit: I also have ULA as tunnel address but it does not affect anything since you masquarade

 

[archiel]

Well, Thats too bad, altough you dont actually need an ipv6 dns. You get ipv6 lookup on ipv4 dns as well.
Howabout using Unbound, it will solve all these problems.

I agree that I can get IPv6 addresses over DNSv4. What I am trying to see if I can also get them over DNSv6 - it is not critical, but it would be nice.
I am already using Unbound - but maybe I need to tweak my settings.

 

[archiel]

@ZebMcKayhan Looking at your notes on Unbound with WireGuard I can see two methods of redirecting the traffic through unbound (I had already tested @eibgrad's method for IPv4 over OpenVPN), but have a couple of questions on each

While I am quite happy to follow

outgoing-interface: 192.168.1.1 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
outgoing-interface: aaff:a37f:fa75:1::1 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)

But I have a dynamic IPv6 GUA address. So either I need a means to pull this from nvram (as we have done for the 'road warrior' setup) into unbound.conf (I just cannot get unbound.conf.add to work) or do this in init-start, which may be easier. Alternatively does this need to use my real WAN ULA, might this work with a spoofed GLA-to-ULA address as it does for the road warrior setup?

When I set this up for OpenVPN I used wan-start rather than init-start

ifconfig br0:1 192.168.3.1 netmask 255.255.255.255

is one better than the other and if I want to add {ipv6address} netmask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, can I (should I) add it to the above or add a new line? each attempt at adding ipv6 to br0:1 like

ifconfig br0:1 add aaff:a37f:fa75:1::1/128

results with adding it to br0, not sure how this affects matters.

 

[archiel]

Update - if I edit unbound.conf to include

outgoing-interface: 10.50.60.1
outgoing-interface: aaff:a37f:fa75:1::1

and change the wg11 DNS to

peer wg11 dns=10.50.60.1,aaff:a37f:fa75:1::1

Then I immediately start leaking on IPv6

The same happens if I do not include the ipv6 interfaces, i.e.

outgoing-interface: 10.50.60.1
#outgoing-interface: aaff:a37f:fa75:1::1

and change the wg11 DNS to

peer wg11 dns=10.50.60.1

 

[ZebMcKayhan]

Update - if I edit unbound.conf to include

outgoing-interface: 10.50.60.1
outgoing-interface: aaff:a37f:fa75:1::1

and change the wg11 DNS to

peer wg11 dns=10.50.60.1,aaff:a37f:fa75:1::1

Then I immediately start leaking on IPv6

The same happens if I do not include the ipv6 interfaces, i.e.

outgoing-interface: 10.50.60.1
#outgoing-interface: aaff:a37f:fa75:1::1

and change the wg11 DNS to

peer wg11 dns=10.50.60.1

Starting to glimpse on exactly how complex these setup could get.

As you are using default routing, then there should not be any need to use outgoing-interface in unbound. But if you want to put something there, use your wg11 ipv4/ipv6. But it will probably bork if wg11 is brought down. If you dont use the option at all unbound will rotate and use all your interface which will all point to wg11. But you may need to look over wg11 masquarading rule.

ip6tables -nvL POSTROUTING -t nat

So it covers your entire lan.

Didn't think ip alias worked for ipv6 as you could add how many addresses you like to any interface. Sure, create an ula (or modified) on br0 and point your dns to this one but never tried this. Hope dnsmasq listening on this ip as well.

Leaks could mean your dnat redirect is not working, check out

ip6tables -nvL PREROUTING -t nat
ip6tables -nvL WGDNS1 -t nat

Are you sure your ipv4 and ipv6 is working over wg11?

 

[archiel]

Just realised that I have been testing without adding the routing from #915! I am going to add these to wg11-up and wg11-down and then start again

 

[ZebMcKayhan]

Just realised that I have been testing without adding the routing from #915! I am going to add these to wg11-up and wg11-down and then start again

Great find!

For the future, I was thinking that as you have dynamic ip, it got be a good idea to add a fixed ipv6 to br0 (as you proposed). I though it had to be like:

ip -6 address add dev br0 aaaa:bbbb:cccc:dddd::1/128

And it should probably be in the vincinity (/48) of your wg21 IP (lets not make things more complicated than it already is).

But dhcp-ra gives out ip based on br0 ip, so check so it doesn't give out this ip to br0 clients as it might complicate things.

If successful, use PingTools and Point dns-server to this ip and see if you could dns lookup something. If possible then dnsmasq listens to this ip and you could use it in wgm to control lan ipv6 dns lookup (exclusive). This would further come handy when switching to policy based routing for Unbound outgoing-interface and to setup routing rules for unbound to lookup via wg11.

Sadly I still have not found any reliable way to policy route ipv6 lan clients. One of the drawbacks of stateless assignement is that router has no control over which ip a device gets. Dynamic prefix further complicates it but is atleast obtainable from the router. I imagine something where clients register themself and their ip is the intended way. I've been trying to ask acouple of times here but no response.

 

[archiel]

Great find!

For the future, I was thinking that as you have dynamic ip, it got be a good idea to add a fixed ipv6 to br0 (as you proposed). I though it had to be like:

ip -6 address add dev br0 aaaa:bbbb:cccc:dddd::1/128

And it should probably be in the vincinity (/48) of your wg21 IP (lets not make things more complicated than it already is).

But dhcp-ra gives out ip based on br0 ip, so check so it doesn't give out this ip to br0 clients as it might complicate things.

If successful, use PingTools and Point dns-server to this ip and see if you could dns lookup something. If possible then dnsmasq listens to this ip and you could use it in wgm to control lan ipv6 dns lookup (exclusive). This would further come handy when switching to policy based routing for Unbound outgoing-interface and to setup routing rules for unbound to lookup via wg11.

Sadly I still have not found any reliable way to policy route ipv6 lan clients. One of the drawbacks of stateless assignement is that router has no control over which ip a device gets. Dynamic prefix further complicates it but is atleast obtainable from the router. I imagine something where clients register themself and their ip is the intended way. I've been trying to ask acouple of times here but no response.

Turns out that may not be necessary, at least for default routing. Starting from your section on diversion I changed the wg11 DNS to the LAN and Link-local addresses on br0

peer wg11 dns=10.50.60.1,fe80::aaaa:5555:eeee:xxxx

Turns out though you cannot use link-local ranges for [Interface]Address it is not an issue for DNS
For now I have not added anything to unbound (though this may be needed for policy based routing)
IPv4, IPv6, DNSv4 & DNSv6 working and no leaks (browserleaks,test-ipv6,ipv6-test and ipleak.net).

 

[ZebMcKayhan]

Turns out though you cannot use link-local ranges for [Interface]Address it is not an issue for DNS
For now I have not added anything to unbound (though this may be needed for policy based routing)
IPv4, IPv6, DNSv4 & DNSv6 working and no leaks (browserleaks,test-ipv6,ipv6-test and ipleak.net).

meaning it did not work to put it in wgm? don't know how static the link-local address is but if it is, then for the sake of redirecting DNS back to local it would work since everything is happening on the router. just remember that the link-local addresses are only valid for the link. so not valid beyond, say, a switch. so you shouldn't try to advertise this address to clients.

 

[archiel]

meaning it did not work to put it in wgm? don't know how static the link-local address is but if it is, then for the sake of redirecting DNS back to local it would work since everything is happening on the router. just remember that the link-local addresses are only valid for the link. so not valid beyond, say, a switch. so you shouldn't try to advertise this address to clients.

Not sure what you mean by 'it did not work to put it in wgm?' As we have already tested, trying to add fe:: address ranges will be rejected by wgm (fc:: and fd:: will be accepted by just don't appear to work), but I had not previously tried adding to the DNS field. Using peer {device} dns={router link local} did not generate any error warnings

Also I thought the sole(?) function here is to tell traffic travelling over the VPN tunnel starting on the router that it should be using the local (router defined) DNS servers. As we are only using the link-local address as an information field (use this DNS) and not as a device address (which would be restricted in how it could be routed) I do not follow in what circumstances I might 'try to advertise this address to clients' and/or where it would break - can you clarify?

In respect of the stickiness of the link-local range, I do not think I have seen it change on the router. The addresses assigned to particular devices may move (I have not tracked this) but the range seems to stay constant (so the router's address will also be effectively static), looking at mine I would guess that it is using a MAC based rule and is unlikely to change.

 

[ZebMcKayhan]

I had not previously tried adding to the DNS field. Using peer {device} dns={router link local} did not generate any error warnings

ok, cool... well, you will find out if it's working or not when switching to policy based routing.

Also I thought the sole(?) function here is to tell traffic travelling over the VPN tunnel starting on the router that it should be using the local (router defined) DNS servers. As we are only using the link-local address as an information field (use this DNS) and not as a device address (which would be restricted in how it could be routed) I do not follow in what circumstances I might 'try to advertise this address to clients' and/or where it would break - can you clarify?

when used in wgm, there will be a firewall rule to alter all DNS request via DNAT to change the destination address to whatever address you put here. so it will be kind of DNS filter to redirect everything (as Exclusive in OpenVPN) in this case the address is basically redirected on the router, to the router so, in theory, link-local would work. just meaning that dont put this address in the gui to be advertised to the clients to be used as DNS, it could cause problems as this address may not be valid for them.

In respect of the stickiness of the link-local range, I do not think I have seen it change on the router. The addresses assigned to particular devices may move (I have not tracked this) but the range seems to stay constant (so the router's address will also be effectively static), looking at mine I would guess that it is using a MAC based rule and is unlikely to change.

ok, great! did not actually keep track of mine.

 

[archiel]

ok, cool... well, you will find out if it's working or not when switching to policy based routing.


when used in wgm, there will be a firewall rule to alter all DNS request via DNAT to change the destination address to whatever address you put here. so it will be kind of DNS filter to redirect everything (as Exclusive in OpenVPN) in this case the address is basically redirected on the router, to the router so, in theory, link-local would work. just meaning that dont put this address in the gui to be advertised to the clients to be used as DNS, it could cause problems as this address may not be valid for them.


ok, great! did not actually keep track of mine.

So we have a working method for dual stack from 'road warrior' to Router and the same from LAN devices>Router>external VPN provider for default routing.
Next things to try- policy based routing, passthrough (phone, etc. to external), then making all DNS lookups (not just those from LAN clients) go though the VPN

 

[ZebMcKayhan]

So we have a working method for dual stack from 'road warrior' to Router and the same from LAN devices>Router>external VPN provider for default routing.
Next things to try- policy based routing, passthrough (phone, etc. to external), then making all DNS lookups (not just those from LAN clients) go though the VPN

Don't forget to remove your added ipv6 default route when you put your client in policy mode.

 

[archiel]

Not unexpectedly switching to policy based routing leads to IPv6 leaks (my IPv6 address in Browserleaks shows as the ISP IPv6 and the IPv6 DNS the same) and I am guessing this is because I am only telling the IPv4 traffic (10.50.60.nnn) on a selected device to go through the VPN. Reverting to the Azire assigned DNS servers did not assist.

 

[ZebMcKayhan]

Not unexpectedly switching to policy based routing leads to IPv6 leaks (my IPv6 address in Browserleaks shows as the ISP IPv6 and the IPv6 DNS the same) and I am guessing this is because I am only telling the IPv4 traffic (10.50.60.nnn) on a selected device to go through the VPN. Reverting to the Azire assigned DNS servers did not assist.

Having only a single computer over vpn could prove difficult with ipv6. ideally you should make an ipv6 rule for the computer ip in wgm, but the device could have many ip, so use the right one (or all).

Regarding DNS it follows the same pattern in Policy mode. whenever the rules are working, so shall (hopefully) the DNS redirect as well. But device ipv6 could be changing and I dont know how to deal with that.

Or use Unbound with br0 IP and point everything there.