Resolving Issues with TunSafe and WireGuard on Windows

WireGuard is an incredibly versatile VPN implementation. It’s incredibly fast, snappy and lightweight, but it comes with some incredibly finicky errors with it, that generally come from obscure config problems. There isn’t a ton of documentation behind these issues (but there’s a great community behind WireGuard that’s always willing to jump in and help).

Tunnel Error – IPv6 Binding (WireGuard for Windows, Pre-Alpha)

I recently installed the WireGuard Pre-Alpha for Windows. and encountered the dreaded Tunnel Error Prompt.

Unable to set interface addresses, routes, dns and/or adapter settings.

Please consult the log for more information.

I found that the issue was caused by the addition of ::/0 within the AllowedIPs parameter, when my server did not support IPv6. The Wireguard Pre-Alpha for Windows client doesn’t seem to like that very much.

After removing that parameter, and restarting my computer (to confirm that it wasn’t the WinTun driver acting up), I was able to initiate the WireGuard tunnel.

TunSafe doesn’t seem to suffer from the same issue. TunSafe will accept the ::/0 and ::0/0 paramters for AllowedIPs, but simply ignore it, causing your IPv6 to leak if you have IPv6 network adapters enabled.

IPv6 Leaking (TunSafe and WireGuard)

If your WireGuard server does not support IPv6, and the client is using IPv6, WireGuard will leak your IPv6 by default. There is no workaround for this other than disabling your IPv6 network adapters while using WireGuard on Windows.

If your WireGuard server does support IPv6, it is imperative that you add ::0/0 or ::/0 to your AllowedIPs parameter to ensure that it is capable of routing IPv6.

An example Peer block for your client config goes along as follows

[Peer]
PublicKey = pubkey___qwdijqwdqoiwdoijDOJIASD
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = ip:port
PersistentKeepalive = 25

DNS Issues (TunSafe)

TunSafe does not support WireGuard config files with more than one DNS address attached to the config. When using TunSafe, your DNS parameter should look like:

DNS = 8.8.8.8

Instead of:

DNS = 8.8.8.8,8.8.4.4

The Open Government License + freedom of information and privacy laws

Open data and open government are great initiatives that are increasingly being adopted by Canadian municipalities. Many municipalities and provincial governments license their open data under a modified variation of the Open Government License (UK 3.0).

The license itself is generally fairly permissive in practice. It allows you to copy, publish, transmit, adapt and commercially exploit OGL-licensed information in return for an attribution statement.

However, in recent times, this license has been complicated through freedom of information and privacy laws. One principle aspect of freedom of information is that it is not absolute.

Freedom of information and privacy laws dictate what information that governments may legally withhold, must withhold, or must withhold until consulting with relevant parties. This can range from contractual obligations, to sensitive information, to personal and private information.

In many ways, this is a bit confusing. If governments deliberately go out of their way to release open data, why would open datasets include information that could or must be withheld? Would it not be reasonable to conclude that the information released has nothing that is subject to an exception?

The issue lies in the details. How can you be sure that a OGL-licensed dataset with freedom of information provisions is truly free of exempt material?

Government employees are not infallible and make the same mistakes as you and I.

Therefore, OGL licenses with provisions for freedom of information laws are non-free licenses, that present limitations on its full and absolute use. If you create a product that inadvertently contains information that cannot be released under freedom of information laws, you put your product in a legal grey zone, because it could contain data that you were not legally licensed to use.

One potential workaround, is to make freedom of information requests for already-released open datasets. This effectively ensures that each released dataset is properly reviewed by a freedom of information specialist. The response to your request would confirm that the data can be used in full because it contains no information subject to exceptions, or you would receive a sanitized dataset with all exceptioned data removed.

However, I’m not a lawyer and I can’t say with any certainty whether this could be a final solution that absolves users of modified-OGL licensed content from blame and liability

Source: Paul Norman on the OpenStreetMap Talk-CA mailing list