WFP on Windows 8 or greater. This is done because
Windows Vista and 7 depend on the adapter binding
order for DNS routing, and using WFP might cause
DNS failures if the local interface has a higher
binding order than the TAP adapter.
registry settings for DNS routing on Win 8 and higher.
We are now using these three approaches (simultaneously)
for DNS routing/filtering:
1. NRPT for routing (Win 8 and higher)
2. WFP for filtering (Win Vista and higher)
3. "netsh interface ip set dnsservers ..." (Win Vista and
higher)
The NRPT approach also supports selective DNS routing for
split tunnel via "dhcp-option DOMAIN ..." directive, where
DOMAIN is a DNS suffix. Note however that on Win 10, only
the first DOMAIN suffix given was actually routed through
the tunnel, and subsequent suffixes were ignored.
Previously, the first domain in the "dhcp-option DOMAIN ..."
list was used to set a default TAP-adapter domain suffix,
but I've disabled this behavior as it seems to be archaic
usage and conflicts with the modern usage of "dhcp-option
DOMAIN ..." as a selector for DNS suffix routing. Let me
know if you disagree.
preventing DNS leakage.
Filter #1 -- permit IPv4 DNS requests from OpenVPN app
Filter #2 -- permit IPv6 DNS requests from OpenVPN app
Filter #3 -- block IPv4 DNS requests from other apps
Filter #4 -- block IPv6 DNS requests from other apps
Filter #5 -- allow IPv4 traffic from TAP
Filter #6 -- allow IPv6 traffic from TAP
This change has the unfortunate side-effect of causing
lags in DNS resolution, so for now the capability is
disabled in tunsetup.hpp, pending evaluation of
NRPT-based approaches.
chars is passed to this template method:
template <typename V>
std::string encode(const V& data) const
The problem is that references to data[] were failing to
cast the value to unsigned char, so UTF-8 chars >= 0x80
were being interpreted as negative values.
ClientAPI::Config::ipv6 string:
IPv6 preference
no -- disable IPv6, so tunnel will be IPv4-only
yes -- request combined IPv4/IPv6 tunnel
default (or empty string) -- leave decision to server
bool ClientAPI::Config::autologinSessions and default
to false. Previously, the logic was hardcoded to true.
Autologin Sessions can be enabled in the cli.cpp wrapper
using the -a flag.
to "auth-token-request" to request the server to issue an
Autologin Session.
ClientCreds::set_session_id() now also accepts a username
argument, since the combination of username/token-id
defines the session.
