Jan Just Keijser | 3 Jul 13:02 2015
Picon
Picon

Adding routes on Windows using DHCP

hi all,

whilst writing the TFTP/WPAD patch I stumbled upon the options to set a 
default gateway and/or routes using DHCP options.
I've patched openvpn to also set DHCP option 3 ("gateway") and indeed, 
windows picks up the route supplied to it  :)

This might be a way to address this topic from the IRC meeting:

Windows 8.1 DNS registration issues

    * ipconfig failing to execute during VPN connection
      <https://community.openvpn.net/openvpn/ticket/516>
    * Who will fix and how?

It's even possible to run openvpn without admin privileges and set 
routes this way!
Before you get too excited: it does not seem to be possible to replace 
an existing default GW this way. the new 0.0.0.0 route has the metric of 
the tap-win32 adapter , which is better than that of a wifi adapter but 
worse (30 == higher) than that of a regular LAN Adapter (metric=10).

Before I go any deeper into this: what does the rest think about setting 
routes on Windows this way? It could be a nice way to circumvent all 
kinds of "route add" problems.

cheers,

JJK

(Continue reading)

Jan Just Keijser | 2 Jul 11:56 2015
Picon
Picon

[PATCH] Add TFTP and WPAD DHCP options

Attached is the patch to add the TFTP and WPAD DHCP options. The patch 
is based on openvpn 2.3.7 as I did not know how to do a windows mingw 
build of the git version ...
The patch was tested on Windows XP 32bit and Windows 7sp1 64bit.
A 64bit windows binary can be found  <at>  
http://www.nikhef.nl/~janjust/openvpn-2.3.7-dhcp-win64.exe

Signed-off-by: Jan Just Keijser <janjust <at> nikhef.nl>

--- openvpn-2.3.7/src/openvpn/options.c 2015-06-02 10:01:24.000000000 +0200
+++ /tmp/build-x86_64/openvpn-2.3.7/src/openvpn/options.c       
2015-07-02 11:47:24.291216980 +0200
 <at>  <at>  -692,11 +692,13  <at>  <at> 
   "                    DNS addr    : Set domain name server address(es)\n"
   "                    NTP         : Set NTP server address(es)\n"
   "                    NBDD        : Set NBDD server address(es)\n"
+  "                    TFTP        : Set TFTP server address(es)\n"
   "                    WINS addr   : Set WINS server address(es)\n"
   "                    NBT type    : Set NetBIOS over TCP/IP Node type\n"
   "                                  1: B, 2: P, 4: M, 8: H\n"
   "                    NBS id      : Set NetBIOS scope ID\n"
   "                    DISABLE-NBT : Disable Netbios-over-TCP/IP.\n"
+  "                    WPAD url    : Set WebProxy AutoDiscovery url\n"
   "--dhcp-renew       : Ask Windows to renew the TAP adapter lease on 
startup.\n"
   "--dhcp-pre-release : Ask Windows to release the previous TAP adapter 
lease on\n"
 "                       startup.\n"
 <at>  <at>  -1119,6 +1121,8  <at>  <at> 
   SHOW_STR (netbios_scope);
(Continue reading)

Fish Wang | 1 Jul 21:47 2015
Picon

Compiling issue on Visual Studio 2010

Hi,

 

Visual Studio 2010 refuses to compile the latest code on branch release/2.3 because __func__ is not supported. Microsoft supports __FUNCTION__ instead of __func__ in their compiler. VS 2013 complains the same.

 

The following patch resolves this issue.

 

 

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c

index aa93a7b..c4fda84 100644

--- a/src/openvpn/crypto.c

+++ b/src/openvpn/crypto.c

<at> <at> -423,7 +423,7 <at> <at> crypto_adjust_frame_parameters(struct frame *frame,

   frame_add_to_extra_frame (frame, crypto_overhead);

 

   msg(D_MTU_DEBUG, "%s: Adjusting frame parameters for crypto by %zu bytes",

-      __func__, crypto_overhead);

+      CURRENT_FUNCTION, crypto_overhead);

}

 

/*

diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h

index e489827..66704ba 100644

--- a/src/openvpn/crypto.h

+++ b/src/openvpn/crypto.h

<at> <at> -459,6 +459,15 <at> <at> key_ctx_bi_defined(const struct key_ctx_bi* key)

   return key->encrypt.cipher || key->encrypt.hmac || key->decrypt.cipher || key->decrypt.hmac;

}

 

+/*

+ * __func__ is not yet supported on Visual Studio 2013

+ */

+

+#ifdef _MSC_VER

+    #define CURRENT_FUNCTION __FUNCTION__

+#else

+    #define CURRENT_FUNCTION __func__

+#endif

 

#endif /* ENABLE_CRYPTO */

#endif /* CRYPTO_H */

 

Best,

Fish

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Gert Doering | 1 Jul 17:40 2015
Picon

RfD: speed up PUSH_REQUEST...

Hi,

experimenting with the MTU patch, I discovered that we basically sit
idle for two seconds on the client between "TLS is up!" and "PUSH_REQUEST".

This is part due to the coarse granularity of, well, our coarse timers,
but in part due to *two* timers having to fire...

- TLS is done, we schedule an "wait_for_connect" timer to fire in +1 second
  (init.c, do_init_timers())

- when that timer fires, 1 second after TLS completes, we set up *another*
  timer inside check_connection_established_dowork(), that is intended to
  fire in +1 second

- +1 second later, we send PUSH_REQUEST

due to the calling sequence and check_push_request() being called right
after check_connection_established(), it seems to be fairly safe to just
set up the event to "fire right away" (*having* the event is needed to
be able to reset it to "fire again in +5 seconds").

So, with the patch below on top of the MTU patch, connection times to a
server which is 150ms away from me went down from 5 seconds to 2 seconds
- which I consider quite significant :-)

Anyone better versed in the history of this code who can tell me whether
this is safe, or why the extra delay is there?

gert

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 6d459d2..e1571ec 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
 <at>  <at>  -212,8 +212,8  <at>  <at>  check_connection_established_dowork (struct context *c)
 					0);
 		}
 #endif
-	      /* send push request in 1 sec */
-	      event_timeout_init (&c->c2.push_request_interval, 1, now);
+	      /* fire up push request right away (already 1s delayed) */
+	      event_timeout_init (&c->c2.push_request_interval, 0, now);
 	      reset_coarse_timers (c);
 	    }
 	  else
--

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert <at> greenie.muc.de
fax: +49-89-35655025                        gert <at> net.informatik.tu-muenchen.de
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
debbie10t | 1 Jul 15:22 2015
Picon

OpenVPN 2.3.7-I602-x86_64.exe download 404 Error

>On Wed, Jul 01, 2015 at 12:07:11PM +0100, debbie10t <at> gmail.com wrote:
>> It's been OFFLINE for a couple of days now ...
>>
>> https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.7-I602-x86_64.exe
>
>Please do not hijack other people's threads by just replying to anything
>that just happens to come along the right mailing list.  Reasonable
>mail readers thread mails, and your mail got attached to the MTU v2 patch
>from Steffan, which it does not have *anything* to do with - annoyance.
>

Sorry .. I must have hit reply to something accidentally
It is very hot here today ..

>Besides that, I just tried the download (with Chrome), and it worked
>perfectly well...

Sorry, still does not work for me and others:

https://forums.openvpn.net/topic19158.html

Tried from various systems.

>
>("couple of days" is interesting, given that Samuli only released I602
>about 44 hours ago...)

44 hours is near enough 2 days ...

Again .. apologies.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
steffan.karger | 1 Jul 13:03 2015

[PATCH] Fix overflow check in openvpn_decrypt()

From: Steffan Karger <steffan.karger <at> fox-it.com>

Sebastian Krahmer from the SuSE security team reported that the buffer
overflow check in openvpn_decrypt() was too strict according to the
cipher update function contract:

"The amount of data written depends on the block alignment of the
encrypted data: as a result the amount of data written may be anything
from zero bytes to (inl + cipher_block_size - 1) so outl should contain
sufficient room."

This stems from the way CBC mode works, which caches input and 'flushes'
it block-wise to the output buffer.  We do allocate enough space for this
extra block in the output buffer for CBC mode, but not for CFB/OFB modes.

This patch:
 * updates the overflow check to also verify that the extra block required
   according to the function contract is available.
 * uses buf_inc_len() to double-check for overflows during en/decryption.
 * also reserves the extra block for non-CBC cipher modes.

In practice, I could not find a way in which this would fail. The plaintext
is never longer than the ciphertext, and the implementations of CBC/OFB/CBC
for AES and BF in both OpenSSL and PolarSSL/mbed TLS do not use the buffer
beyond the plaintext length when decrypting.  However, some funky OpenSSL
engine I did not check *might* use the buffer space required by the
function contract.  So we should still make sure we have enough room
anyway.

Signed-off-by: Steffan Karger <steffan.karger <at> fox-it.com>
---
 src/openvpn/crypto.c         | 21 +++++++++++----------
 src/openvpn/crypto_backend.h |  2 +-
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index d15c85a..49e61d3 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
 <at>  <at>  -156,11 +156,11  <at>  <at>  openvpn_encrypt (struct buffer *buf, struct buffer work,

 	  /* Encrypt packet ID, payload */
 	  ASSERT (cipher_ctx_update (ctx->cipher, BPTR (&work), &outlen, BPTR (buf), BLEN (buf)));
-	  work.len += outlen;
+	  ASSERT (buf_inc_len(&work, outlen));

 	  /* Flush the encryption buffer */
-	  ASSERT(cipher_ctx_final(ctx->cipher, BPTR (&work) + outlen, &outlen));
-	  work.len += outlen;
+	  ASSERT (cipher_ctx_final(ctx->cipher, BPTR (&work) + outlen, &outlen));
+	  ASSERT (buf_inc_len(&work, outlen));

 	  /* For all CBC mode ciphers, check the last block is complete */
 	  ASSERT (cipher_kt_mode (cipher_kt) != OPENVPN_MODE_CBC ||
 <at>  <at>  -298,18 +298,20  <at>  <at>  openvpn_decrypt (struct buffer *buf, struct buffer work,
 	    CRYPT_ERROR ("cipher init failed");

 	  /* Buffer overflow check (should never happen) */
-	  if (!buf_safe (&work, buf->len))
-	    CRYPT_ERROR ("buffer overflow");
+	  if (!buf_safe (&work, buf->len + cipher_ctx_block_size(ctx->cipher)))
+	    CRYPT_ERROR ("potential buffer overflow");

 	  /* Decrypt packet ID, payload */
 	  if (!cipher_ctx_update (ctx->cipher, BPTR (&work), &outlen, BPTR (buf), BLEN (buf)))
 	    CRYPT_ERROR ("cipher update failed");
-	  work.len += outlen;
+	  if (!buf_inc_len(&work, outlen))
+	    CRYPT_ERROR ("cipher update buffer overflow");

 	  /* Flush the decryption buffer */
 	  if (!cipher_ctx_final (ctx->cipher, BPTR (&work) + outlen, &outlen))
 	    CRYPT_ERROR ("cipher final failed");
-	  work.len += outlen;
+	  if (!buf_inc_len(&work, outlen))
+	    CRYPT_ERROR ("cipher final buffer overflow");

 	  dmsg (D_PACKET_CONTENT, "DECRYPT TO: %s",
 	       format_hex (BPTR (&work), BLEN (&work), 80, &gc));
 <at>  <at>  -395,9 +397,8  <at>  <at>  crypto_adjust_frame_parameters(struct frame *frame,
       if (use_iv)
 	crypto_overhead += cipher_kt_iv_size (kt->cipher);

-      if (cipher_kt_mode_cbc (kt->cipher))
-	/* worst case padding expansion */
-	crypto_overhead += cipher_kt_block_size (kt->cipher);
+      /* extra block required by cipher_ctx_update() */
+      crypto_overhead += cipher_kt_block_size (kt->cipher);
     }

   crypto_overhead += kt->hmac_length;
diff --git a/src/openvpn/crypto_backend.h b/src/openvpn/crypto_backend.h
index 4e45df0..4c1ce9f 100644
--- a/src/openvpn/crypto_backend.h
+++ b/src/openvpn/crypto_backend.h
 <at>  <at>  -333,7 +333,7  <at>  <at>  int cipher_ctx_reset (cipher_ctx_t *ctx, uint8_t *iv_buf);
  * Note that if a complete block cannot be written, data is cached in the
  * context, and emitted at a later call to \c cipher_ctx_update, or by a call
  * to \c cipher_ctx_final(). This implies that dst should have enough room for
- * src_len + \c cipher_ctx_block_size() - 1.
+ * src_len + \c cipher_ctx_block_size().
  *
  *  <at> param ctx 		Cipher's context. May not be NULL.
  *  <at> param dst		Destination buffer
--

-- 
2.1.0

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
Steffan Karger | 30 Jun 21:44 2015

[PATCH v2] Increase control channel packet size for faster handshakes

Instead of limiting the control channel TCP/UDP packet payload size at
'100 bytes + real control channel overhead' (~140 bytes ethernet payload),
increase the max TCP/UDP payload size to '1250 bytes - calculated overhead'
(~1210 bytes ethernet payload).

Note that this patch does *not* yield an optimal solution, but it is a
simple and rather safe change that will improve connection setup times
significantly.

v2: use the mininum value of --link-mtu and 1250 to give the user a way to
    reduce control packet size if really needed.

Signed-off-by: Steffan Karger <steffan <at> karger.me>
---
 src/openvpn/ssl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index bc17fd0..e61e0aa 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
 <at>  <at>  -299,8 +299,9  <at>  <at>  tls_init_control_channel_frame_parameters(const struct frame *data_channel_frame
   reliable_ack_adjust_frame_parameters (frame, CONTROL_SEND_ACK_MAX);
   frame_add_to_extra_frame (frame, SID_SIZE + sizeof (packet_id_type));

-  /* set dynamic link MTU to minimum value */
-  frame_set_mtu_dynamic (frame, 0, SET_MTU_TUN);
+  /* set dynamic link MTU to cap control channel packets at 1250 bytes */
+  ASSERT (TUN_LINK_DELTA (frame) < min_int (frame->link_mtu, 1250));
+  frame->link_mtu_dynamic = min_int (frame->link_mtu, 1250) - TUN_LINK_DELTA (frame);
 }

 void
--

-- 
2.1.4

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
Steffan Karger | 29 Jun 22:59 2015

[PATCH] Increase control channel packet size for faster handshakes

Instead of limiting the control channel TCP/UDP packet payload size at
'100 bytes + real control channel overhead' (~140 bytes ethernet payload),
increase the max TCP/UDP payload size to '1250 bytes - calculated overhead'
(~1210 bytes ethernet payload).  This decreases the number of packets
required to establish a connection by a factor 10, but still has a
comfortable enough margin to succeed for lower-MTU connections.

This should especially help out for complex configs (trac #545), but also
for high-latency connections (trac #543).

Note that this patch does *not* yield an optimal solution, but it is a
simple and rather safe change that will improve connection setup times
significantly.

Signed-off-by: Steffan Karger <steffan <at> karger.me>
---
 src/openvpn/ssl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index bc17fd0..cde820d 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
 <at>  <at>  -299,8 +299,9  <at>  <at>  tls_init_control_channel_frame_parameters(const struct frame *data_channel_frame
   reliable_ack_adjust_frame_parameters (frame, CONTROL_SEND_ACK_MAX);
   frame_add_to_extra_frame (frame, SID_SIZE + sizeof (packet_id_type));

-  /* set dynamic link MTU to minimum value */
-  frame_set_mtu_dynamic (frame, 0, SET_MTU_TUN);
+  /* set dynamic link MTU to cap control channel packets at 1250 bytes */
+  ASSERT(TUN_LINK_DELTA(frame) < 1250);
+  frame->link_mtu_dynamic = 1250 - TUN_LINK_DELTA(frame);
 }

 void
--

-- 
2.1.4

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
Samuli Seppänen | 29 Jun 17:46 2015
Picon

New OpenVPN 2.3.7 installers released

Hello everyone,

New OpenVPN Windows installers (2.3.7-I602) have been released and can 
be downloaded from the downloads page:

<https://openvpn.net/index.php/download/community-downloads.html>

The installers bundle the latest OpenSSL version (1.0.1o) which includes 
several security fixes. Based on our research the vulnerabilities should 
not affect OpenVPN or can be mitigated, but an upgrade is still recommended.

--

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
Arne Schwabe | 29 Jun 14:46 2015

[PATCH] Report missing endtags of inline files as warnings

---
 src/openvpn/options.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 74276d4..24efb59 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
 <at>  <at>  -3703,10 +3703,15  <at>  <at>  read_inline_file (struct in_src *is, const char *close_tag, struct gc_arena *gc)
   char line[OPTION_LINE_SIZE];
   struct buffer buf = alloc_buf (8*OPTION_LINE_SIZE);
   char *ret;
+  bool endtagfound = false;
+
   while (in_src_get (is, line, sizeof (line)))
     {
       if (!strncmp (line, close_tag, strlen (close_tag)))
-	break;
+	{
+	  endtagfound = true;
+	  break;
+	}
       if (!buf_safe (&buf, strlen(line)))
 	{
 	  /* Increase buffer size */
 <at>  <at>  -3718,6 +3723,8  <at>  <at>  read_inline_file (struct in_src *is, const char *close_tag, struct gc_arena *gc)
 	}
       buf_printf (&buf, "%s", line);
     }
+  if (!endtagfound)
+    msg (M_WARN, "WARNING: Endtag %s missing", close_tag);
   ret = string_alloc (BSTR (&buf), gc);
   buf_clear (&buf);
   free_buf (&buf);
--

-- 
2.3.2 (Apple Git-55)

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
Samuli Seppänen | 29 Jun 11:59 2015
Picon

Topics for today's (Monday, 29th June 2015) community meeting

Hi,

We're going to have an IRC meeting today, 29th June, starting at 20:00 
CEST (18:00 UTC) on #openvpn-devel <at> irc.freenode.net. Current topic 
list along with basic information is here:

<https://community.openvpn.net/openvpn/wiki/Topics-2015-06-29>

If you have any other things you'd like to bring up, respond to this 
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments 
on the topics by responding to this email or to the summary email sent 
after the meeting. Whenever possible, we'll also respond to existing, 
related email threads.

NOTE: It's required to use a registered Freenode IRC nickname to join 
#openvpn-devel - look here for details:

<https://community.openvpn.net/openvpn/wiki/GettingHelp#DeveloperIRCchannel>

--

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o

Gmane