Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Fri, Jul 10, 2020 at 06:48:26PM +0200, Jan Just Keijser wrote: > > It's just a comment, but if that is wrong, it's not helpful in trying to > > understand the code. > > > just submitted patch v4 but forgot to fix that: richard is right 29 > decimal is 0x1D - or just 29, I guess - not 0x13 > > Want a v5 for that :P ? If the rest is working nicely, I usually fix comment or commit message errors (if the proposer agrees) on the fly. So, will test v4 tomorrow, and then report back :-) While I couldn't sleep a few nights ago, I came up with a more elegant approach than strtok()/strchr()/strsep() though... just walk the string, remember where to put the lenght byte, and every time you hit a "." or "\0", put (p-lenght_p)-1 into *length_p and remember the current position as new "length_p"... less code, no remainder to deal with, and single-pass... :-) - so if v4 is not working yet, that might be another thing for v5. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi all, On 08-Jul-20 10:24, Gert Doering wrote: On Tue, Jul 07, 2020 at 06:14:25PM +0200, Jan Just Keijser wrote: This one works(!), so generally, Win10 accepts this DHCP option - but it seems to want "all domains in one". Can you send a v3? not sure if all went well , but here's V3. Unfortunately not, that one seems to be based on your V1 patch, so we have "remove 'SEARCH', add 'DOMAIN-SEARCH'" hunks... diff --git a/src/openvpn/options.c b/src/openvpn/options.c index e59b22b..85f1d8a 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -726,7 +726,7 @@ static const char usage_message[] = "which allow multiple addresses,\n" "--dhcp-option must be repeated.\n" "DOMAIN name : Set DNS suffix\n" -"SEARCH name : Set DNS domain search list\n" +"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n" This is ok for me to have a look, but to actually merge I need something that applies "as it is" on top of master... diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index eed9ae6..60a149c 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -5567,46 +5567,70 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error) buf_write(buf, str, len); } +/* + * RFC3397 states that multiple searchdomains are encoded as follows: + * - at start the length of the entire option is given + * - each subdomain is preceded by its length + * - each searchdomain is separated by a NUL character + * e.g. if you want "openvpn.net" and "duckduckgo.com" then you end up with + * 0x13 0x7 openvpn 0x3 net 0x00 0x0A duckduckgo 0x3 com 0x00 + */ Richard commented on IRC that the "0x13" does not seem to be right here - adding up all of it (1+7+1+3+1+1+10+1+3+1 = 29). Can you double-check? It's just a comment, but if that is wrong, it's not helpful in trying to understand the code. just submitted patch v4 but forgot to fix that: richard is right 29 decimal is 0x1D - or just 29, I guess - not 0x13 Want a v5 for that :P ? cheers, JJK ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On Tue, Jul 07, 2020 at 06:14:25PM +0200, Jan Just Keijser wrote:
> > This one works(!), so generally, Win10 accepts this DHCP option - but
> > it seems to want "all domains in one".
> >
> > Can you send a v3?
> >
> not sure if all went well , but here's V3.
Unfortunately not, that one seems to be based on your V1 patch, so
we have "remove 'SEARCH', add 'DOMAIN-SEARCH'" hunks...
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index e59b22b..85f1d8a 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -726,7 +726,7 @@ static const char usage_message[] =
> "which allow multiple addresses,\n"
> "--dhcp-option must be repeated.\n"
> "DOMAIN name : Set DNS suffix\n"
> -"SEARCH name : Set DNS domain search list\n"
> +"DOMAIN-SEARCH entry : Add entry to DNS domain
> search list\n"
This is ok for me to have a look, but to actually merge I need something
that applies "as it is" on top of master...
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index eed9ae6..60a149c 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -5567,46 +5567,70 @@ write_dhcp_str(struct buffer *buf, const int type,
> const char *str, bool *error)
> buf_write(buf, str, len);
> }
>
> +/*
> + * RFC3397 states that multiple searchdomains are encoded as follows:
> + * - at start the length of the entire option is given
> + * - each subdomain is preceded by its length
> + * - each searchdomain is separated by a NUL character
> + * e.g. if you want "openvpn.net" and "duckduckgo.com" then you end up with
> + * 0x13 0x7 openvpn 0x3 net 0x00 0x0A duckduckgo 0x3 com 0x00
> + */
Richard commented on IRC that the "0x13" does not seem to be right here
- adding up all of it (1+7+1+3+1+1+10+1+3+1 = 29). Can you double-check?
It's just a comment, but if that is wrong, it's not helpful in trying to
understand the code.
> static void
> -write_dhcp_search_str(struct buffer *buf, const int type, const char *str,
> bool *error)
> +write_dhcp_search_str(struct buffer *buf, const int type, const char * const
> *str_array,
> + int array_len, bool *error)
> {
> -const char *ptr = str, *dotptr = str;
> -int i, j;
> +char tmp_buf[256];
> +int i;
> +int len = 0;
> +
> +for (i=0; i < array_len; i++)
> +{
> +const char *ptr = str_array[i], *dotptr = str_array[i];
> +int j, k;
> +
> +msg(M_INFO, "Processing '%s'", ptr);
> +
> +if (strlen(ptr) + len + 1 > sizeof(tmp_buf))
> +{
> +*error = true;
> +msg(M_WARN, "write_dhcp_search_str: temp buffer overflow
> building DHCP options");
> +return;
> +}
> +/* Loop over all subdomains separated by a dot and replace the dot
> + with the length of the subdomain */
> +while ((dotptr = strchr(ptr, '.')) != NULL)
> +{
> +j = dotptr - ptr;
> +tmp_buf[len++] = j;
> +for (k=0; k < j; k++) tmp_buf[len++] = ptr[k];
> +ptr = dotptr + 1;
> +}
> +
> +/* Now do the remainder after the last dot */
> +j = strlen(ptr);
> +tmp_buf[len++] = j;
> +for (k=0; k < j; k++) tmp_buf[len++] = ptr[k];
This should work. It might be possible to do this with slightly less
code with strsep() (which will give you nicely null-terminated chunks,
including "the remainder", but will require a writeable copy of the string).
It's overflow safe, so "good enough".
The restriction to max. 10 search domains sounds reasonable to me - since
the total string is limited, and we do not implement multiple options
(*and* windows 10 is, by observation, ignoring more than one anyway) this
is "good enough for all reasonable deployments".
Can I have a v4, please? :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On 06/07/20 18:15, Gert Doering wrote:
Hi,
On Tue, Jun 30, 2020 at 04:15:58PM +0200, Jan Just Keijser wrote:
On 30/06/20 16:11, Gert Doering wrote:
On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
struct tuntap_options *o)
write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, );
+for (int i=0; i < o->domain_search_list_len; i++)
+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
+}
I assume that this won't work. In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.
see https://tools.ietf.org/html/rfc3397
"
In the above diagram, Searchstring is a string specifying the
searchlist. If the length of the searchlist exceeds the maximum
permissible within a single option (255 octets), then multiple
options MAY be used, as described in "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
].
"
so you MAY use this option multiple times - and wireshark groks it fine. I
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do
that for me.
I did test, and my initial suspicion was correct - Windows accepts the
option, but only one of them.
I am pushing
dhcp-option DOMAIN-SEARCH v6.de,dhcp-option DOMAIN-SEARCH
leo.org,dhcp-option DOMAIN-SEARCH ov.greenie.net,dhcp-option DOMAIN-SEARCH
nekosoft.de
(because these are domains that have more interesting hostnames in than
just "www" and "mail", so I can see if "v4only.v6.de" is found, or
"dict.leo.org")
and "ipconfig /all" only shows the "nekosoft.de" one.
This one works(!), so generally, Win10 accepts this DHCP option - but
it seems to want "all domains in one".
Can you send a v3?
not sure if all went well , but here's V3.
cheers,
JJK
>From 2a7f199252ddaf1bccf1eb399d26adc0a5aca137 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser
Date: Tue, 7 Jul 2020 18:10:15 +0200
Subject: [PATCH] [V3] Added support for DHCP option 119 (dns search suffix
list) for Windows. As of Windows 10 1809 Windows finally supports this so it
makes sense to add support to OpenVPN as well.
Signed-off-by: Jan Just Keijser
---
src/openvpn/options.c | 34 ++---
src/openvpn/tun.c | 101 --
src/openvpn/tun.h | 9 +++--
3 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index e59b22b..85f1d8a 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -726,7 +726,7 @@ static const char usage_message[] =
"which allow multiple addresses,\n"
"--dhcp-option must be repeated.\n"
"DOMAIN name : Set DNS suffix\n"
-"SEARCH name : Set DNS domain search list\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n"
"DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
"NTP : Set NTP server address(es)\n"
"NBDD: Set NBDD server address(es)\n"
@@ -1150,6 +1150,20 @@ parse_hash_fingerprint(const char *str, int nbytes, int msglevel, struct gc_aren
#ifndef ENABLE_SMALL
static void
+show_dhcp_option_list(const char *name, const char * const*array, int len)
+{
+int i;
+for (i = 0; i < len; ++i)
+{
+msg(D_SHOW_PARMS, " %s[%d] = %s",
+name,
+i,
+array[i] );
+}
+}
+
+
+static void
show_dhcp_option_addrs(const char *name, const in_addr_t *array, int len)
{
struct gc_arena gc = gc_new();
@@ -1176,7 +1190,6 @@ show_tuntap_options(const struct tuntap_options *o)
SHOW_BOOL(dhcp_renew);
SHOW_BOOL(dhcp_pre_release);
SHOW_STR(domain);
-SHOW_STR(domain_search_list);
SHOW_STR(netbios_scope);
SHOW_INT(netbios_node_type);
SHOW_BOOL(disable_nbt);
@@ -1185,6 +1198,7 @@ show_tuntap_options(const struct tuntap_options *o)
show_dhcp_option_addrs("WINS", o->wins, o->wins_len);
show_dhcp_option_addrs("NTP", o->ntp, o->ntp_len);
show_dhcp_option_addrs("NBDD", o->nbdd, o->nbdd_len);
+show_dhcp_option_list("DOMAIN-SEARCH", o->domain_search_list, o->domain_search_list_len);
}
#endif /* ifndef ENABLE_SMALL */
@@ -7329,10 +7343,6 @@ add_option(struct options *options,
{
o->domain = p[2];
}
-else if (streq(p[1], "SEARCH") && p[2])
-{
-o->domain_search_list = p[2];
-}
else if (streq(p[1], "NBS") && p[2])
{
o->netbios_scope = p[2];
@@ -7373,6 +7383,18 @@ add_option(struct options *options,
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Thu, Jul 02, 2020 at 11:04:41PM +0200, David Sommerseth wrote: > Can we please see this discussion also in context of this mail thread, which > tries to look a broader at this challenge? There's two things here - a small and useful featurette which can go into 2.5, and the broader negotiation / option rehaul work for 2.6. > The main purpose of that RFC is to ensure we handle DNS and --dhcp-options > consistently across all OpenVPN implementations we care about, and that we > document this properly. As far as I understand, jjk's patch is in line with what Tunnelblick already does on MAC, and does not conflict with the larger plan. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On Tue, Jun 30, 2020 at 04:15:58PM +0200, Jan Just Keijser wrote:
> On 30/06/20 16:11, Gert Doering wrote:
> > On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
> >> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
> >> struct tuntap_options *o)
> >> write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len,
> >> );
> >> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
> >> );
> >>
> >> +for (int i=0; i < o->domain_search_list_len; i++)
> >> +{
> >> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
> >> +}
> > I assume that this won't work. In the DHCP answer, it must be a single
> > option with the concatenated list, not multiple answers with a single
> > domain name each.
>
> see https://tools.ietf.org/html/rfc3397
>
> "
>
> In the above diagram, Searchstring is a string specifying the
> searchlist. If the length of the searchlist exceeds the maximum
> permissible within a single option (255 octets), then multiple
> options MAY be used, as described in "Encoding Long Options in the
> Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
> ].
>
> "
> so you MAY use this option multiple times - and wireshark groks it fine. I
> don't have a Windows 10
> client to test it against, however, so I am hoping that someone (Selva?) can
> do that for me.
I did test, and my initial suspicion was correct - Windows accepts the
option, but only one of them.
I am pushing
dhcp-option DOMAIN-SEARCH v6.de,dhcp-option DOMAIN-SEARCH leo.org,dhcp-option
DOMAIN-SEARCH ov.greenie.net,dhcp-option DOMAIN-SEARCH nekosoft.de
(because these are domains that have more interesting hostnames in than
just "www" and "mail", so I can see if "v4only.v6.de" is found, or
"dict.leo.org")
and "ipconfig /all" only shows the "nekosoft.de" one.
This one works(!), so generally, Win10 accepts this DHCP option - but
it seems to want "all domains in one".
Can you send a v3?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On 03/07/20 11:18, Arne Schwabe wrote: The main purpose of that RFC is to ensure we handle DNS and --dhcp-options consistently across all OpenVPN implementations we care about, and that we document this properly. I see one as an implementation issue (can we specify a particular DHCP option more than once) and one as an OpenVPN protocol issue. I fully agree that it's time to think about and overhaul the DNS settings for OpenVPN but I also believe that further abusing the option 'dhcp-option' is not the best way forward. The option 'dhcp-option' only really applies to the Windows tap-win adapter as that is the only adapter where you can use DHCP to add/change settings. This not even remotely true anymore. Basically all platforms will accept the dhcp-options for modifying the DNS settings. AFAIK even the new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-' is moot. Yes. Of course we can specify nicer sounding names for these options and that also break all kind of backwards compatibility for little gain or we document that the dhcp- prefix in these options is for historic reasons. I should have worded it more carefully, but Jonathan beat me to it: On 03/07/20 11:30, Jonathan K. Bullard wrote: > If you mean the term 'dhcp' should not be used in the name of the > option, I agree. Perhaps something like "interface-option" would be > better. > > But the _option_ isn't only for Windows tap-win adaptor. The option's > arguments are passed to scripts via $foreign_option_* environment > variables (on macOS, at least, and I think on most or all platforms). > And the Tunnelblick scripts use them to modify network settings, sort > of as if they came from DHCP, but not actually using DHCP. I fully understand that most of those options are supported (or should I say, '(ab)used' ) by the other platforms but what I meant was that the name 'dhcp-option' is totally misleading as it has nothing to do with DHCP *except* when using the tap-win adapter. Thus, if we want an overhaul of this, let's do it right and change the name of this option. JJK ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On Fri, Jul 3, 2020 at 3:39 AM Jan Just Keijser wrote:
>
> Hi,
>
> On 02/07/20 23:04, David Sommerseth wrote:
> > On 30/06/2020 16:15, Jan Just Keijser wrote:
> >> hi,
> >>
> >> On 30/06/20 16:11, Gert Doering wrote:
> >>> Hi,
> >>>
> >>> On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf,
> const struct tuntap_options *o)
> write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len,
> );
> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
> );
>
> +for (int i=0; i < o->domain_search_list_len; i++)
> +{
> +write_dhcp_search_str(buf, 119, o->domain_search_list[i],
> );
> +}
> >>> I assume that this won't work. In the DHCP answer, it must be a single
> >>> option with the concatenated list, not multiple answers with a single
> >>> domain name each.
> >>>
> >>> gert
> >>>
> >> see https://tools.ietf.org/html/rfc3397
> >>
> >> "
> >>
> >> In the above diagram, Searchstring is a string specifying the
> >> searchlist. If the length of the searchlist exceeds the maximum
> >> permissible within a single option (255 octets), then multiple
> >> options MAY be used, as described in "Encoding Long Options in the
> >> Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
> >> ].
> >>
> >> "
> >>
> >>
> >> so you MAY use this option multiple times - and wireshark groks it fine. I
> >> don't have a Windows 10
> >> client to test it against, however, so I am hoping that someone (Selva?)
> >> can do that for me.
> >>
> > Hi,
> >
> > Can we please see this discussion also in context of this mail thread, which
> > tries to look a broader at this challenge?
> >
> > Message-Id:
> > URL:
> >
> >
> > One change in that RFC since last time is that we will move IV_PROTO to be
> > only about the OpenVPN wire protocol (features/settings only affecting
> > protocol for the communication between the OpenVPN end-points themselves).
> > The DNS settings and more related to host configuration and similar will be
> > moved into an IV_FEAT field. Except of that, nothing else has changed from
> > the initial mail.
> >
> > The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
> > consistently across all OpenVPN implementations we care about, and that we
> > document this properly.
> >
>
> I see one as an implementation issue (can we specify a particular DHCP
> option more than once) and one as an OpenVPN protocol issue.
> I fully agree that it's time to think about and overhaul the DNS
> settings for OpenVPN but I also believe that further abusing the option
> 'dhcp-option' is not the best way forward.
+1
> The option 'dhcp-option'
> only really applies to the Windows tap-win adapter as that is the only
> adapter where you can use DHCP to add/change settings. AFAIK even the
> new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-'
> is moot.
If you mean the term 'dhcp' should not be used in the name of the
option, I agree. Perhaps something like "interface-option" would be
better.
But the _option_ isn't only for Windows tap-win adaptor. The option's
arguments are passed to scripts via $foreign_option_* environment
variables (on macOS, at least, and I think on most or all platforms).
And the Tunnelblick scripts use them to modify network settings, sort
of as if they came from DHCP, but not actually using DHCP.
> Thus, moving forward, I'd be more in favor of overhauling this
> *completely* and review all 'dhcp-option' flags to see how we can
> a) specify then more logically and more neutrally
> b) implement these features for each of the different platforms:
>
> Windows+tap-win: use DHCP
> Windows+win-tun: use netsh ?
> Linux: use systemd? use scripts
> BSD: scripts? systemd?
> MacOS: just copy what Jonathan is using ;)
+1 here, too, for overhauling this "completely".
I'll have further comment soon on the other thread:
> > Message-Id:
> > URL:
> >
Best regards,
Jon
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
>> The main purpose of that RFC is to ensure we handle DNS and >> --dhcp-options >> consistently across all OpenVPN implementations we care about, and >> that we >> document this properly. >> > > I see one as an implementation issue (can we specify a particular DHCP > option more than once) and one as an OpenVPN protocol issue. > I fully agree that it's time to think about and overhaul the DNS > settings for OpenVPN but I also believe that further abusing the option > 'dhcp-option' is not the best way forward. The option 'dhcp-option' > only really applies to the Windows tap-win adapter as that is the only > adapter where you can use DHCP to add/change settings. This not even remotely true anymore. Basically all platforms will accept the dhcp-options for modifying the DNS settings. > AFAIK even the > new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-' > is moot. Yes. Of course we can specify nicer sounding names for these options and that also break all kind of backwards compatibility for little gain or we document that the dhcp- prefix in these options is for historic reasons. Arne signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On 02/07/20 23:04, David Sommerseth wrote:
On 30/06/2020 16:15, Jan Just Keijser wrote:
hi,
On 30/06/20 16:11, Gert Doering wrote:
Hi,
On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
struct tuntap_options *o)
write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, );
+for (int i=0; i < o->domain_search_list_len; i++)
+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
+}
I assume that this won't work. In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.
gert
see https://tools.ietf.org/html/rfc3397
"
In the above diagram, Searchstring is a string specifying the
searchlist. If the length of the searchlist exceeds the maximum
permissible within a single option (255 octets), then multiple
options MAY be used, as described in "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
].
"
so you MAY use this option multiple times - and wireshark groks it fine. I
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do
that for me.
Hi,
Can we please see this discussion also in context of this mail thread, which
tries to look a broader at this challenge?
Message-Id:
URL:
One change in that RFC since last time is that we will move IV_PROTO to be
only about the OpenVPN wire protocol (features/settings only affecting
protocol for the communication between the OpenVPN end-points themselves).
The DNS settings and more related to host configuration and similar will be
moved into an IV_FEAT field. Except of that, nothing else has changed from
the initial mail.
The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
consistently across all OpenVPN implementations we care about, and that we
document this properly.
I see one as an implementation issue (can we specify a particular DHCP
option more than once) and one as an OpenVPN protocol issue.
I fully agree that it's time to think about and overhaul the DNS
settings for OpenVPN but I also believe that further abusing the option
'dhcp-option' is not the best way forward. The option 'dhcp-option'
only really applies to the Windows tap-win adapter as that is the only
adapter where you can use DHCP to add/change settings. AFAIK even the
new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-'
is moot.
Thus, moving forward, I'd be more in favor of overhauling this
*completely* and review all 'dhcp-option' flags to see how we can
a) specify then more logically and more neutrally
b) implement these features for each of the different platforms:
Windows+tap-win: use DHCP
Windows+win-tun: use netsh ?
Linux: use systemd? use scripts
BSD: scripts? systemd?
MacOS: just copy what Jonathan is using ;)
JM2CW,
JJK
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
On 30/06/2020 16:15, Jan Just Keijser wrote:
> hi,
>
> On 30/06/20 16:11, Gert Doering wrote:
>> Hi,
>>
>> On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
>>> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
>>> struct tuntap_options *o)
>>> write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
>>> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
>>> );
>>>
>>> +for (int i=0; i < o->domain_search_list_len; i++)
>>> +{
>>> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
>>> +}
>> I assume that this won't work. In the DHCP answer, it must be a single
>> option with the concatenated list, not multiple answers with a single
>> domain name each.
>>
>> gert
>>
> see https://tools.ietf.org/html/rfc3397
>
> "
>
>In the above diagram, Searchstring is a string specifying the
>searchlist. If the length of the searchlist exceeds the maximum
>permissible within a single option (255 octets), then multiple
>options MAY be used, as described in "Encoding Long Options in the
>Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
> ].
>
> "
>
>
> so you MAY use this option multiple times - and wireshark groks it fine. I
> don't have a Windows 10
> client to test it against, however, so I am hoping that someone (Selva?) can
> do that for me.
>
Hi,
Can we please see this discussion also in context of this mail thread, which
tries to look a broader at this challenge?
Message-Id:
URL:
One change in that RFC since last time is that we will move IV_PROTO to be
only about the OpenVPN wire protocol (features/settings only affecting
protocol for the communication between the OpenVPN end-points themselves).
The DNS settings and more related to host configuration and similar will be
moved into an IV_FEAT field. Except of that, nothing else has changed from
the initial mail.
The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
consistently across all OpenVPN implementations we care about, and that we
document this properly.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
hi,
On 30/06/20 16:11, Gert Doering wrote:
Hi,
On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
struct tuntap_options *o)
write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, );
+for (int i=0; i < o->domain_search_list_len; i++)
+{
+write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
+}
I assume that this won't work. In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.
gert
see https://tools.ietf.org/html/rfc3397
"
In the above diagram, Searchstring is a string specifying the
searchlist. If the length of the searchlist exceeds the maximum
permissible within a single option (255 octets), then multiple
options MAY be used, as described in "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
].
"
so you MAY use this option multiple times - and wireshark groks it fine. I
don't have a Windows 10
client to test it against, however, so I am hoping that someone (Selva?) can do
that for me.
cheers,
JJK
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const
> struct tuntap_options *o)
> write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, );
>
> +for (int i=0; i < o->domain_search_list_len; i++)
> +{
> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
> +}
I assume that this won't work. In the DHCP answer, it must be a single
option with the concatenated list, not multiple answers with a single
domain name each.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On 24/06/20 12:28, Gert Doering wrote:
Hi,
On Tue, Jun 23, 2020 at 03:53:52PM -0400, Selva Nair wrote:
So what option do we want?
--dhcp-option SEARCH
--dhcp-option DOMAIN-SEARCH
--dhcp-option SEARCH-DOMAIN
RFC 3397 calls it "Domain Search" so it has to be DOMAIN-SEARCH, in my
view. Platform scripts accepting other forms in foreign_option is up
to them. We don't have to officially support that.
I like that argument.
(I do not care too much which string it is, in the end, but if we have
an RFC which has a name for it, and that name maps directly to one of
the candidates, this is a strong argument :-) )
On the "shall it be a single occurrance with multiple domains in it" or
"shall it be multiple occurances that are concatenated into a single DHCP
option which then has multiple domains in it", I do not have a truly
strong opinion. So I'd go with "what Tunnelblick has", which is
"multiple occurances, a single string each".
He who goes first wins :-)
here's V2:
- allow a user to specify
dhcp-option DOMAIN-SEARCH
multiple times
- only a single FQDN per entry
cheers,
JJK
>From a82036c3f81d31af223a574f75de48797ba76698 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser
Date: Tue, 30 Jun 2020 15:52:58 +0200
Subject: [PATCH] Added support for DHCP option 119 (dns search suffix list)
for Windows. As of Windows 10 1809 Windows finally supports this so it makes
sense to add support to OpenVPN as well.
Signed-off-by: Jan Just Keijser
---
src/openvpn/options.c | 13 +
src/openvpn/tun.c | 48
src/openvpn/tun.h | 6 ++
3 files changed, 67 insertions(+)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 2073b4a..376b8e7 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -729,6 +729,7 @@ static const char usage_message[] =
"which allow multiple addresses,\n"
"--dhcp-option must be repeated.\n"
"DOMAIN name : Set DNS suffix\n"
+"DOMAIN-SEARCH entry : Add entry to DNS domain search list\n"
"DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
"NTP : Set NTP server address(es)\n"
"NBDD: Set NBDD server address(es)\n"
@@ -7460,6 +7461,18 @@ add_option(struct options *options,
{
dhcp_option_address_parse("NBDD", p[2], o->nbdd, >nbdd_len, msglevel);
}
+else if (streq(p[1], "DOMAIN-SEARCH") && p[2])
+{
+if (o->domain_search_list_len < N_SEARCH_LIST_LEN)
+{
+o->domain_search_list[o->domain_search_list_len++] = p[2];
+}
+else
+{
+msg(msglevel, "--dhcp-option %s: maximum of %d search entries can be specified",
+p[1], N_SEARCH_LIST_LEN);
+}
+}
else if (streq(p[1], "DISABLE-NBT") && !p[2])
{
o->disable_nbt = 1;
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 5567c44..843c6b2 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5673,6 +5673,49 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error)
buf_write(buf, str, len);
}
+
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char *str, bool *error)
+{
+const char *ptr = str, *dotptr = str;
+int i, j;
+
+const int len = strlen(str) + 2;
+if (!buf_safe(buf, 2 + len))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_str: buffer overflow building DHCP options");
+return;
+}
+if (len < 1 || len > 255)
+{
+*error = true;
+msg(M_WARN, "write_dhcp_search_str: string '%s' must be > 0 bytes and <= 255 bytes", str);
+return;
+}
+
+buf_write_u8(buf, type);
+buf_write_u8(buf, len);
+
+/* Loop over all subdomains separated by a dot and replace the dot
+ with the length of the subdomain */
+while ((dotptr = strchr(ptr, '.')) != NULL)
+{
+i = dotptr - ptr;
+buf_write_u8(buf, i);
+for (j=0; j< i; j++) buf_write_u8(buf, ptr[j]);
+ptr = dotptr + 1;
+}
+
+/* Now do the remainder after the last dot */
+i = strlen(ptr);
+buf_write_u8(buf, i);
+for (j=0; j< i; j++) buf_write_u8(buf, ptr[j]);
+
+/* And close off with an extra NUL char */
+buf_write_u8(buf, 0);
+}
+
static bool
build_dhcp_options_string(struct buffer *buf, const struct tuntap_options *o)
{
@@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const struct tuntap_options *o)
write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, );
+for (int i=0; i < o->domain_search_list_len; i++)
+{
+write_dhcp_search_str(buf, 119,
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Tue, Jun 23, 2020 at 03:53:52PM -0400, Selva Nair wrote: > > So what option do we want? > > > > --dhcp-option SEARCH > > --dhcp-option DOMAIN-SEARCH > > --dhcp-option SEARCH-DOMAIN > > RFC 3397 calls it "Domain Search" so it has to be DOMAIN-SEARCH, in my > view. Platform scripts accepting other forms in foreign_option is up > to them. We don't have to officially support that. I like that argument. (I do not care too much which string it is, in the end, but if we have an RFC which has a name for it, and that name maps directly to one of the candidates, this is a strong argument :-) ) On the "shall it be a single occurrance with multiple domains in it" or "shall it be multiple occurances that are concatenated into a single DHCP option which then has multiple domains in it", I do not have a truly strong opinion. So I'd go with "what Tunnelblick has", which is "multiple occurances, a single string each". He who goes first wins :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Tue, Jun 23, 2020 at 3:22 AM Jan Just Keijser wrote: > > Hi, > > On 21/06/20 17:14, Selva Nair wrote: > > On Sun, Jun 21, 2020 at 7:14 AM Gert Doering wrote: > >> > >> going through OpenVPN threads that went stale - I think this is > >> actually a nice addition (read: other people have already asked > >> me if this can be done). > >> > >> On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > >>> So, for what it's worth, I've dusted off the patch again and rebased it > >>> to the current openvpn master tree. See attached. Note that I did only > >>> rudimentary testing, as I don't use Windows 10 a lot and I was testing > >>> using a mingw cross-compile only. In wireshark I *do* see that the > >>> correct DHCP offer is sent to the tap-win adapter. > >>> > >>> Also note that I implemented multiple search domains by separating them > >>> using semi-colons, e.g. > >>> > >>> --dhcp-option SEARCH example.com;example.org;example.nl;example.de > >>> > >>> etc as that was easier to implement > >> The patch looks okay-ish on quick reading. > > Feature wise yes, but some improvements needed.. > > > > I do not like that option format > > > > "example.com; example.org" with quotes will parse right and fail later > > on because of the space, for example. And, we support multiple > > statements of dhcp options like DNS, so this is counter-intuitive. > > It's only a little more work to support a more forgiving format. > actually, the patch will be a bit more invasive if we add that; parsing > DNS/WINS etc is already there and it parses an option into an IP/IPv6 > address. changing the dns-search option to an array of strings will > require more work. I did look into that initially but decided not to do > it as the patch would be lengthier. > > Note that "multiple domain" option is also not support, really. The > domain is stored in the tuntap_options struct as > > 90 const char *domain; /* DOMAIN (15) */ Windows is probably the only platform where these options are "natively" supported through DHCP, and indeed DOMAIN (option 15) has to be a single domain. Android also seem to treat them internally. However, we export these as foreign_option in all other platforms, and do export anything that looks like "dhcp-option name value" with repetitions allowed. That said, I don't mind breaking scripts that use and misuse these... Anyway my point about multiple values was about DNS and WINS where it's allowed, and we parse them one entry at a time. I believe this option (search list) also should use the same format instead of inventing yet another format. Yes, it may need a bit "more work" to support one domain at a time, but that's no excuse not to use a sensible format. Concatenation of strings read one at a time with a delimiter added doesn't look that hard either. > > so it's "last option wins" ; the fact that some platforms abuse this > option to actually set multiple search domains is a different matter. > > >>> Also note that I did not fully implement the RFC3397 encoding of the > >>> search list, as that requires one to merge domain names that occur more > >>> than once - that would have made the code far more complicated. > >> Indeed. I haven't looked at what other DHCP implementations do, but > >> "correct" encoding definitely sounds like quite a bit of extra code just > >> to save a few bytes on the wire - might come handy if you have many > >> subdomains of a long internal DNS domain, though, but this can be > >> added "if needed". > > Same as my thoughts, the encoding part could be kept simple as in here > > and possibly improved later. But option format is hard to change or > > deprecate. > > > >> > >> More interesting is the question "which option to use" - it should > >> be synchronized between openvpn platform handlers. So if systemd-networkd > >> uses "SEARCH-DOMAIN" it would make sense to use that for windows > >> as well. > > I think we need both --- the current one retained as the connection > > specific suffix which would be just one entry and then this search > > list. As we allow multiple entries for DOMAIN right now, a user > > friendly approach would be to continue doing so but internally treat > > all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could > > also deprecate the use of multiple entries in the dhcp-option DOMAIN > > keyword. > > > See above: like I said, multiple DOMAIN entries do not seem to be supported. > > So what option do we want? > > --dhcp-option SEARCH > --dhcp-option DOMAIN-SEARCH > --dhcp-option SEARCH-DOMAIN RFC 3397 calls it "Domain Search" so it has to be DOMAIN-SEARCH, in my view. Platform scripts accepting other forms in foreign_option is up to them. We don't have to officially support that. Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On 21/06/20 17:14, Selva Nair wrote: On Sun, Jun 21, 2020 at 7:14 AM Gert Doering wrote: going through OpenVPN threads that went stale - I think this is actually a nice addition (read: other people have already asked me if this can be done). On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: So, for what it's worth, I've dusted off the patch again and rebased it to the current openvpn master tree. See attached. Note that I did only rudimentary testing, as I don't use Windows 10 a lot and I was testing using a mingw cross-compile only. In wireshark I *do* see that the correct DHCP offer is sent to the tap-win adapter. Also note that I implemented multiple search domains by separating them using semi-colons, e.g. --dhcp-option SEARCH example.com;example.org;example.nl;example.de etc as that was easier to implement The patch looks okay-ish on quick reading. Feature wise yes, but some improvements needed.. I do not like that option format "example.com; example.org" with quotes will parse right and fail later on because of the space, for example. And, we support multiple statements of dhcp options like DNS, so this is counter-intuitive. It's only a little more work to support a more forgiving format. actually, the patch will be a bit more invasive if we add that; parsing DNS/WINS etc is already there and it parses an option into an IP/IPv6 address. changing the dns-search option to an array of strings will require more work. I did look into that initially but decided not to do it as the patch would be lengthier. Note that "multiple domain" option is also not support, really. The domain is stored in the tuntap_options struct as 90 const char *domain; /* DOMAIN (15) */ so it's "last option wins" ; the fact that some platforms abuse this option to actually set multiple search domains is a different matter. Also note that I did not fully implement the RFC3397 encoding of the search list, as that requires one to merge domain names that occur more than once - that would have made the code far more complicated. Indeed. I haven't looked at what other DHCP implementations do, but "correct" encoding definitely sounds like quite a bit of extra code just to save a few bytes on the wire - might come handy if you have many subdomains of a long internal DNS domain, though, but this can be added "if needed". Same as my thoughts, the encoding part could be kept simple as in here and possibly improved later. But option format is hard to change or deprecate. More interesting is the question "which option to use" - it should be synchronized between openvpn platform handlers. So if systemd-networkd uses "SEARCH-DOMAIN" it would make sense to use that for windows as well. I think we need both --- the current one retained as the connection specific suffix which would be just one entry and then this search list. As we allow multiple entries for DOMAIN right now, a user friendly approach would be to continue doing so but internally treat all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could also deprecate the use of multiple entries in the dhcp-option DOMAIN keyword. See above: like I said, multiple DOMAIN entries do not seem to be supported. So what option do we want? --dhcp-option SEARCH --dhcp-option DOMAIN-SEARCH --dhcp-option SEARCH-DOMAIN all? JJK ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
On 21/06/2020 13:14, Gert Doering wrote: > Hi, > > going through OpenVPN threads that went stale - I think this is > actually a nice addition (read: other people have already asked > me if this can be done). > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: >> So, for what it's worth, I've dusted off the patch again and rebased it >> to the current openvpn master tree. See attached. Note that I did only >> rudimentary testing, as I don't use Windows 10 a lot and I was testing >> using a mingw cross-compile only. In wireshark I *do* see that the >> correct DHCP offer is sent to the tap-win adapter. >> >> Also note that I implemented multiple search domains by separating them >> using semi-colons, e.g. >> >> --dhcp-option SEARCH example.com;example.org;example.nl;example.de >> >> etc as that was easier to implement > > The patch looks okay-ish on quick reading. Feature-ACK from my side as well. But there are a few things we need to look more into. [...snip...] > More interesting is the question "which option to use" - it should > be synchronized between openvpn platform handlers. So if systemd-networkd > uses "SEARCH-DOMAIN" it would make sense to use that for windows > as well. Nit-pick, systemd-resolved is the target service in this case though. But it is related to systemd-networkd. But I agree, we should synchronize this a bit. IIRC, there might already be somewhat partial support for this in OpenVPN Connect clients as well, which might also be used in Access Server. I would also expect the OpenVPN Cloud service to facilitate such a feature. I have recently been working on systemd-resolved support in OpenVPN 3 Linux as well, and reached out earlier this week to Jonathan (update-systemd-resolved maintainer) to see if we can join forces better and standardize on a common understanding of the DHCP options. I would also like to at least consider pulling update-systemd-resolved (or a similar approach) into our OpenVPN distribution, as an alternative to the rather hacky pull-resolv-conf scripts we're shipping. I quickly spoke with Arne late on Friday about it as well, and we might also want to consider some IV flags from client to server as well, to flag support for features like split-dns (which at least systemd-resolved can provide). > Does anyone know about commercial VPN providers basing their clients > on OpenVPN? I will clarify with our folks internally how this will influence OpenVPN Cloud. I can't imagine many other commercial VPNs depending on such a feature, this is more typically a business feature than a consumer VPN feature. There might be a few ones implementing or needing such a feature, but if they don't appear here and raise there concerns here, I don't think we should spend time on them. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Sun, Jun 21, 2020 at 11:15 AM Selva Nair wrote: > > Hi, > > On Sun, Jun 21, 2020 at 7:14 AM Gert Doering wrote: > > > > Hi, > > > > going through OpenVPN threads that went stale - I think this is > > actually a nice addition (read: other people have already asked > > me if this can be done). > > > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > > > So, for what it's worth, I've dusted off the patch again and rebased it > > > to the current openvpn master tree. See attached. Note that I did only > > > rudimentary testing, as I don't use Windows 10 a lot and I was testing > > > using a mingw cross-compile only. In wireshark I *do* see that the > > > correct DHCP offer is sent to the tap-win adapter. > > > > > > Also note that I implemented multiple search domains by separating them > > > using semi-colons, e.g. > > > > > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de > > > > > > etc as that was easier to implement > > > > The patch looks okay-ish on quick reading. > > Feature wise yes, but some improvements needed.. > > I do not like that option format > > "example.com; example.org" with quotes will parse right and fail later > on because of the space, for example. And, we support multiple > statements of dhcp options like DNS, so this is counter-intuitive. > It's only a little more work to support a more forgiving format. > > > > > > Also note that I did not fully implement the RFC3397 encoding of the > > > search list, as that requires one to merge domain names that occur more > > > than once - that would have made the code far more complicated. > > > > Indeed. I haven't looked at what other DHCP implementations do, but > > "correct" encoding definitely sounds like quite a bit of extra code just > > to save a few bytes on the wire - might come handy if you have many > > subdomains of a long internal DNS domain, though, but this can be > > added "if needed". > > Same as my thoughts, the encoding part could be kept simple as in here > and possibly improved later. But option format is hard to change or > deprecate. I agree. > > More interesting is the question "which option to use" - it should > > be synchronized between openvpn platform handlers. So if systemd-networkd > > uses "SEARCH-DOMAIN" it would make sense to use that for windows > > as well. > > I think we need both --- the current one retained as the connection > specific suffix which would be just one entry and then this search > list. As we allow multiple entries for DOMAIN right now, a user > friendly approach would be to continue doing so but internally treat > all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could > also deprecate the use of multiple entries in the dhcp-option DOMAIN > keyword. The man page says to use "DOMAIN" to set the"domain suffix", but there is no documented way to specify the computer's domain. The man page doesn't indicate that multiple --dhcp-option DOMAIN options are allowed, but it specifically states that multiple DNS and WINS are allowed (for example, "Repeat this option to set secondary DNS server addresses"). (Note that bad formatting on the online version of the man page [1] makes it hard to see that "DOMAIN" is allowed at all, since it is merged into the prior paragraph. Also note that the opening paragraph for the --dhcp-option section of the man page implies it is only for Windows tap adaptors, which hasn't been true for at least 11 years!) For many years, Tunnelblick has 1. Accepted multiple SEARCH-DOMAIN or DOMAIN-SEARCH entries to set the search domains, which is in keeping with the way multiple DNS and WINS entries are interpreted. 2. Ignored all but the last "--dhcp-option DOMAIN…" entry in $foreign_option_X. 3. Used that last entry to set the computer's domain. 4. Under certain conditions, prepended the search domains with that last entry. Best regards, Jon Bullard [1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/# ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, On Sun, Jun 21, 2020 at 7:14 AM Gert Doering wrote: > > Hi, > > going through OpenVPN threads that went stale - I think this is > actually a nice addition (read: other people have already asked > me if this can be done). > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > > So, for what it's worth, I've dusted off the patch again and rebased it > > to the current openvpn master tree. See attached. Note that I did only > > rudimentary testing, as I don't use Windows 10 a lot and I was testing > > using a mingw cross-compile only. In wireshark I *do* see that the > > correct DHCP offer is sent to the tap-win adapter. > > > > Also note that I implemented multiple search domains by separating them > > using semi-colons, e.g. > > > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de > > > > etc as that was easier to implement > > The patch looks okay-ish on quick reading. Feature wise yes, but some improvements needed.. I do not like that option format "example.com; example.org" with quotes will parse right and fail later on because of the space, for example. And, we support multiple statements of dhcp options like DNS, so this is counter-intuitive. It's only a little more work to support a more forgiving format. > > > Also note that I did not fully implement the RFC3397 encoding of the > > search list, as that requires one to merge domain names that occur more > > than once - that would have made the code far more complicated. > > Indeed. I haven't looked at what other DHCP implementations do, but > "correct" encoding definitely sounds like quite a bit of extra code just > to save a few bytes on the wire - might come handy if you have many > subdomains of a long internal DNS domain, though, but this can be > added "if needed". Same as my thoughts, the encoding part could be kept simple as in here and possibly improved later. But option format is hard to change or deprecate. > > > More interesting is the question "which option to use" - it should > be synchronized between openvpn platform handlers. So if systemd-networkd > uses "SEARCH-DOMAIN" it would make sense to use that for windows > as well. I think we need both --- the current one retained as the connection specific suffix which would be just one entry and then this search list. As we allow multiple entries for DOMAIN right now, a user friendly approach would be to continue doing so but internally treat all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could also deprecate the use of multiple entries in the dhcp-option DOMAIN keyword. Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi! On Sun, Jun 21, 2020 at 7:15 AM Gert Doering wrote: > > Hi, > > going through OpenVPN threads that went stale - I think this is > actually a nice addition (read: other people have already asked > me if this can be done). > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > > So, for what it's worth, I've dusted off the patch again and rebased it > > to the current openvpn master tree. See attached. Note that I did only > > rudimentary testing, as I don't use Windows 10 a lot and I was testing > > using a mingw cross-compile only. In wireshark I *do* see that the > > correct DHCP offer is sent to the tap-win adapter. > > > > Also note that I implemented multiple search domains by separating them > > using semi-colons, e.g. > > > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de > > > > etc as that was easier to implement > > The patch looks okay-ish on quick reading. > > > Also note that I did not fully implement the RFC3397 encoding of the > > search list, as that requires one to merge domain names that occur more > > than once - that would have made the code far more complicated. > > Indeed. I haven't looked at what other DHCP implementations do, but > "correct" encoding definitly sounds like quite a bit of extra code just > to save a few bytes on the wire - might come handy if you have many > subdomains of a long internal DNS domain, though, but this can be > added "if needed". > > > More interesting is the question "which option to use" - it should > be synchronized between openvpn platform handlers. So if systemd-networkd > uses "SEARCH-DOMAIN" it would make sense to use that for windows > as well. > > Is there an option in Tunnelblick to set MacOS DNS and search list? If > yes, what option do they use? I apologize for not noticing this earlier. Two points to consider: 1. Tunnelblick does not accept "--dhcp-option SEARCH". Tunnelblick accepted DOMAIN-SEARCH starting in 2013, but users kept trying to use SEARCH-DOMAIN and then complaining when it didn't work, so in 2017 Tunnelblick started accepting also SEARCH-DOMAIN. If Windows starts using "SEARCH" I suppose we can add that, too. (**Sigh**.) 2. As is the case with using --dhcp-option to set DNS and WINS servers, Tunnelblick was designed to accept only one search domain per option, so one would use "--dhcp-option SEARCH-DOMAIN example.com --dhcp-option SEARCH-DOMAIN example.org --dhcp-option SEARCH-DOMAIN example.de" to set those three search domains. Our "up" script accepts multiple $foreign_option_X options and constructs appropriate instructions to have macOS use all of them. Parsing multiple search domains contained in one $foreign_option_X could be added but I'd rather avoid that if possible. (We'd probably have to do that if Windows does it. **Sigh**, again.) > Does anyone know about commercial VPN providers basing their clients > on OpenVPN? I don't think commercial VPN providers would use search domains. I think search domains would be used more by universities, corporations, etc. that want an easy way for their users to access their internal servers. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi, going through OpenVPN threads that went stale - I think this is actually a nice addition (read: other people have already asked me if this can be done). On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: > So, for what it's worth, I've dusted off the patch again and rebased it > to the current openvpn master tree. See attached. Note that I did only > rudimentary testing, as I don't use Windows 10 a lot and I was testing > using a mingw cross-compile only. In wireshark I *do* see that the > correct DHCP offer is sent to the tap-win adapter. > > Also note that I implemented multiple search domains by separating them > using semi-colons, e.g. > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de > > etc as that was easier to implement The patch looks okay-ish on quick reading. > Also note that I did not fully implement the RFC3397 encoding of the > search list, as that requires one to merge domain names that occur more > than once - that would have made the code far more complicated. Indeed. I haven't looked at what other DHCP implementations do, but "correct" encoding definitly sounds like quite a bit of extra code just to save a few bytes on the wire - might come handy if you have many subdomains of a long internal DNS domain, though, but this can be added "if needed". More interesting is the question "which option to use" - it should be synchronized between openvpn platform handlers. So if systemd-networkd uses "SEARCH-DOMAIN" it would make sense to use that for windows as well. Is there an option in Tunnelblick to set MacOS DNS and search list? If yes, what option do they use? Does anyone know about commercial VPN providers basing their clients on OpenVPN? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi all, On 05/03/20 13:53, Jan Just Keijser wrote: Hi, On 01/03/20 16:29, Selva Nair wrote: On Sun, Mar 1, 2020 at 2:17 AM Gert Doering wrote: On Sun, Mar 01, 2020 at 05:37:15AM +, Leroy Tennison via Openvpn-users wrote: Admittedly, and older server version (2.3) but is there a way to specify multiple DNS search suffixes for a Windows (10 if that makes a difference) client. The clients are part of a domain but I have no control over them via that avenue. I've tried multiple dhcp-option DOMAiN entries and the last one applies, I don't see another dhcp-option such as DOMAIN-SEARCH. Any options would be much appreciated. Thanks. OpenVPN never had functionality to set the DHCP SEARCH LIST option on Windows. So while you could always specify the option multiple times, it would only use one of them and put it into the DHCP DOMAIN option. It's not very much missing code, but someone would have to do it (and the "core team" is very busy with other aspects right now). IIRC, windows clients never queried DHCP option 119 (domain search). It seems that has changed since Windows 10, or has it? I had to dig through my archives for this one - I found an OpenVPN 2.0.9 (!) source tree to which I had added rudimentary support for DHCP domain search, but that was *before* I found out that Windows did not support that... And yes, according to the comment section of https://www.normanbauer.com/2018/04/18/configuring-dhcp-option-119-domain-search-list-on-a-windows-dhcp-server/, Windows 10 1809+ finally has support for DHCP domain searches. So, for what it's worth, I've dusted off the patch again and rebased it to the current openvpn master tree. See attached. Note that I did only rudimentary testing, as I don't use Windows 10 a lot and I was testing using a mingw cross-compile only. In wireshark I *do* see that the correct DHCP offer is sent to the tap-win adapter. Also note that I implemented multiple search domains by separating them using semi-colons, e.g. --dhcp-option SEARCH example.com;example.org;example.nl;example.de etc as that was easier to implement Also note that I did not fully implement the RFC3397 encoding of the search list, as that requires one to merge domain names that occur more than once - that would have made the code far more complicated. to follow up on this: I just found Jonathan's update-systemd-resolved thingie (https://github.com/jonathanio/update-systemd-resolved) where he mentions that you can push --dhcp-option DOMAIN multiple times to achieve a similar result - but at best that works on anything BUT Windows. I do see that he lists a non-supported option --dhcp-option SEARCH-DOMAIN instead of my 'SEARCH' ; it will be good to sync up with his script/code to ensure a smooth cooperation between platforms - provided, that is, that my patch is actually acceptable ;) cheers, JJK ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows
Hi,
On 01/03/20 16:29, Selva Nair wrote:
On Sun, Mar 1, 2020 at 2:17 AM Gert Doering wrote:
On Sun, Mar 01, 2020 at 05:37:15AM +, Leroy Tennison via Openvpn-users
wrote:
Admittedly, and older server version (2.3) but is there a way to specify
multiple DNS search suffixes for a Windows (10 if that makes a difference)
client. The clients are part of a domain but I have no control over them via
that avenue. I've tried multiple dhcp-option DOMAiN entries and the last one
applies, I don't see another dhcp-option such as DOMAIN-SEARCH. Any options
would be much appreciated. Thanks.
OpenVPN never had functionality to set the DHCP SEARCH LIST option
on Windows.
So while you could always specify the option multiple times, it would
only use one of them and put it into the DHCP DOMAIN option.
It's not very much missing code, but someone would have to do it (and
the "core team" is very busy with other aspects right now).
IIRC, windows clients never queried DHCP option 119 (domain search).
It seems that has changed since Windows 10, or has it?
I had to dig through my archives for this one - I found an OpenVPN
2.0.9 (!) source tree to which I had added rudimentary support for DHCP
domain search, but that was *before* I found out that Windows did not
support that...
And yes, according to the comment section of
https://www.normanbauer.com/2018/04/18/configuring-dhcp-option-119-domain-search-list-on-a-windows-dhcp-server/,
Windows 10 1809+ finally has support for DHCP domain searches.
So, for what it's worth, I've dusted off the patch again and rebased it
to the current openvpn master tree. See attached. Note that I did only
rudimentary testing, as I don't use Windows 10 a lot and I was testing
using a mingw cross-compile only. In wireshark I *do* see that the
correct DHCP offer is sent to the tap-win adapter.
Also note that I implemented multiple search domains by separating them
using semi-colons, e.g.
--dhcp-option SEARCH example.com;example.org;example.nl;example.de
etc as that was easier to implement
Also note that I did not fully implement the RFC3397 encoding of the
search list, as that requires one to merge domain names that occur more
than once - that would have made the code far more complicated.
share and enjoy,
JJK
>From a969947cd86292c881f7cc1c704ac992e8f6f0d6 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser
Date: Thu, 5 Mar 2020 13:41:00 +0100
Subject: [PATCH] Added support for DHCP option 119 (dns search suffix list)
for Windows. As of Windows 10 1809 Windows finally supports this so it makes
sense to add support to OpenVPN as well.
---
src/openvpn/options.c | 6 +
src/openvpn/tun.c | 62 +++
src/openvpn/tun.h | 3 +++
3 files changed, 71 insertions(+)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 6c0e52e..e59b22b 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -726,6 +726,7 @@ static const char usage_message[] =
"which allow multiple addresses,\n"
"--dhcp-option must be repeated.\n"
"DOMAIN name : Set DNS suffix\n"
+"SEARCH name : Set DNS domain search list\n"
"DNS addr: Set domain name server address(es) (IPv4 and IPv6)\n"
"NTP : Set NTP server address(es)\n"
"NBDD: Set NBDD server address(es)\n"
@@ -1175,6 +1176,7 @@ show_tuntap_options(const struct tuntap_options *o)
SHOW_BOOL(dhcp_renew);
SHOW_BOOL(dhcp_pre_release);
SHOW_STR(domain);
+SHOW_STR(domain_search_list);
SHOW_STR(netbios_scope);
SHOW_INT(netbios_node_type);
SHOW_BOOL(disable_nbt);
@@ -7327,6 +7329,10 @@ add_option(struct options *options,
{
o->domain = p[2];
}
+else if (streq(p[1], "SEARCH") && p[2])
+{
+o->domain_search_list = p[2];
+}
else if (streq(p[1], "NBS") && p[2])
{
o->netbios_scope = p[2];
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index aa131b2..eed9ae6 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5567,6 +5567,48 @@ write_dhcp_str(struct buffer *buf, const int type, const char *str, bool *error)
buf_write(buf, str, len);
}
+static void
+write_dhcp_search_str(struct buffer *buf, const int type, const char *str, bool *error)
+{
+const char *ptr = str, *dotptr = str;
+int i, j;
+
+const int len = strlen(str) + 2;
+if (!buf_safe(buf, 2 + len))
+{
+*error = true;
+msg(M_WARN, "write_dhcp_str: buffer overflow building DHCP options");
+return;
+}
+if (len < 1 || len > 255)
+{
+*error = true;
+msg(M_WARN, "write_dhcp_search_str: string '%s' must be > 0 bytes and <= 255 bytes", str);
+return;
+}
+
+buf_write_u8(buf, type);
+
