Re: [Openvpn-devel] [PATCH] Added client-ip to NAT config
Ops, sorry. It's the same. I thought it was not sent to the group. :-) BR Gava On Wed, Sep 16, 2020 at 5:35 PM Gert Doering wrote: > Hi, > > On Wed, Sep 16, 2020 at 04:56:17PM +0000, Rafael Gava de Oliveira via > Openvpn-devel wrote: > > A couple years ago I submitted this patch which allows the user to set > the 'client-ip' as a convenient way to use the leased IP address received > from OpenVPN server in NAT configuration. For example: > > We now have two submissions for this - are they any different? > > 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 > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Added client-ip to NAT config
Hello guys,
A couple years ago I submitted this patch which allows the user to set the
'client-ip' as a convenient way to use the leased IP address received from
OpenVPN server in NAT configuration. For example:
client-nat snat client-ip 255.255.255.255 172.20.1.15
, where 'client-ip' string is replaced with the leased IP address received from
OpenVPN server.
At that time, it was NACKED due to the fact that I was using both client-ip and
localhost strings. So, it's changed now and I'd like to re-submit it again for
appreciation.
Thanks
Gava
--
>From cb56f9bd4acaf28a2af256eead009310d8ba063f Mon Sep 17 00:00:00 2001
From: Rafael Gava de Oliveira
Date: Sat, 12 Sep 2020 19:27:25 -0300
Subject: [PATCH] Allows the usage of the string 'client-ip' in the client-nat
network configuration in a way that is not necessary to inform the IP address
beforehand. Openvpn will set dynamically the received IP from DHCP.
Example:
client-nat snat client-ip 255.255.255.255 172.20.1.15
Replaces the 'client-ip' string with the DHCP address received from
the openvpn server.
Signed-off-by: Rafael Gava de Oliveira
---
src/openvpn/clinat.c | 45 -
src/openvpn/clinat.h | 2 ++
src/openvpn/init.c| 2 ++
src/openvpn/options.c | 2 +-
4 files changed, 45 insertions(+), 6 deletions(-)
mode change 100644 => 100755 src/openvpn/clinat.c
diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
old mode 100644
new mode 100755
index b08fd54..865b0e2
--- a/src/openvpn/clinat.c
+++ b/src/openvpn/clinat.c
@@ -128,12 +128,16 @@ add_client_nat_to_option_list(struct
client_nat_option_list *dest,
msg(msglevel, "client-nat: type must be 'snat' or 'dnat'");
return;
}
-
-e.network = getaddr(0, network, 0, &ok, NULL);
-if (!ok)
+if (network && !strcmp(network, "client-ip"))
{
-msg(msglevel, "client-nat: bad network: %s", network);
-return;
+e.network = 0x;
+} else {
+e.network = getaddr(0, network, 0, &ok, NULL);
+if (!ok)
+{
+msg(msglevel, "client-nat: bad network: %s", network);
+return;
+}
}
e.netmask = getaddr(0, netmask, 0, &ok, NULL);
if (!ok)
@@ -276,3 +280,34 @@ client_nat_transform(const struct client_nat_option_list
*list,
}
}
}
+
+/*
+* Replaces the client-ip token with the IP received from OpenVPN Server
+*/
+bool
+update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t local_ip)
+{
+int i;
+bool ret = false;
+
+if (!dest)
+return ret;
+
+for (i=0; i <= dest->n; i++)
+{
+struct client_nat_entry *nat_entry = &dest->entries[i];
+if (nat_entry && nat_entry->network == 0x)
+{
+struct in_addr addr;
+
+nat_entry->network = ntohl(local_ip);
+addr.s_addr = nat_entry->network;
+char *dot_ip = inet_ntoa(addr);
+
+msg (M_INFO, "Updating NAT table client-ip to: %s", dot_ip);
+ret = true;
+}
+}
+
+return ret;
+}
diff --git a/src/openvpn/clinat.h b/src/openvpn/clinat.h
index eec7a03..c2941b9 100644
--- a/src/openvpn/clinat.h
+++ b/src/openvpn/clinat.h
@@ -64,4 +64,6 @@ void client_nat_transform(const struct client_nat_option_list
*list,
struct buffer *ipbuf,
const int direction);
+bool update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t
local_ip);
+
#endif /* if !defined(CLINAT_H) */
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index a785934..8d6f9a8 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1920,6 +1920,8 @@ do_open_tun(struct context *c)
SET_MTU_TUN | SET_MTU_UPPER_BOUND);
}
+update_client_ip_nat(c->options.client_nat, c->c1.tuntap->local);
+
ret = true;
static_context = c;
#ifndef TARGET_ANDROID
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 8bf82c5..26f11fa 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -231,7 +231,7 @@ static const char usage_message[] =
" ICMPv6 host unreachable messages on the client.\n"
" (Server) Instead of forwarding IPv6 packets send\n"
" ICMPv6 host unreachable packets to the client.\n"
-"--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT
rule.\n"
+"--client-nat snat|dnat network|'client-ip' netmask alias : on client add
1-to-1 NAT rule.\n"
[Openvpn-devel] NAT client-ip
Hello guys,
A couple years ago I submitted this patch which allows the user to set the
'client-ip' as a convenient way to use the leased IP address received from
OpenVPN server in NAT configuration. For example:
client-nat snat client-ip 255.255.255.255 172.20.1.15
, where 'client-ip' string is replaced with the leased IP address received
from OpenVPN server.
At that time, it was NACKED due to the fact that I was using both client-ip
and localhost strings. So, it's changed now and I'd like to re-submit it
again for appreciation.
Thanks
Gava
-
>From e273b13bc10da8f917a981957cf2c43ba6bd1e10 Mon Sep 17 00:00:00 2001
From: Rafael Gava de Oliveira
Date: Sat, 12 Sep 2020 19:27:25 -0300
Subject: [PATCH] Allows the usage of the string 'client-ip' in the
client-nat
network configuration in a way that is not necessary to inform the IP
address
beforehand. Openvpn will dynamically set the received IP from DHCP.
Example:
client-nat snat client-ip 255.255.255.255 172.20.1.15
Replaces the 'client-ip' string with the DHCP address received from
the openvpn server.
---
src/openvpn/clinat.c | 45 -
src/openvpn/clinat.h | 2 ++
src/openvpn/init.c| 2 ++
src/openvpn/options.c | 2 +-
4 files changed, 45 insertions(+), 6 deletions(-)
mode change 100644 => 100755 src/openvpn/clinat.c
diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
old mode 100644
new mode 100755
index b08fd54..865b0e2
--- a/src/openvpn/clinat.c
+++ b/src/openvpn/clinat.c
@@ -128,12 +128,16 @@ add_client_nat_to_option_list(struct
client_nat_option_list *dest,
msg(msglevel, "client-nat: type must be 'snat' or 'dnat'");
return;
}
-
-e.network = getaddr(0, network, 0, &ok, NULL);
-if (!ok)
+if (network && !strcmp(network, "client-ip"))
{
-msg(msglevel, "client-nat: bad network: %s", network);
-return;
+e.network = 0x;
+} else {
+e.network = getaddr(0, network, 0, &ok, NULL);
+if (!ok)
+{
+msg(msglevel, "client-nat: bad network: %s", network);
+return;
+}
}
e.netmask = getaddr(0, netmask, 0, &ok, NULL);
if (!ok)
@@ -276,3 +280,34 @@ client_nat_transform(const struct
client_nat_option_list *list,
}
}
}
+
+/*
+* Replaces the client-ip token with the IP received from OpenVPN Server
+*/
+bool
+update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t
local_ip)
+{
+int i;
+bool ret = false;
+
+if (!dest)
+return ret;
+
+for (i=0; i <= dest->n; i++)
+{
+struct client_nat_entry *nat_entry = &dest->entries[i];
+if (nat_entry && nat_entry->network == 0x)
+{
+struct in_addr addr;
+
+nat_entry->network = ntohl(local_ip);
+addr.s_addr = nat_entry->network;
+char *dot_ip = inet_ntoa(addr);
+
+msg (M_INFO, "Updating NAT table client-ip to: %s", dot_ip);
+ret = true;
+}
+}
+
+return ret;
+}
diff --git a/src/openvpn/clinat.h b/src/openvpn/clinat.h
index eec7a03..c2941b9 100644
--- a/src/openvpn/clinat.h
+++ b/src/openvpn/clinat.h
@@ -64,4 +64,6 @@ void client_nat_transform(const struct
client_nat_option_list *list,
struct buffer *ipbuf,
const int direction);
+bool update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t
local_ip);
+
#endif /* if !defined(CLINAT_H) */
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index a785934..8d6f9a8 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1920,6 +1920,8 @@ do_open_tun(struct context *c)
SET_MTU_TUN | SET_MTU_UPPER_BOUND);
}
+update_client_ip_nat(c->options.client_nat, c->c1.tuntap->local);
+
ret = true;
static_context = c;
#ifndef TARGET_ANDROID
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 8bf82c5..26f11fa 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -231,7 +231,7 @@ static const char usage_message[] =
" ICMPv6 host unreachable messages on the client.\n"
" (Server) Instead of forwarding IPv6 packets send\n"
" ICMPv6 host unreachable packets to the client.\n"
-"--client-nat snat|dnat network netmask alias : on client add 1-to-1
NAT rule.\n"
+"--client-nat snat|dnat network|'client-ip' netmask alias : on client
add 1-to-1 NAT rule.\n"
"--push-peer-info : (client only) push client info to server.\n"
"--setenv name value : Set a custom environmental variable to pass to
script.\n"
"--setenv FORWARD_COMPATIBLE 1 : Relax config file syntax checking to
allow\n"
--
2.7.4
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] problem with beta3 and wintun
Hi Selva, I was wondering if it's possible to detect UAC during the installation. What do you think? BR Gava On Fri, Sep 11, 2020 at 1:48 PM Selva Nair wrote: > Hi, > > On Fri, Sep 11, 2020 at 1:58 AM Gert Doering wrote: > >> Hi, >> >> On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote: >> > To All 3, >> > Thank you with your help I found the issue. UAC was disabled in the >> > registry on this image. IIRC we had trouble updating some software by >> > automated script and turning UAC off was required. >> > >> > After re-enabling UAC, wintun started normally. >> >> Cool, thanks for digging into this and reporting back. >> >> Selva, is there any reasonable way to detect this? Or do we just go >> for "we always use the iservice if it is running, no matter what >> privs the GUI is running with"? > > > I think TokenElevationType will indicate whether using split token (UAC > enabled) or not. > > Personally, I would like to show a warning when the GUI is started with > privileges but some users may not like it. And we could make iservice a > requirement for the GUI. The service is mature enough now and has become a > necessity with wintun support. > > Although we don't have any reason not to connect to named pipes as admin > in post-vista systems, the idea that the GUI should be run without elevated > privileges appeals to me. Unless the user has taken deliberate steps to > force running it as admin, it just works that way. Disabling UAC and then > log in as admin for day to day work is like using root for browsing the > web. > > That said, I won't object to a patch that removes the restriction when the > runtime version is Win7 and newer. > > Selva > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Gert, Glad that we could help! :-) If you guys need anything else that we can help, please let us know. BR Gava On Mon, Aug 31, 2020 at 10:23 AM Gert Doering wrote: > Hi, > > On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote: > > Good news, it worked beautifully with tun and tap interfaces! > > > > Thank you very much > > Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock > will go about building a beta3 .msi with it (and hopefully lots of other > windows specific fixes :-) ). > > 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 > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Gert, Good news, it worked beautifully with tun and tap interfaces! Thank you very much BR Gava On Sun, Aug 30, 2020 at 5:37 PM Gert Doering wrote: > Hi, > > On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote: > > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: > [..] > > If it still doesn't do that, you found a new bug :-) > > So - patch has been merged, and I think I have set up an appropriate > testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled). > > With Arne's (v2) patch it is no longer failing. > > Can you re-test your scenarios, 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 > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Gert, thanks for the prompt fix. Our server is an old appliance and I really don't know if it was compiled with "enable-small". I'll try to figure that. :-) Sure, I'll try the fix and let you know ASAP. BR Gava On Sun, Aug 30, 2020 at 5:37 PM Gert Doering wrote: > Hi, > > On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote: > > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: > [..] > > If it still doesn't do that, you found a new bug :-) > > So - patch has been merged, and I think I have set up an appropriate > testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled). > > With Arne's (v2) patch it is no longer failing. > > Can you re-test your scenarios, 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 > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Help testing OpenVPN 2.5-beta2 driver installation?
Hi,
Although I've got an issue (below) in your release, reported in another
email, the installation worked fine in a Windows 10 Enterprise
Evaluation Build 19041.vb_release. 191206-1406.
2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher
with server. Add the server's cipher ('BF-CBC') to --data-ciphers
(currently 'BF-CBC') if you want to connect to this server.
2020-08-29 16:02:53 us=659181 ERROR: Failed to apply push options
BR
Gava
On Fri, Aug 28, 2020 at 10:10 AM Samuli Seppänen wrote:
> Hi,
>
> It would be great if somebody would find time to test the following
> installer:
>
>
> https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi
>
> In particular I'd like to know if anyone else has problems installing
> Wintun or Tap-windows6. My exact issue is described here:
>
> https://github.com/OpenVPN/openvpn-build/issues/187
>
> At the moment two people have successfully ran that installer and one
> (me) have failed.
>
> Samuli
>
>
> PS. The installer has a known, upgrade-related issue as well, but we
> already have plans on how to tackle that:
>
> https://github.com/OpenVPN/openvpn-build/issues/188
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hello tincanteksup,
Thanks for sharing. I didn't know that wiki. I'll double check and see if
I'm missing something.
Actually, I haven't compiled the code, I was just trying the installer from
the link below:
https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi
Anyway, I'll pull the code, build it and see what happens.
BR
Gava
On Sat, Aug 29, 2020 at 4:28 PM tincanteksup wrote:
> Hi,
>
> sorry to interrupt, Rafael could you please confirm if you find this
> document to be correct/incorrect for your use case:
> https://community.openvpn.net/openvpn/wiki/CipherNegotiation
>
> Also note, this patch has been merged so make sure your binary has been
> compiled with it.
>
>
> On 29/08/2020 20:19, Rafael Gava wrote:
> > Hi Arne,
> >
> > This thread has a could days but I'm testing the version 2.5-beta2 and
> I'm
> > getting the following error:
> >
> > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher
> > with server. Add the server's cipher ('BF-CBC') to --data-ciphers
> > (currently 'BF-CBC') if you want to connect to this server.
> >
> > I have added the data-ciphers and also the data-ciphers-fallback to the
> > client's config file and in all attempts I'm getting the same error
> message.
> >
> > data-ciphers BF-CBC
> > data-ciphers-fallback BF-CBC
> >
> > I know that you guys are trying to get rid of the BF-CBC but my question
> > is, should it still work if we set these parameters in the config file or
> > am I missing or doing something wrong? :-)
> >
> > BR
> >
> > Gava
> >
> >
> >
> >
> > On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe wrote:
> >
> >> OpenVPN 2.5 clients do not correctly do a fallback to the server server.
> >> This commit fixes that logic and also fixes --data-ciphers-fallback to
> >> be used in situations other than no OCC cipher.
> >>
> >> To reproduce the error use a client with only --data-ciphers set against
> >> a server without NCP.
> >>
> >> OPTIONS ERROR: failed to negotiate cipher with server.
> >> Add the server's cipher ('AES-256-CBC') to --data-ciphers
> >> (currently 'AES-256-CBC') if you want to connect to this
> server.
> >>
> >> Reported by: Richard Bonhomme
> >>
> >> Signed-off-by: Arne Schwabe
> >> ---
> >> src/openvpn/ssl_ncp.c | 9 +
> >> 1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> >> index f522b8f0..c9ab85ce 100644
> >> --- a/src/openvpn/ssl_ncp.c
> >> +++ b/src/openvpn/ssl_ncp.c
> >> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int
> >> found)
> >> }
> >> /* If the server did not push a --cipher, we will switch to the
> >>* remote cipher if it is in our ncp-ciphers list */
> >> -bool useremotecipher = tls_poor_mans_ncp(&c->options,
> >> -
> >> c->c2.tls_multi->remote_ciphername);
> >> -
> >> +if(tls_poor_mans_ncp(&c->options,
> c->c2.tls_multi->remote_ciphername))
> >> +{
> >> +return true;
> >> +}
> >>
> >> /* We could not figure out the peer's cipher but we have fallback
> >>* enabled */
> >> -if (!useremotecipher && c->options.enable_ncp_fallback)
> >> +if (!c->c2.tls_multi->remote_ciphername &&
> >> c->options.enable_ncp_fallback)
> >> {
> >> return true;
> >> }
> >> --
> >> 2.26.2
> >>
> >>
> >>
> >> ___
> >> Openvpn-devel mailing list
> >> Openvpn-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >>
> >
> >
> >
> > ___
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Gert,
Actually, I was testing Samuli's 2.5-beta2 installer from the link below:
Note sure if it's with the patch for data-ciphers but I guess so.
I'll pull the 2.5-beta2 code and build it in order to check if it's
working properly.
https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi
Moreover, please see the comments inline...
Please let me know if you need anything else.
BR
Gava
On Sat, Aug 29, 2020 at 4:47 PM Gert Doering wrote:
> Hi,
>
> On Sat, Aug 29, 2020 at 04:19:07PM -0300, Rafael Gava wrote:
> > This thread has a could days but I'm testing the version 2.5-beta2 and
> I'm
> > getting the following error:
> >
> > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher
> > with server. Add the server's cipher ('BF-CBC') to --data-ciphers
> > (currently 'BF-CBC') if you want to connect to this server.
>
> Which combination of client/server is this exactly? 2.5-beta2 on
> the client, what is on the server? Can we have some more log file,
> including the "PUSH_REPLY", please?
>
>
The server version is 2.3.18.
The client:
2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL
(OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020
2020-08-29 16:02:50 us=235805 Windows version 10.0 (Windows 10 or greater)
64bit
2020-08-29 16:02:50 us=235805 library versions: OpenSSL 1.1.1g 21 Apr
2020, LZO 2.10
And, if this is on windows, please make sure it's really "beta2" - the
> installer will not replace openvpn.exe when going from beta1 to beta2,
> so you might run an 2.5_beta1 openvpn.exe.
>
> [..]
> > I know that you guys are trying to get rid of the BF-CBC but my question
> > is, should it still work if we set these parameters in the config file or
> > am I missing or doing something wrong? :-)
>
> It definitely should work.
>
> It does work for my test bed, but I am not testing "2.5 client against
> 'some old server'" yet - only the other way round, 2.2/2.3/2.4/2.5 client
> against 2.5 server. It needs "data-ciphers BF-CBC" (or "cipher BF-CBC")
> to be added to the config for non-NCP combinations, but afterwards
> it works.
>
>
I falled back to the 2.5-beta1 using the same configuration and it worked.
Attached are both logs and the client config.
> 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
>
2020-08-29 16:02:50 us=235805 WARNING: Ignoring option 'dh' in tls-client mode,
please only include this in your server configuration
2020-08-29 16:02:50 us=235805 Current Parameter Settings:
2020-08-29 16:02:50 us=235805 config = 'Test.ovpn'
2020-08-29 16:02:50 us=235805 mode = 0
2020-08-29 16:02:50 us=235805 show_ciphers = DISABLED
2020-08-29 16:02:50 us=235805 show_digests = DISABLED
2020-08-29 16:02:50 us=235805 show_engines = DISABLED
2020-08-29 16:02:50 us=235805 genkey = DISABLED
2020-08-29 16:02:50 us=235805 genkey_filename = '[UNDEF]'
2020-08-29 16:02:50 us=235805 key_pass_file = '[UNDEF]'
2020-08-29 16:02:50 us=235805 show_tls_ciphers = DISABLED
2020-08-29 16:02:50 us=235805 connect_retry_max = 0
2020-08-29 16:02:50 us=235805 Connection profiles [0]:
2020-08-29 16:02:50 us=235805 proto = tcp-client
2020-08-29 16:02:50 us=235805 local = '[UNDEF]'
2020-08-29 16:02:50 us=235805 local_port = '[UNDEF]'
2020-08-29 16:02:50 us=235805 remote = '192.168.1.1'
2020-08-29 16:02:50 us=235805 remote_port = '443'
2020-08-29 16:02:50 us=235805 remote_float = DISABLED
2020-08-29 16:02:50 us=235805 bind_defined = DISABLED
2020-08-29 16:02:50 us=235805 bind_local = DISABLED
2020-08-29 16:02:50 us=235805 bind_ipv6_only = DISABLED
2020-08-29 16:02:50 us=235805 connect_retry_seconds = 5
2020-08-29 16:02:50 us=235805 connect_timeout = 120
2020-08-29 16:02:50 us=235805 socks_proxy_server = '[UNDEF]'
2020-08-29 16:02:50 us=235805 socks_proxy_port = '[UNDEF]'
2020-08-29 16:02:50 us=235805 tun_mtu = 1500
2020-08-29 16:02:50 us=235805 tun_mtu_defined = ENABLED
2020-08-29 16:02:50 us=235805 link_mtu = 1500
2020-08-29 16:02:50 us=235805 link_mtu_defined = DISABLED
2020-08-29 16:02:50 us=235805 tun_mtu_extra = 0
2020-08-29 16:02:50 us=235805 tun_mtu_extra_defined = DISABLED
2020-08-29 16:02:50 us=235805 mtu_discover_type = -1
2020-08-29 16:02:50 us=235805 fragment = 0
2020-08-29 16:02:50 us=
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Arne,
This thread has a could days but I'm testing the version 2.5-beta2 and I'm
getting the following error:
2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher
with server. Add the server's cipher ('BF-CBC') to --data-ciphers
(currently 'BF-CBC') if you want to connect to this server.
I have added the data-ciphers and also the data-ciphers-fallback to the
client's config file and in all attempts I'm getting the same error message.
data-ciphers BF-CBC
data-ciphers-fallback BF-CBC
I know that you guys are trying to get rid of the BF-CBC but my question
is, should it still work if we set these parameters in the config file or
am I missing or doing something wrong? :-)
BR
Gava
On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe wrote:
> OpenVPN 2.5 clients do not correctly do a fallback to the server server.
> This commit fixes that logic and also fixes --data-ciphers-fallback to
> be used in situations other than no OCC cipher.
>
> To reproduce the error use a client with only --data-ciphers set against
> a server without NCP.
>
> OPTIONS ERROR: failed to negotiate cipher with server.
> Add the server's cipher ('AES-256-CBC') to --data-ciphers
> (currently 'AES-256-CBC') if you want to connect to this server.
>
> Reported by: Richard Bonhomme
>
> Signed-off-by: Arne Schwabe
> ---
> src/openvpn/ssl_ncp.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index f522b8f0..c9ab85ce 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int
> found)
> }
> /* If the server did not push a --cipher, we will switch to the
> * remote cipher if it is in our ncp-ciphers list */
> -bool useremotecipher = tls_poor_mans_ncp(&c->options,
> -
> c->c2.tls_multi->remote_ciphername);
> -
> +if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername))
> +{
> +return true;
> +}
>
> /* We could not figure out the peer's cipher but we have fallback
> * enabled */
> -if (!useremotecipher && c->options.enable_ncp_fallback)
> +if (!c->c2.tls_multi->remote_ciphername &&
> c->options.enable_ncp_fallback)
> {
> return true;
> }
> --
> 2.26.2
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges
Hello Guys, sorry for the late reply.
Ok, I'll wait for the fix to retest.
Another question...
Inspecting the wintun interface through the properties I saw that on the
TCP/IPv4 Properties the default option selected is "Use the following IP
address" but the IP address and the Subnet mask were empty. Should that be
a problem?
BR
Rafael
On Tue, Aug 18, 2020 at 5:15 PM Selva Nair wrote:
> Hi
>
> On Tue, Aug 18, 2020 at 3:42 PM Gert Doering wrote:
>
>> Hi,
>>
>> On Tue, Aug 18, 2020 at 03:29:19PM -0400, Selva Nair wrote:
>> > > If you already have SYSTEM, accessing wintun from openvpn directly
>> will
>> > > also work and should bring quite a bit of speed improvement.
>> >
>> > I was wrong to assume that this just works. Looking at it again, the
>> current
>> > implementation of wintun support does not seem to cover this. Meaning
>> the
>> > only working approach is to use the interactive service.
>>
>> Indeed, you are right. Somewhere on the track we lost the ability
>> to do wintun "from OpenVPN" if we *have* SYSTEM.
>>
>> This is the code in tun.c
>>
>> if (tt->options.msg_channel)
>> {
>> ret = service_register_ring_buffers(tt);
>> }
>> else
>> {
>> msg(M_FATAL, "ERROR: Wintun requires SYSTEM privileges and
>> therefore "
>> "should be used with interactive service. If you
>> want to "
>> "use openvpn from command line, you need to do
>> SYSTEM "
>> "elevation yourself (for example with psexec).");
>> }
>>
>>
>> ... so while I'm happy that we got rid of impersonating SYSTEM, the
>> current
>> code does not even try anymore, just assumes "if there is no message
>> channel,
>> we have not enough privileges".
>>
>> OTOH the message is severely misleading now, since it suggests "having
>> the right privileges will make this work".
>>
>>
>> This needs fixing - either we *try*, and if we fail, print the message
>> about insufficient privileges, or we change the message to actually
>> print something like "Wintun support is only possible if the interactive
>> service is used. Do not run from the CLI. Use the GUI in non-admin
>> mode.".
>>
>
> We have all the necessary code to do "register ring buffers" that the
> service uses, so just calling it and printing that message on failure
> should fix it.
>
> Looks like something lost by Lev during a rebase or conflict resolution.
>
> Trac #1318
>
> Selva
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges
Hello Everyone
Could you please give me an insight of what is going here... :-)
I'm trying to use and test the openvpn version 2.5_beta1 with the wintun
interface on a windows 10 machine based on a release built from the source
code.
In order to do that, I'm using the openvpn-vagrant with the
openvpn-build-bionic vm to generate a nsis installer. Well, so far, I'm
building an unsigned release.
After setting the environment variables, downloading the code and running
the ./openvpn-build/windows-nsis/build-complete script, the compilation
completes successfully and an exe file is generated.
In a Windows 10 machine, the installation of this generated exe runs ok but
when I try to connect to a server from the Openvpn-GUI using the wintun
interface, I always get the following error:
2020-08-17 19:15:39 us=419470 Outgoing Data Channel: Using 160 bit message
hash 'SHA1' for HMAC authentication
2020-08-17 19:15:39 us=419470 Incoming Data Channel: Cipher 'BF-CBC'
initialized with 128 bit key
2020-08-17 19:15:39 us=419470 WARNING: INSECURE cipher (BF-CBC) with block
size less than 128 bit (64 bit). This allows attacks like SWEET32.
Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Support for these insecure ciphers will be removed in OpenVPN 2.6.
2020-08-17 19:15:39 us=419470 Incoming Data Channel: Using 160 bit message
hash 'SHA1' for HMAC authentication
2020-08-17 19:15:39 us=419470 WARNING: cipher with small block size in use,
reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
2020-08-17 19:15:39 us=419470 interactive service msg_channel=0
2020-08-17 19:15:39 us=421471 ROUTE_GATEWAY 10.1.1.1/255.255.0.0 I=10
HWADDR=92:e9:37:4c:bb:99
2020-08-17 19:15:39 us=421471 open_tun
2020-08-17 19:15:39 us=424470 MANAGEMENT: Client disconnected
2020-08-17 19:15:39 us=424470 ERROR: Wintun requires SYSTEM privileges and
therefore should be used with interactive service. If you want to use
openvpn from the command line, you need to do SYSTEM elevation yourself
(for example with psexec).
2020-08-17 19:15:39 us=424470 Exiting due to fatal error
It seems that the openvpn.exe is unable to open the pipe with the
Interactive Service (interactive service msg_channel=0). If I download and
install the OpenVPN-2.5-beta.msi from the openvpn.net, wintun works
perfectly.
So, now is the point that I'm stuck. What am I doing wrong or missing?
Moreover, I have a couple questions that you guys might help:
1) Is there any problem in using openvpn with the wintun interface from an
unsigned built release?
2) Is there any problem with wintun in using an unsigned nsis installer
than the .msi one?
3) I'm also trying to generate a msi installer with vagrant msibuilder but
I'm getting the following error:
PS O:\windows-msi> cscript build.wsf msi
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.
BUILD: tmp\x86\msi.wixobj
RUN: "C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe" -nologo -ext
WixNetFxExtension -arch "x86" -dPRODUCT_PUBLISHER="OpenVPN Technologies,
Inc." -dPRODUCT_NAME="OpenVPN" -dPRODUCT_VERSION="2.5.003"
-dPACKAGE_VERSION="2.5-20200304" -dPRODUCT_TAP_WIN_NAME="TAP-Windows"
-dPRODUCT_TAP_WIN_COMPONENT_ID="tap0901" -dPRODUCT_PLATFORM="x86"
-dPRODUCT_CODE="
{E5931AF4-2A8F-48A5-AFC8-E996BB49D024}"
-dUPGRADE_CODE="{1195A47B-A37A-4055-9D34-B7A691F7E97B}"
-dCONFIG_EXTENSION="ovpn" -dPROGRAM_FILES_DIR="ProgramFilesFolder"
-dOPENSSL_PLAT="" -out "tmp\x86\msi.wixobj" "msi.wxs"
msi.wxs
O:\windows-msi\msi.wxs(724) : error CNDL0104 : Not a valid source file;
detail: 'yes' is an unexpected token. Expecting
white space. Line 724, position 157.
O:\windows-msi\build.wsf(163, 20) Microsoft JScript runtime error: WiX
compiler returned non-zero.
PS O:\windows-msi>
Please, any help is very welcome!
Thanks in Advance
Rafael
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Added client-ip option to NAT
Hi Arne, I left both options available, at least for now. Either 'client-ip', or 'localhost' as an undocumented alias. This patch to 'client-nat' is necessary to allow it to work properly on a Windows client (not necessary on Linux) of client/server configuration when server issues OVPN DHCP addresses but the client has a static IP. Otherwise the traffic from the Windows client device back through the tunnel uses the DHCP address as source instead of the static IP. And this breaks the system. We have had to use our own build of this for many years now. We have several thousand clients running in this way on our system. Your request not to use 'localhost' is ok. So I changed 'client-ip'. But since we have so many clients already configured with the 'localhost' keyword, we would like to gradually make the transition. We would like to have 'localhost' be an undocumented alias to 'client-ip', at least until we have made the transition. Our hope is that we can do what is necessary to make this option available for others as well and merge it into the main build. When originally searching for a solution the 'client-nat' issue, we noticed that we were not the only ones running into it. BR Rafael On Mon, Jul 25, 2016 at 5:20 AM, Arne Schwabe wrote: > > > Am 05.07.16 um 15:13 schrieb Rafael Gava: > > Hi Arne, sorry for replying so late. > > > > Below is the NAT client-ip patch fixing the messed up whitespaces. > > The only difference from the previous patch, besides the whitespaces, > > is that I'm considering both strings 'client-ip' and 'localhost' as > > valid options. > > > > Please, whatever problem let me know. > Wasn't the general consensus on the mailing list that making localhost > an alias for client-ip is confusing? I wonder why you introduced it again. > > Arne >
Re: [Openvpn-devel] [PATCH] Added client-ip option to NAT
ault gateway. Useful when pushing private subnets.\n" "--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT rule.\n" + " Set the network parameter to 'client-ip' or to 'localhost' to use the received ip from OpenVPN Server.\n" #ifdef ENABLE_PUSH_PEER_INFO "--push-peer-info : (client only) push client info to server.\n" #endif -- 1.7.9.5 On Thu, May 19, 2016 at 6:07 AM, Arne Schwabe wrote: > > > Am 04.05.16 um 19:40 schrieb Rafael Gava: > > Reapplying client-ip NAT patch fixing the following issues raised by > > Arne Schwabe: > > > > - Fixing TABs and whitespaces; > It is now more messed up :( There are a lot of changes to whitespace in > the new patch. > > Arne >
[Openvpn-devel] [PATCH] Added client-ip option to NAT
D); + update_client_ip_nat(c->options.client_nat, c->c1.tuntap->local); + ret = true; static_context = c; #ifndef TARGET_ANDROID diff --git a/src/openvpn/options.c b/src/openvpn/options.c old mode 100644 new mode 100755 index 764ca74..e81d525 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -223,6 +223,7 @@ static const char usage_message[] = "--redirect-private [flags]: Like --redirect-gateway, but omit actually changing\n" " the default gateway. Useful when pushing private subnets.\n" "--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT rule.\n" + " Set the network parameter to 'client-ip' to use the received ip from OpenVPN Server.\n" #ifdef ENABLE_PUSH_PEER_INFO "--push-peer-info : (client only) push client info to server.\n" #endif -- 1.7.9.5 On Thu, Apr 28, 2016 at 1:20 PM, Arne Schwabe wrote: > Am 28.04.16 um 04:01 schrieb Rafael Gava: > > Hi Arne, > > > > what a surprise I thought that the NAT patch had been dropped. :-) > > More or less forgotten. IIrc the active FTP part was controversal. This > part is okay. > > > So, please, should I change the code based on your comments and resend > > the patch? > > Yes, please. > > Arne >
[Openvpn-devel] [PATCH] Added client-ip option to NAT
Allow the user to use the string 'client-ip' on the client-nat network
configuration as a convenient way to use the leased IP address received
from OpenVPN server. Usage Example:
client-nat snat client-ip 255.255.255.255 172.20.1.15 # replaces the
'client-ip' string with the leased IP address received from OpenVPN server
---
>From 2774d25c4c2947be7d1516f01cd520856e683db2 Mon Sep 17 00:00:00 2001
From: Rafael Gava
List-Post: openvpn-devel@lists.sourceforge.net
Date: Mon, 26 Oct 2015 18:31:12 -0200
Subject: [PATCH] Allow the user to use the string 'client-ip' on the
client-nat network configuration as a convenient way to use
the leased IP address received from OpenVPN server. Usage
Example:
client-nat snat client-ip 255.255.255.255 172.20.1.15 # replaces the
'client-ip' string with the leased IP address received from OpenVPN server
Signed-off-by: Rafael Gava
---
src/openvpn/clinat.c | 38 ++
src/openvpn/clinat.h |2 ++
src/openvpn/init.c|2 ++
src/openvpn/options.c |1 +
4 files changed, 43 insertions(+)
mode change 100644 => 100755 src/openvpn/clinat.c
mode change 100644 => 100755 src/openvpn/clinat.h
mode change 100644 => 100755 src/openvpn/init.c
mode change 100644 => 100755 src/openvpn/options.c
diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
old mode 100644
new mode 100755
index ddefe12..2ff4166
--- a/src/openvpn/clinat.c
+++ b/src/openvpn/clinat.c
@@ -124,12 +124,19 @@ add_client_nat_to_option_list (struct
client_nat_option_list *dest,
return;
}
+ if (network && !strcmp(network, "client-ip"))
+{
+ msg (M_INFO, "*** client-nat client-ip detected...");
+ e.network = 0x;
+} else {
e.network = getaddr(0, network, 0, &ok, NULL);
if (!ok)
{
msg(msglevel, "client-nat: bad network: %s", network);
return;
}
+}
+
e.netmask = getaddr(0, netmask, 0, &ok, NULL);
if (!ok)
{
@@ -263,3 +270,34 @@ client_nat_transform (const struct
client_nat_option_list *list,
}
}
}
+
+/*
+* Replaces the client_ip token with the IP received from OpenVPN
+*/
+bool
+update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t
local_ip)
+{
+ int i;
+ bool ret = false;
+
+ if (!dest)
+return ret;
+
+ for (i=0; i <= dest->n; i++)
+{
+ struct client_nat_entry *nat_entry = &dest->entries[i];
+ if (nat_entry && nat_entry->network == 0x)
+{
+ struct in_addr addr;
+
+ nat_entry->network = ntohl(local_ip);
+ addr.s_addr = nat_entry->network;
+ char *dot_ip = inet_ntoa(addr);
+
+ msg (M_INFO, "CNAT - Updating NAT table from client-ip to: %s",
dot_ip);
+ ret = true;
+}
+}
+
+ return ret;
+}
diff --git a/src/openvpn/clinat.h b/src/openvpn/clinat.h
old mode 100644
new mode 100755
index a5779e1..156e84c
--- a/src/openvpn/clinat.h
+++ b/src/openvpn/clinat.h
@@ -62,4 +62,6 @@ void client_nat_transform (const struct
client_nat_option_list *list,
struct buffer *ipbuf,
const int direction);
+bool update_client_ip_nat(struct client_nat_option_list *dest, in_addr_t
local_ip);
+
#endif
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
old mode 100644
new mode 100755
index c5c0ab6..f54bc14
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1481,6 +1481,8 @@ do_open_tun (struct context *c)
c->c1.tuntap->post_open_mtu,
SET_MTU_TUN | SET_MTU_UPPER_BOUND);
+ update_client_ip_nat(c->options.client_nat, c->c1.tuntap->local);
+
ret = true;
static_context = c;
#ifndef TARGET_ANDROID
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
old mode 100644
new mode 100755
index 2f8915d..c08e775
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -223,6 +223,7 @@ static const char usage_message[] =
"--redirect-private [flags]: Like --redirect-gateway, but omit actually
changing\n"
" the default gateway. Useful when pushing private
subnets.\n"
"--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT
rule.\n"
+ " Set the network parameter to 'client-ip' to use the
received ip from OpenVPN Server.\n"
#ifdef ENABLE_PUSH_PEER_INFO
"--push-peer-info : (client only) push client info to server.\n"
#endif
--
1.7.9.5
Re: [Openvpn-devel] [PATCH] Added two features to Network Address Translator
Hello All,
I'm looking forward to hearing from you guys a feedback if the patch for
the features added to the NAT will be accepted or not or if is there
anything else that I need to do or change in order to have it merged into
the code.
>From the previous replies, it seems that a minor change was requested to
replace the localhost string with client-ip.
Anything else?
Thanks in advance,
Rafael
On Tue, Aug 25, 2015 at 10:43 PM, Rafael Gava wrote:
> Hi,
>
> this is my first submission to the list and I hope that I'm doing in the
> right way. :-)
>
>
> Well, the features added to Network Address Translator are:
>
> 1) Allow the user to use the string "localhost" on the client-nat network
> configuration in a way that is not necessary to inform the IP address
> beforehand. Openvpn will set the dynamic received IP from DHCP.
> Example:
>
> client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
> 'localhost' string with the DHCP address received from openvpn server.
>
> 2) Allow the user to enable the FTP NAT support through the
> --enable-nat-ftp-support option.
> This is useful for systems that don't have conntrack-tools support, for
> example on Windows systems. On windows this feature is enabled by default.
>
> enable-nat-ftp-support (yes | no)
>
>
> The following patch was written based on release/2.3 branch.
>
> --
>
> From d11957a025dc6c113874e7b04ce4c8e9513c3b02 Mon Sep 17 00:00:00 2001
> From: venturus
> Date: Thu, 13 Aug 2015 08:26:36 -0300
> Subject: [PATCH] Replaces the client-nat network string 'localhost' with
> the
> dynamic IP set to the tun/tap interface by the openvpn
> server. Example:
>
> --client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
> 'localhost' string with the DHCP address received from openvpn server.
>
> Signed-off-by: Rafael Gava
> ---
> src/openvpn/clinat.c | 57
> ++
> src/openvpn/clinat.h |2 ++
> src/openvpn/init.c |4
> 3 files changed, 54 insertions(+), 9 deletions(-)
> mode change 100644 => 100755 src/openvpn/clinat.c
> mode change 100644 => 100755 src/openvpn/clinat.h
> mode change 100644 => 100755 src/openvpn/init.c
>
> diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
> old mode 100644
> new mode 100755
> index af75fc9..2460185
> --- a/src/openvpn/clinat.c
> +++ b/src/openvpn/clinat.c
> @@ -107,11 +107,11 @@ copy_client_nat_option_list (struct
> client_nat_option_list *dest,
>
> void
> add_client_nat_to_option_list (struct client_nat_option_list *dest,
> - const char *type,
> - const char *network,
> - const char *netmask,
> - const char *foreign_network,
> - int msglevel)
> +const char *type,
> +const char *network,
> +const char *netmask,
> +const char *foreign_network,
> +int msglevel)
> {
>struct client_nat_entry e;
>bool ok;
> @@ -126,12 +126,19 @@ add_client_nat_to_option_list (struct
> client_nat_option_list *dest,
>return;
> }
>
> - e.network = getaddr(0, network, 0, &ok, NULL);
> - if (!ok)
> + if (network && !strcmp(network, "localhost"))
> {
> - msg(msglevel, "client-nat: bad network: %s", network);
> - return;
> + msg (M_INFO, "*** client-nat localhost detected...");
> + e.network = 0x;
> +} else {
> + e.network = getaddr(0, network, 0, &ok, NULL);
> + if (!ok)
> + {
> +msg(msglevel, "client-nat: bad network: %s", network);
> +return;
> + }
> }
> +
>e.netmask = getaddr(0, netmask, 0, &ok, NULL);
>if (!ok)
> {
> @@ -148,6 +155,7 @@ add_client_nat_to_option_list (struct
> client_nat_option_list *dest,
>add_entry(dest, &e);
> }
>
> +
> #if 0
> static void
> print_checksum (struct openvpn_iphdr *iph, const char *prefix)
> @@ -266,4 +274,35 @@ client_nat_transform (const struct
> client_nat_option_list *list,
> }
> }
>
> +/*
> +* Replaces the localhost token with the IP received from OpenVPN
> +*/
> +bool
> +update_localhost_nat(struct client_nat_option_list *dest, in_addr_t
> local_ip)
> +{
> + int i;
> + bool ret = false;
> +
> + if (!dest)
> +return ret;
> +
> + for (i=0; i <= dest->n; i++)
> +{
> + struct client_nat_entry *nat_entry = &dest->entries[i];
>
Re: [Openvpn-devel] [PATCH] Added two features to Network Address Translator
Hi JJK,
"client-ip" instead of "localhost" sounds good to me.
BR
Gava
On Wed, Aug 26, 2015 at 10:01 AM, Jan Just Keijser
wrote:
> Hi,
>
> Rafael Gava wrote:
>
>>
>> this is my first submission to the list and I hope that I'm doing in the
>> right way. :-)
>>
>>
>> Well, the features added to Network Address Translator are:
>>
>> 1) Allow the user to use the string "localhost" on the client-nat network
>> configuration in a way that is not necessary to inform the IP address
>> beforehand. Openvpn will set the dynamic received IP from DHCP. Example:
>>
>> client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
>> 'localhost' string with the DHCP address received from openvpn server.
>>
>> I understand the idea behind it but it would be a NACK from me on the
> string "localhost" - to me, localhost is 127.0.0.1 or ::1, not the DHCP-IP
> ; perhaps use something like "client-ip" ?
>
>
> 2) Allow the user to enable the FTP NAT support through the
>> --enable-nat-ftp-support option. This is useful for systems that don't have
>> conntrack-tools support, for example on Windows systems. On windows this
>> feature is enabled by default.
>>
>> enable-nat-ftp-support (yes | no)
>>
>> sounds like a useful feature to me.
>
>
> JJK
>
>
>> The following patch was written based on release/2.3 branch.
>>
>> --
>>
>> From d11957a025dc6c113874e7b04ce4c8e9513c3b02 Mon Sep 17 00:00:00 2001
>> From: venturus
>> Date: Thu, 13 Aug 2015 08:26:36 -0300
>> Subject: [PATCH] Replaces the client-nat network string 'localhost' with
>> the
>> dynamic IP set to the tun/tap interface by the openvpn
>> server. Example:
>>
>> --client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
>> 'localhost' string with the DHCP address received from openvpn server.
>>
>> Signed-off-by: Rafael Gava > rafael.olive...@venturus.org.br>>
>>
>> ---
>> src/openvpn/clinat.c | 57
>> ++
>> src/openvpn/clinat.h |2 ++
>> src/openvpn/init.c |4
>> 3 files changed, 54 insertions(+), 9 deletions(-)
>> mode change 100644 => 100755 src/openvpn/clinat.c
>> mode change 100644 => 100755 src/openvpn/clinat.h
>> mode change 100644 => 100755 src/openvpn/init.c
>>
>> diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
>> old mode 100644
>> new mode 100755
>> index af75fc9..2460185
>> --- a/src/openvpn/clinat.c
>> +++ b/src/openvpn/clinat.c
>> @@ -107,11 +107,11 @@ copy_client_nat_option_list (struct
>> client_nat_option_list *dest,
>> void
>> add_client_nat_to_option_list (struct client_nat_option_list *dest,
>> - const char *type,
>> - const char *network,
>> - const char *netmask,
>> - const char *foreign_network,
>> - int msglevel)
>> +const char *type,
>> +const char *network,
>> +const char *netmask,
>> +const char *foreign_network,
>> +int msglevel)
>> {
>>struct client_nat_entry e;
>>bool ok;
>> @@ -126,12 +126,19 @@ add_client_nat_to_option_list (struct
>> client_nat_option_list *dest,
>>return;
>> }
>> - e.network = getaddr(0, network, 0, &ok, NULL);
>> - if (!ok)
>> + if (network && !strcmp(network, "localhost"))
>> {
>> - msg(msglevel, "client-nat: bad network: %s", network);
>> - return;
>> + msg (M_INFO, "*** client-nat localhost detected...");
>> + e.network = 0x;
>> +} else {
>> + e.network = getaddr(0, network, 0, &ok, NULL);
>> + if (!ok)
>> + {
>> +msg(msglevel, "client-nat: bad network: %s", network);
>> +return;
>> + }
>> }
>> + e.netmask = getaddr(0, netmask, 0, &ok, NULL);
>>if (!ok)
>> {
>> @@ -148,6 +155,7 @@ add_client_nat_to_option_list (struct
>> client_nat_option_list *dest,
>>add_entry(dest, &e);
>> }
>> +
>> #if 0
>> static void
>> print_checksum (struct openvpn_iphdr *iph, const char *prefix)
>> @@ -266,4 +274,35 @@ client_nat_transform (const struct
>
Re: [Openvpn-devel] [PATCH] Added two features to Network Address Translator
Hi Arne, thanks for the prompt feedback. please see comments in-line: Thanks in advance, Rafael On Wed, Aug 26, 2015 at 5:35 AM, Arne Schwabe wrote: > > > Am 26.08.15 um 03:43 schrieb Rafael Gava: > > Hi, > > this is my first submission to the list and I hope that I'm doing in the > right way. :-) > > Yes submitting patches to the list is the preferred way. I haven't looked > in the patch yet. I am first trying to understand the goal of the patches. > > > Well, the features added to Network Address Translator are: > > 1) Allow the user to use the string "localhost" on the client-nat network > configuration in a way that is not necessary to inform the IP address > beforehand. Openvpn will set the dynamic received IP from DHCP. > Example: > > client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the > 'localhost' string with the DHCP address received from openvpn server. > > > I am not sure what you trying to achieve here? Forward all packets > intended for this host to another? > RafaelGava: yes, exactly!!! Today we have hundreds of boxes on the field, including PCs (Windows) and also embedded devices, all running openvpn with NAT in a way that these boxes work as a kind of router for another bigger equipments. So, the reason for the NAT is that we can establish another virtual network on top of the vpn one and then reach these bigger equipments without changing its local network infrastructure. Let me give an example. Suppose that we have 2 equippments and one openvpn box on the same LAN. The configuration that we are setting on the openvpn client is as showed below: client-nat snat localhost 255.255.255.255 172.20.1.15 # vpn box. Note that with the localhost string, we don't need to worry which IP it will get from openvpn server. client-nat snat 10.10.10.132 255.255.255.255 172.20.1.16 # Equipment 1 client-nat snat 10.10.10.134 255.255.255.255 172.20.1.17 # Equipment 2 So, with this configuration it's possible to reach these 2 equipments through the 172.20.1 network. In general, a subnet is set for each openvpn box. > 2) Allow the user to enable the FTP NAT support through the > --enable-nat-ftp-support option. > This is useful for systems that don't have conntrack-tools support, for > example on Windows systems. On windows this feature is enabled by default. > > enable-nat-ftp-support (yes | no) > > Okay yes. Active FTP is broken by our simple nat implementation. But I > think FTP, let alone active FTP is dead. I am not sure if we should support > this in our simple NAT implementation. > RafaelGava: I agree with you but unfortunately there are a huge legacy of proprietary equipments on the field that still use Active FTP and we have no control over them. So, based on these items and difficulties that the patch was written. > > > Arne >
[Openvpn-devel] [PATCH] Added two features to Network Address Translator
Hi,
this is my first submission to the list and I hope that I'm doing in the
right way. :-)
Well, the features added to Network Address Translator are:
1) Allow the user to use the string "localhost" on the client-nat network
configuration in a way that is not necessary to inform the IP address
beforehand. Openvpn will set the dynamic received IP from DHCP.
Example:
client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
'localhost' string with the DHCP address received from openvpn server.
2) Allow the user to enable the FTP NAT support through the
--enable-nat-ftp-support option.
This is useful for systems that don't have conntrack-tools support, for
example on Windows systems. On windows this feature is enabled by default.
enable-nat-ftp-support (yes | no)
The following patch was written based on release/2.3 branch.
--
>From d11957a025dc6c113874e7b04ce4c8e9513c3b02 Mon Sep 17 00:00:00 2001
From: venturus
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 13 Aug 2015 08:26:36 -0300
Subject: [PATCH] Replaces the client-nat network string 'localhost' with the
dynamic IP set to the tun/tap interface by the openvpn
server. Example:
--client-nat snat localhost 255.255.255.255 172.20.1.15 # replaces the
'localhost' string with the DHCP address received from openvpn server.
Signed-off-by: Rafael Gava
---
src/openvpn/clinat.c | 57
++
src/openvpn/clinat.h |2 ++
src/openvpn/init.c |4
3 files changed, 54 insertions(+), 9 deletions(-)
mode change 100644 => 100755 src/openvpn/clinat.c
mode change 100644 => 100755 src/openvpn/clinat.h
mode change 100644 => 100755 src/openvpn/init.c
diff --git a/src/openvpn/clinat.c b/src/openvpn/clinat.c
old mode 100644
new mode 100755
index af75fc9..2460185
--- a/src/openvpn/clinat.c
+++ b/src/openvpn/clinat.c
@@ -107,11 +107,11 @@ copy_client_nat_option_list (struct
client_nat_option_list *dest,
void
add_client_nat_to_option_list (struct client_nat_option_list *dest,
- const char *type,
- const char *network,
- const char *netmask,
- const char *foreign_network,
- int msglevel)
+const char *type,
+const char *network,
+const char *netmask,
+const char *foreign_network,
+int msglevel)
{
struct client_nat_entry e;
bool ok;
@@ -126,12 +126,19 @@ add_client_nat_to_option_list (struct
client_nat_option_list *dest,
return;
}
- e.network = getaddr(0, network, 0, &ok, NULL);
- if (!ok)
+ if (network && !strcmp(network, "localhost"))
{
- msg(msglevel, "client-nat: bad network: %s", network);
- return;
+ msg (M_INFO, "*** client-nat localhost detected...");
+ e.network = 0x;
+} else {
+ e.network = getaddr(0, network, 0, &ok, NULL);
+ if (!ok)
+ {
+msg(msglevel, "client-nat: bad network: %s", network);
+return;
+ }
}
+
e.netmask = getaddr(0, netmask, 0, &ok, NULL);
if (!ok)
{
@@ -148,6 +155,7 @@ add_client_nat_to_option_list (struct
client_nat_option_list *dest,
add_entry(dest, &e);
}
+
#if 0
static void
print_checksum (struct openvpn_iphdr *iph, const char *prefix)
@@ -266,4 +274,35 @@ client_nat_transform (const struct
client_nat_option_list *list,
}
}
+/*
+* Replaces the localhost token with the IP received from OpenVPN
+*/
+bool
+update_localhost_nat(struct client_nat_option_list *dest, in_addr_t
local_ip)
+{
+ int i;
+ bool ret = false;
+
+ if (!dest)
+return ret;
+
+ for (i=0; i <= dest->n; i++)
+{
+ struct client_nat_entry *nat_entry = &dest->entries[i];
+ if (nat_entry && nat_entry->network == 0x)
+{
+ struct in_addr addr;
+
+ nat_entry->network = ntohl(local_ip);
+ addr.s_addr = nat_entry->network;
+ char *dot_ip = inet_ntoa(addr);
+
+ msg (M_INFO, "Updating NAT table from localhost to: %s",
dot_ip);
+ ret = true;
+}
+}
+
+ return ret;
+}
+
#endif
diff --git a/src/openvpn/clinat.h b/src/openvpn/clinat.h
old mode 100644
new mode 100755
index d55a727..ce995d9
--- a/src/openvpn/clinat.h
+++ b/src/openvpn/clinat.h
@@ -62,4 +62,6 @@ void client_nat_transform (const struct
client_nat_option_list *list,
struct buffer *ipbuf,
const int direction);
+bool update_localhost_nat(struct client_nat_option_list *dest, in_addr_t
local_ip);
+
#endif
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
old mode 100644
new mode 100755
index 71c91a2..4a63ee8
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1476,6 +1476,10 @@ do_open_tun (struct context *c)
c-&g
