This fixes the bug of supporting --no-iv (since we're only accepting
bugfixes in the current release phase ;) ).
The --no-iv function decreases security if used (CBC *requires*
unpredictable IVs, other modes don't allow --no-iv at all), and even
marginally decreases other user's security by adding unwanted
complexity to our code.
Let's get rid of this.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1481138447-6292-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13430.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Also correct the default ifconfig-pool end in docs and comments
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1480707729-19578-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13387.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As reported and discussed on Trac #775, restarting dns service has
unwanted side effects when there are dependent services. And it
appears unnecessary to restart this service to get DNS registered
on Windows.
Resolve by removing two actions from --register-dns:
'net stop dnscache' and 'net start dnscache' run through the service
or directly.
Trac: #775
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1480542696-7123-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13331.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
- Any existing addresses are deleted before adding
- On close_tun all addresses are deleted (only if any were added)
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1479958527-29491-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13222.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Allows non-NCP peers (<= 2.3, or 2.4+ with --ncp-disable) to specify a
--cipher that is different from the one in our config, as long as the new
cipher value is allowed (i.e. in --ncp-ciphers at our side).
This works both client-to-server and server-to-client. I.e. a 2.4 client
with "cipher BF-CBC" and "ncp-ciphers AES-256-GCM:AES-256-CBC" can connect
to both a 2.3 server with "cipher BF-CBC" as well as a server with
"cipher AES-256-CBC" in its config. The other way around, a 2.3 client
with either "cipher BF-CBC" or "cipher AES-256-CBC" can connect to a 2.4
server with e.g. "cipher BF-CBC" and "ncp-ciphers AES-256-GCM:AES-256-CBC"
in its config.
This patch was inspired by Gert's "Poor man's NCP for 2.3 clients" patch,
but takes a different approach to avoid the need for server-side scripts
or client-side 'setenv UV_*' tricks.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1479936104-4045-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13218.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This isn't an option to be used directly in any configuration files,
but to be used via --client-connect scripts or --plugin making use of
OPENVPN_PLUGIN_CLIENT_CONNECT or OPENVPN_PLUGIN_CLIENT_CONNECT_V2.
[v2 - Added lacking .B styling of options
- Clarified the token life time ]
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1474118415-14666-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12506.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
v2: On closing tun delete the ipv6 dns addresses (if any were set).
Also use "validate=no" only in Windows 7 and higher where it is
supported. Its used to skip the time consuming automatic address
validation which is on by default on those platforms.
Tested on Windows Server 2008 (i686), Win 7 (x64) and Win 10 (x64)
TODO: set dns servers using the interactive service
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1479784332-21680-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13193.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This defines a new DHCP suboption "DNS6", but does not actually
implement anything but "document the option and understand it".
If received, it will be put into an "foreign_option_<n>" environment
variable where an --up script or plugin could receive and act upon it.
On non-Windows platforms, all "dhcp-option" sub-options end up there,
so v4 and v6 DNS options will be reflected like this:
foreign_option_1=dhcp-option DNS6 2001:608::2
foreign_option_2=dhcp-option DNS 195.30.0.2
v2: do not set o->dhcp_options if DNS6 is the single dhcp-option seen
(spotted by Selva Nair)
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <1479746562-751-1-git-send-email-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13174.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In OpenVPN 2.3 --tls-remote got deprecated in favour of --verify-x509-name.
The new option solves the same task as --tls-remote but in a more flexible
and improved way. This new option was introduced in commit 9f0fc74566
(release/2.3: f6e12862ce). Removing --tls-remote will only require
a minor configuration file change.
The removal of this option has been documented in the man pages since the
release of OpenVPN v2.3, where also the deprecation of --compat-names and
--no-name-remapping was included. However, those two will first be removed
in OpenVPN v2.5.
The reason not to remove --compat-names and --no-name-remapping now is that
such a change will require TLS verification scripts and plug-ins to be
updated to support the new X.509 subject formatting; which
--verify-x509-name already uses.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1479217256-21298-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13070.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This adds a --tls-crypt option, which uses a pre-shared static key (like
the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
* It provides more privacy by hiding the certificate used for the TLS
connection.
* It is harder to identify OpenVPN traffic as such.
* It provides "poor-man's" post-quantum security, against attackers who
will never know the pre-shared key (i.e. no forward secrecy).
Control channel packet encryption
---------------------------------
We propose to use the following encryption method, based on the SIV
construction [0], to achieve nonce misuse-resistant authenticated
encryption:
msg = control channel plaintext
header = opcode (1 byte) || session_id (8 bytes) || packet_id (8
bytes)
Ka = authentication key (256 bits)
Ke = encryption key (256 bits)
(Ka and Ke are pre-shared keys, like with --tls-auth)
auth_tag = HMAC-SHA256(Ka, header || msg)
IV = 128 most-significant bits of auth_tag
ciph = AES256-CTR(Ke, IV, msg)
output = Header || Tag || Ciph
This boils down to the following on-the-wire packet format:
-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
Where
- XXX - means authenticated, and
* XXX * means authenticated and encrypted.
Which is very similar to the current tls-auth packet format, and has the
same overhead as "--tls-auth" with "--auth SHA256".
The use of a nonce misuse-resistant authenticated encryption scheme
allows us to worry less about the risks of nonce collisions. This is
important, because in contrast with the data channel in TLS mode, we
will not be able to rotate tls-crypt keys often or fully guarantee nonce
uniqueness. For non misuse-resistant modes such as GCM [1], [2], the
data channel in TLS mode only has to ensure that the packet counter
never rolls over, while tls-crypt would have to provide nonce uniqueness
over all control channel packets sent by all clients, for the lifetime
of the tls-crypt key.
Unlike with tls-auth, no --key-direction has to be specified for
tls-crypt. TLS servers always use key direction 1, and TLS clients
always use key direction 2, which means that client->server traffic and
server->client traffic always use different keys, without requiring
configuration.
Using fixed, secure, encryption and authentication algorithms makes both
implementation and configuration easier. If we ever want to, we can
extend this to support other crypto primitives. Since tls-crypt should
provide privacy as well as DoS protection, these should not be made
negotiable.
Security considerations:
------------------------
tls-crypt is a best-effort mechanism that aims to provide as much
privacy and security as possible, while staying as simple as possible.
The following are some security considerations for this scheme.
1. The same tls-crypt key is potentially shared by a lot of peers, so it
is quite likely to get compromised. Once an attacker acquires the
tls-crypt key, this mechanism no longer provides any security against
the attacker.
2. Since many peers potentially use the tls-crypt key for a long time, a
lot of data might be encrypted under the tls-crypt key. This leads
to two potential problems:
* The "opcode || session id || packet id" combination might collide.
This might happen in larger setups, because the session id contains
just 64 bits or random. Using the uniqueness requirement from the
GCM spec [3] (a collision probability of less than 2^(-32)),
uniqueness is achieved when using the tls-crypt key for at most
2^16 (65536) connections per process start. (The packet id
includes the daemon start time in the packet ID, which should be
different after stopping and (re)starting OpenPVN.)
And if a collision happens, an attacker can *only* learn whether
colliding packets contain the same plaintext. Attackers will not
be able to learn anything else about the plaintext (unless the
attacker knows the plaintext of one of these packets, of course).
Since the impact is limited, I consider this an acceptable
remaining risk.
* The IVs used in encryption might collide. When two IVs collide, an
attacker can learn the xor of the two plaintexts by xorring the
ciphertexts. This is a serious loss of confidentiality. The IVs
are 128-bit, so when HMAC-SHA256 is a secure PRF (an assumption
that must also hold for TLS), and we use the same uniqueness
requirement from [3], this limits the total amount of control
channel messages for all peers in the setup to 2^48. Assuming a
large setup of 2^16 (65536) clients, and a (conservative) number of
2^16 control channel packets per connection on average, this means
that clients may set up 2^16 connections on average. I think these
numbers are reasonable.
(I have a follow-up proposal to use client-specific tls-auth/tls-crypt
keys to partially mitigate these issues, but let's tackle this patch
first.)
References:
-----------
[0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap
Problem, 2006
(https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
[1] Ferguson, Authentication weaknesses in GCM, 2005
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferg
uson2.pdf)
[2] Joux, Authentication Failures in NIST version of GCM, 2006
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Serie
s-Drafts/GCM/Joux_comments.pdf)
[3] Dworking, Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, 2007
(http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf)
Patch history:
--------------
v2 - processed Arne's review comments:
* Error out early with a clear error message when AES-256-CTR or
HMAC-SHA-256 are not supported by the crypto library.
* Clarify that cipher_ctx_reset() sets the IV.
v3 - actually add error messages promised in v2...
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1479216586-20078-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13069.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
With c99, "WIN32" is no longer automatically defined when (cross-)building
for Windows, and proper compilation relies on including <windefs.h>,
before checking the macro. "_WIN32" is the official define that is
guaranteed to be defined by the compiler itself, no includes are needed.
So, mechanically change all occurrances of "WIN32" to "_WIN32".
While at it, get rid of unused WIN32_0_1 #define in syshead.h
See also:
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefi
ned_macros_detect_operating_system#WindowsCygwinnonPOSIXandMinGW
Trac #746
v2: rebased to master, merge the console[_builtin].c changes
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20161113195228.74090-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13035.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Key method 2 has been the default since OpenVPN 2.0, and is both more
functional and secure. Also, key method 1 was only ever supported for
peer-to-peer connections (i.e. not for client-server).
Let's get rid of some legacy and phase out key method 1.
v2: add Changes.rst entry, and update man page
[ DS: Slightly modified patch, rewored the warning message and the
Changes.rst note to encourage not to set --key-method at all ]
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1479153967-6788-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13054.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
v4:
- Account for IP header offset in TAP mode
- Correct handle of non-IP protocols in TAP mode
v3: Use better way of figuring out IP proto version which
does not break TAP mode. Add an option to allow recursive
routing, could be useful when packets sent by openvpn itself
are not subject to the routing tables that would move packets
into the tunnel.
v2: better method naming
On certain OSes (Windows, OS X) when network adapter is
disabled (ethernet cable pulled off, Wi-Fi hardware switch disabled),
operating system starts to use tun as an external interface.
Outgoing packets are routed to tun, UDP encapsulated, given to
routing table and sent to.. tun.
As a consequence, system starts talking to itself on full power,
traffic counters skyrocket and user is not happy.
To prevent that, drop packets which have gateway IP as
destination address.
Tested on Win7/10, OS X, Linux.
Trac #642
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1478208503-25929-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12894.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Just minor clarifications and corrections of the --keepalive option.
v2 - Changed from ps/pto to interval/timeout
- Rephrased the server-side timeout doubling parapgraph
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1478007489-17163-1-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12866.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This sets the flag if the OpenVPN server should create authentication
tokens on-the-fly on successful --auth-user-pass-verify or --plugin with
OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY processing.
If an OpenVPN server is running without this option, it should behave
as before. Next patches will implement the auth-token generation and
passing it on to the clients.
The --auth-gen-token can be given an optional integer argument which
defines the lifetime of generated tokens. The lifetime argument
must be given in number of seconds.
v2 - Update Changes.rst
- Improve man page in regards to lifetime argument
- Rename struct member auth_generate_token to auth_token_generate
to have a consistent naming scheme
Signed-off-by: David Sommerseth <davids@openvpn.net>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <1477684124-26083-2-git-send-email-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12825.html
- Add `` to all options
- Sort and group new features
- Group changes a bit better
- Fix some formatting/formulation
Patch V2:
- add missing quote, noticed by Samuli
- add new windows services
- add ECDH
- add pushable compression
- add Android and AIX platform support
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1477060957-6423-1-git-send-email-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12766.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Following the earlier warning about small block ciphers, now limit the
--reneg-bytes value when using a cipher that susceptible to SWEET32-like
attacks. The 64 MB value has been selected with the researchers who
published the SWEET32 paper.
Note that this will not change a user-set --reneg-bytes value, to allow a
user to align a gun with his feet^w^w^w^w^w^w override this behaviour if
really needed.
v2: obey user-set --reneg-bytes 0 to revert to old behaviour, use more firm
language in warning message, and add URL to man page.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1477655821-6711-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12798.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
This option was useful when IPv6 tun support was non standard and was an
internal/user specified flag that tracked the Ipv6 capability of the tun
device.
All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so
not putting tun-ipv6 does not forbid ipv6 addresses.
This commit also clean up a bit of the ipv6 related tun.c. Changes for
most platforms are minimal.
For linux a bit more cleanup is done:
- Remove compatibility defines that were added 2008
- Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun
setups (Android also always IFF_NO_PI works fine with Ipv6).
This commit also remove a non ipv6 fallback for tap driver from OpenVPN
2.2-beta or earlier and only warns.
Patch V2: Integrate Gert's comments
Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there
it was wrong since it should on the transport protocol if at all
Patch V4: Completely remove support for NetBSD <= 4.0 and remove
NETBSD_MULTI_AF defines
Patch V5: Assume generic OS in tun.c is also IPv6 capable. Add changes to
man page. Fix typos/change message as suggest by David.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: David Sommerseth <davids@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1476377656-3150-1-git-send-email-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12695.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
Before the connect-retry change to do exponential backup this was not
necessary since the time was fixed. With the exponential backoff the
UI needs either to implement its own exponential backoff mechanism
or needs a way of knowing the value of OpenVPN internal mechansim.
Patch V2: Fixed typos noticed by Selva
[DS: Fixed a couple of whitespace errors in management_hold() at commit time]
Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <1476269227-13290-1-git-send-email-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12675.html
Signed-off-by: David Sommerseth <davids@openvpn.net>
As reported in trac #732, the man page text for --cipher is no longer
accurate. Update the text to represent current knowledge, about NCP and
SWEET32.
This does not hint at changing the default cipher, because we did not make
a decision on that yet. If we do change the default cipher, we'll have to
update the text to reflect that.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1473605431-20842-1-git-send-email-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12439.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Debian also incorrectly changes that the default for route parameters can
be specified by using "nil" instead of "default. The confusion is probably
coming from show_opt printing "nil" instead of "default". Change show_opt
to show "default (not set)" instead of "nil"
Original author: Alberto Gonzalez Iniesta <agi@inittab.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1468495519-25102-1-git-send-email-arne@rfc2549.org>
URL: http://www.mail-archive.com/search?l=mid&q=1468495519-25102-1-git-send-email-arne@rfc2549.org
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Pushes AES-256-GCM when a connection client advertises IV_NCP=2, and
supports serving connections to clients with different data channel
cipher configuration simultaneously.
v2:
* Update manpage
* Add Changes.rst entry
v3:
* Do not regenerate keys if the client sends a second pull request
* Don't postpone key generation if client has no IV_NCP support
v4:
* rebase on client-side NCP v4
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1467149771-10374-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/12009
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add --ncp-disable to completely disable cipher negotiation, and
--ncp-ciphers to specify which ciphers to accept from the server.
v2:
* fix --disable-crypto builds
* use register_signal() instead of operating directly on c->sig
* add man-page entry for new options
v3:
* rebased on client-side NCP v3
v4:
* rebased on client-side NCP v4
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1467149700-10042-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/12008
Signed-off-by: Gert Doering <gert@greenie.muc.de>
- When the number of retries per remote exceeds a limit
(hard coded to 5), double the restart pause interval
for each additional retry per remote.
- Trigger a SIGHUP to reset the retry count when the pause
interval exceeds 1024 times the base value of restart pause.
(removed in v2 of the patch)
The base value of restart pause is set using --connect-retry
(5 seconds by default).
v2 changes (based on suggestions from Arne Schwabe <arne@rfc2549.org>)
- Do not throw SIGHUP.
- Add an optional argument to "--connect-retry n [m]" where 'm'
specifies the max value of restart pause interval (default
300 sec).
E.g., "--connect-retry 5 1800" will cause the restart pause to
scale up starting at 5 until it exceeds 1800 seconds at which
point it gets capped at 1800.
- If n == m no slow down will occur.
- While at it, fix typos and clarify the description of connect-retry-max
in the man page and Changes.rst
v3 changes (on further feedback from arne@rfc2549.org):
- Limiting the base value of retry wait interval to 16 bits moved
to options.c
- Apply backoff only in the udp and tcp-client modes. Backing off on
tcp-server could be exploited by a client in p2p-mode to maliciously
slow it down (thanks to Arne Schwabe for pointing this out.
- Fix typo in Changes.rst: "third argument" -> "second argument"
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1467732770-19110-1-git-send-email-selva.nair@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/12050
Signed-off-by: Gert Doering <gert@greenie.muc.de>
These options were probably introduced long before we had multiple
remote/connection entries. For all other connection entries, OpenVPN will
go on with the next connection if it fails. For proxies, if it fails in
some ways it works the same, for other failures it completely stops.
Removing the *-proxy-retry and defaulting to retry makes the behavior more
predictiable. Stopping after one try (regardless of reason) can be achieved
with --max-connect-retry 1
V2: Add reason for removing, remove from manpage, give a hint at
--max-connet-retry
V3: Collapse the two ifs in options.c to one block
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1466771230-5266-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11988
Signed-off-by: Gert Doering <gert@greenie.muc.de>
- Allow --management-external-cert as an alternative to --cert
- Also make sure --cert and --management-external-cert are not
both specified, and clarify in the man page that the latter
must be used with --management-external-key.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1466132093-1178-1-git-send-email-selva.nair@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11929
Signed-off-by: Gert Doering <gert@greenie.muc.de>
With this change all timeouts before the first packet from the OpenVPN
server are unified into the server-poll-timeout option.
The default of 120s has been chosen to be a safe value is larger as it is
larger the sums of the old small timeouts.
V3: fix some whitespace/typos problems
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1465656195-12722-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11899
Signed-off-by: Gert Doering <gert@greenie.muc.de>
v2 changes:
- Add the flag "ignore" and have "reject" trigger a restart.
- Unlimited number of filters: yes, going against the consensus,
but the code looks simpler and cleaner this way.
- New commit message to reflect the changes.
Usage: --pull-filter accept|ignore|reject "option"
Permit a client to selectively accept, ignore or reject options
pushed by the server. May be used multiple times. The filters
are applied in the order specified to each pushed option received.
The filtering stops as soon as a match is found. The action "ignore"
removes the option and continues processing the next option, while
"reject" flags an error and restarts the connection with SIGUSR1.
Prefix matching is used so that all options starting with the
specified "option" string are filtered.
Example:
pull-filter accept "route 192.168."
pull-filter ignore "route "
pull-filter accept "ifconfig 10.9.0."
pull-filter reject "ifconfig "
will ignore all pushed routes except those starting with "192.168."
and reject the assigned ip unless its in the "10.9.0.0/24"
range. A match of the reject filter will trigger a restart. SIGUSR1
restart is used instead of SIGHUP so as to try the next remote
for reconnection.
Note the space at the end of "route " to not reject "route-gateway",
for example. All options not matched by any filter are accepted.
Acknowledges shameless imitation of --push-remove.
Inspired by Trac #682.
Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1465162884-32520-1-git-send-email-selva.nair@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11808
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Correctly handle CIDR masks when pushing clients addressing from an IPv6
pool. This change ignores the incorrectly used `bits` argument to the
--ifconfig-ipv6-pool option.
The code to save any provided CIDR mask after the pool IP is left in;
this may someday become useful when we move to allow IPv6 pools without
relying on an IPv4 pool assignment.
Signed-off-by: Josh Cepek <josh.cepek@usa.net>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <53F1DA95.7020701@usa.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8990
Signed-off-by: Gert Doering <gert@greenie.muc.de>
With this option, the server can remove individual options from the
set pushed to a client (call from --client-config-dir file, or from
--client-connect script or plugin). Options are removed at parse
time, so it is possible to do stuff like:
push-remove route-ipv6
push "route-ipv6 fd00::/8"
to first remove all IPv6 route options set so far, then add something
specific (what "push-reset" does to all the options).
Arguments to push-remove are strncmp()'ed to option string, so partial
matches like
push-remove "route-ipv6 2001:"
are possible ("remove all IPv6 routes starting with 2001:").
Implementation of remove_iroutes_from_push_route_list() had to be changed
slightly to stop it from re-enabling all disabled options again.
v2: documentation (Changes.rst, doc/openvpn.8)
remove surplus gc_arena
implement filtering of "ifconfig-ipv6"
v3: correct quoting in commit message
only handle a single argument per push-remove statement - if multiple
options are to be removed, just use multiple push-remove statements
Trac #29, #614
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1463393584-8318-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11665
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch is a variant of the patch to implement x509-track for
PolarSSL that was sent to openvpn-devel@ by James Yonan
(<1456993146-63968-7-git-send-email-james@openvpn.net>). It still uses
some of the original code from James, but proposes a different
implementation.
This patch does the following things differently:
* Do not introduce NID_* defines that need to be maintained. Instead,
just use the short name of the attribute for identification. This
has the advantage that we automatically support everything that
PolarSSL supports, it is less code and we do not have maintain the
list. But the disadvantage is that this approach will not error out
when an unknown attribute name is supplied. PolarSSL (at least 1.3,
I didn't check 2.x) does not provide the functions required to do
that. Instead of erroring out, this implementation will just
silently ignore the unknown --x509-track attribute name.
* Remove the ENABLE_X509_TRACK define completely - it depended just on
ENABLE_CRYPTO anyway.
* Move the --x509-track option parsing out of ENABLE_MANAGEMENT, since
it does not depend on management functionality.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL1w8e_o-GjS2jETZWxYdMbS2iKABPc6OZBA8bOVycjtA@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11350
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In the past years, the internet has been moving forward wrt deprecating
older and less secure ciphers. Let's follow this example in OpenVPN and
further restrict the default list of negotiable TLS ciphers.
Compared to earlier, this disables the following:
* Ciphers in the LOW and MEDIUM security cipher list of OpenSSL
The LOW suite will be completely removed from OpenSSL in 1.1.0,
the MEDIUM suite contains ciphers like RC4 and SEED.
* Ciphers that do not provide forward secrecy (static DH/ECDH keys)
* DSA private keys (rarely used, and usually restricted to 1024 bits)
v2: added Changes.rst entry.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1460917927-31645-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11457
Signed-off-by: Gert Doering <gert@greenie.muc.de>
While crl files can change regulary and it is usually not a good idea to
statically include them into config files, handling multiple files and
updating files on mobile devices is tiresome/problematic. Inlining a static
version of the crl file is better in these use cases than to use no crl at
all.
OpenVPN 3 already supports inlining crl-verify, so <crl-verify> is already
used in config files.
V2: Fixed PolarSSL and made formatting respect the 80 column limit
V3: Accidentally reverted one change too much in V2
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1457293149-10526-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11337
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add Authenticated Encryption with Additional Data (AEAD) support for
ciphers, which removes the need for a separate HMAC step. The MAC is
integrated into the cipher and the MAC tag is prepended to the payload.
This patch is inspired by the patch originally submitted by Kenny Root
on the openvpn-devel mailinglist, but does a number things differently:
* Don't support XTS (makes no sense for VPN)
* Don't support CCM (needs extra code to make it actually work)
* Don't force the user to specify "auth none" (that would break
tls-auth)
* Add support for PolarSSL (and change internal API for this)
* Update openvpn frame size ('link mtu') calculation for AEAD modes
* Use the HMAC key as an implicit part of the IV to save 8 bytes per
data channel network packet.
* Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets.
By using the negotiated HMAC key as an implicit part of the IV for
AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each
packet sent. This is particularly interesting for connections which
transfer many small packets, such as remote desktop or voip connections.
The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher
operation, which requires the IV to be unique (but does not require
unpredictability).
IV uniqueness is guaranteed by using a combination of at least 64-bits
of the HMAC key (unique per TLS session), and a 32-bit packet counter.
The last 32-bit word of the 128-bit cipher block is not part of the IV,
but is used as a block counter.
AEAD cipher mode is not available for static key mode, since IV
uniqueness is harder the guarantee over sessions, and I believe
supporting AEAD in static key mode too is not worth the extra
complexity. Modern setups should simply use TLS mode.
OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those
versions have an unnecessary check that fails to update the cipher if
the tag was not already set. 1.0.1d, which fixes that, was released in
February 2013. People should have updated, and distros should have
backported the fix by now.
Changes in v2:
* Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work
in AEAD mode.
* Do not make AEAD support configurable in ./configure.
* Get rid of '12' magic constant in openvpn_encrypt_aead().
* Update manpage to explain that --auth is ignored for the data channel
when using an AEAD cipher.
* Move setting the IV in AEAD cipher modes to the IV generation code.
This is a more natural place and now we can pull iv[] into the IV
generation scope.
* Read packet ID directly from packet buffer instead of from iv buffer,
to remove the need for an extra buffer.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11162
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As reported in trac ticket #646, OpenSSL might also need /dev/urandom to
be available in the chroot. This depends on OS, OS version and ssl library
configuration. Update the manpage to better explain this.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1452196364-18786-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10954
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch uses generic "bob.example.com" and "alice.example.com"
hostnames to replace the current "may" and "june" examples. Generic
names chosen rather than other names like "server"/"client" or
"head-office"/"remote-office" etc which may create other unintended
or implicit meanings to the reader.
The example.com domain is set aside defined by IANA for use as
documentation examples. Refer to: http://www.iana.org/domains/reserved
Using this well-known domain makes comprehension of documentation easier.
This patch incorporates feedback from Gert Doering and Selva Nair.
Signed-off-by: Phillip Smith <fukawi2@gmail.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1450743146-9050-1-git-send-email-fukawi2@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10875
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This option blocks all out-of-tunnel communication on TCP/UDP port 53
(except for OpenVPN itself), preventing DNS Leaks on Windows 8.1 and 10.
This is the same patch as dd628d2e0d in release/2.3, except that it
is always compiled (on WIN32) here - we already require compilation for
Vista+ in master (-> 2.4).
Reviewed-by: Selva Nair <selva.nair@gmail.com>
Reviewed-by: Lev Stipakov <lstipakov@gmail.com>
Reviewed-by: James Yonan <james@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1449780715-4027-1-git-send-email-iam@valdikss.org.ru>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10744
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Currently the state command shows only the tun/tap IPv4 address. The
IPv4 address of the remote peer is also displayed. In case you connect
via IPv6 it just shows the first 4 bytes of the address in IPv4 notation.
This patch extends the state command, so it handles IPv6 addresses.
In addition it also displays the local address and the both port numbers
of the connection, e.g.
1447250958,CONNECTED,SUCCESS,10.0.0.2,fd00::1,1193,fd00::2,6492,fdff::1002
Signed-off-by: Heiko Hund <heiko.hund@sophos.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1448456220-2042-1-git-send-email-heiko.hund@sophos.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10603
Signed-off-by: Gert Doering <gert@greenie.muc.de>
When server exits / restarts (gets SIGUSR1, SIGTERM, SIGHUP, SIGINT) and
explicit-exit-notify is set, server sends RESTART control channel
command to all clients and reschedules received signal in 2 secs.
When client receives RESTART command, it either reconnects to the same
server or advances to the new one, depends on parameter comes with
RESTART command - behavior is controlled by explicit-exit-notify in the
server config.
v4:
- Rebase on top of master
- Remove #ifdef ENABLE_OCC around
connection_entry->explicit_exit_notification
since it is also used outside of OCC context
- Update usage message
v3:
- Use control channel "RESTART" command instead of new OCC code to
notify clients
- Configure on the server side (by value of explicit-exit-notify) if
client should reconnect to the same server or advance to the next one
- Fix compilation when OCC is disabled (--enable-small)
- Update man page
v2:
- Take into use explicit-exit-notify on the server side
- OCC_SHUTTING_DOWN renamed to OCC_SERVER_EXIT
- Code prettifying
Signed-off-by: Lev Stipakov <lstipakov@gmail.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1447752827-16720-1-git-send-email-lstipakov@gmail.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10515
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Make OpenVPN read the username from the auth file
parameter of --auth-user-pass and prompt for a
password if it's not in the file.
Rationale: Prior to this change OpenVPN either
required both username and password present in the
auth file or prompted for both on the console.
Unlike passwords usernames usually don't change and
can therefore be "hardcoded" in the config.
Signed-off-by: Michal Ludvig <mludvig@logix.net.nz>
Reviewed and updated to current master.
Signed-off-by: Adriaan de Jong <dejong@fox-it.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1444553060-15946-1-git-send-email-dejong@fox-it.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10255
Add extended client certificate verification support.
Replace --client-cert-not-required with a more flexible option,
that allows for no, optional or mandatory client certificate
verification.
Signed-off-by: Jan Just Keijser <janjust@nikhef.nl>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1444383559-15788-1-git-send-email-janjust@nikhef.nl>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10213
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Also remove SOCKET_SND_RCV_BUF_MAX since limiting the buffer to 1000k is
arbitrary and all OSes impose a maximum that can be set anyway.
closes trac ticket #461
V2: SOCKET_SND_RCV_BUF_MAX removal
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1444919918-4525-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10280
Signed-off-by: Gert Doering <gert@greenie.muc.de>
LZ4 is using less CPU at similar performance, and it is easier to
build and support for binary installs (as it does not require C++
and a C++ runtime). Since it was never supported in any formally
released OpenVPN version, just drop it again.
This leaves in the compression opcode for Snappy for documentation
purposes.
trac #617
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1444494889-28925-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10251
[DS: Fixed option prefix from '-' to '--']
Signed-off-by: Daniel Kubec <niel@rtfm.cz>
Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com
Acked-by: David Sommerseth <davids@redhat.com>
Keying Material Exporter [RFC-5705] allow additional keying material to be
derived from existing TLS channel. This exported keying material can then be
used for a variety of purposes.
[DS: Updated man page to document both upper and lower length boundaries]
Signed-off-by: Daniel Kubec <niel@rtfm.cz>
Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com
Acked-by: David Sommerseth <davids@redhat.com>
Add "ipv6" and "!ipv4" sub-options to "--redirect-gateway" option.
This is done in the same way as in the OpenVPN 3 code base, so
"--redirect-gateway ipv6" will redirect both IPv4 and IPv6 - if you
want v6-only, use "--redirect-gateway ipv6 !ipv4".
The actual implementation is much simpler than for IPv4 - we just
add a few extra routes to the route_ipv6_option_list and leave it to
init_route_ipv6_list() to figure out whether there is an overlap with
IPv6 transport, and if yes, insert a host route to the VPN server
via the current IPv6 default gateway.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1441985627-14822-8-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10086
- introduce get_default_gateway_ipv6() and add stub functions with the
implementation plan to the 4 major code blocks here (Windows,
Linux/Android, *BSD and Solaris, "others")
- add &rgi6 to print_default_gateway(), and teach it to print v4, v6
or both, depending on the calling environment
- unlike IPv4 (today), get_default_gateway_ipv6() is passed the actual
target IPv6 address of the server we're looking for, so we can handle
more complicated routing setups ("default to eth0, vpn server to ppp0")
correctly
- consequently, --show-gateway has an optional parameter now, the
IPv6 address to look up (for debugging)
- document --show-gateway and the extra option in openvpn.8
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1441985627-14822-5-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10087
Signed-off-by: Gert Doering <gert@greenie.muc.de>
point out that this is for "data channel" packets
trac #463
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1432674063-15916-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9746
The internal machinery wants TLS for this to work, so just add this
to the (long) list of options not allowed unless either --tls-client
or --tls-server is active. For added sanity, add an ASSERT() call
to the place where this combination caused a NULL ptr reference, and
document the restriction.
Fix trac #373
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1432472554-24666-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9736
Prevent confusion as described in trac #422 by better explaining the
behaviour of --capath, and providing pointers to relevant openssl man
pages.
Attached are patches for the master and release/2.3 branches. The only
difference is that in the master patch, a line referencing the
requirement for OpenSSL 0.9.7 is removed, since master already requires
OpenSSL >= 0.9.8.
-Steffan
Content-Type: text/x-patch;
name="2.3-Clarify-capath-option-in-manpage.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="2.3-Clarify-capath-option-in-manpage.patch"
>From 3626088e146dbf959d7ec73f4e7cc5ab24c1ad57 Mon Sep 17 00:00:00 2001
From: Steffan Karger <steffan@karger.me>
Date: Sun, 24 May 2015 11:18:34 +0200
Subject: [PATCH] Clarify --capath option in manpage
Prevent confusion as described in trac #422 by better explaining the
behaviour of --capath, and providing pointers to relevant openssl man
pages.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <55619DC4.2020108@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9732
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Commit 4880739c17 removed DNS randomization, and the dual-stack
patches for 2.4 completely changed the getaddrinfo() result handling again,
but neither fact ever made it into the man page.
Trac #411
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1432454172-1318-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9730
Fixes trac #225 ('--auth-user-pass FILE' and '--auth-nocache' problem).
This patch is based on the changes suggested by ye_olde_iron in the trac
ticket. Also added a note to the manpage to inform people to use
absolute paths when combining --auth-user-pass file and --auth-nocache.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1432386145-15045-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9717
Signed-off-by: Gert Doering <gert@greenie.muc.de>
here's my patch for bug #93: missing ifconfig_* env vars after
up-restart. Tested with both IPv4, IPv6, topology subnet and topology net30
Document differences between --up-restart and --up in openvpn.8
See trac #93 and the discussion starting with <555BF270.3090706@nikhef.nl>
on the openvpn-devel mailing list.
fix trac #93
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <555BF270.3090706@nikhef.nl>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9705
Signed-off-by: Gert Doering <gert@greenie.muc.de>
[SK: v2, patch taken from trac #127 and updated to current master branch]
Signed-off-by: Robert Fischer <ml-openvpn@trispace.org>
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1431976869-4948-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9701
Signed-off-by: Gert Doering <gert@greenie.muc.de>
On UTF-8 systems groff interprets unescaped dashes as hyphens and escaped
dashes
as minus signs. Unescaped dashes can cause problems when searching for or
copying and pasting options. This patch ensures that dashes in command-line
options are escaped and that everything else is left unescaped. This patch
is
for the Git "master" branch.
Trac: 512
Signed-off-by: Samuli Seppänen <samuli@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1431339554-20553-1-git-send-email-samuli@openvpn.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9674
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As reported in trac tickets #304, #358 and #359 (and possibly more), the
usage and interpretation of --tls-cipher (and --show-tls) is tricky. This
patch extends the man page to explain those a bit better and point out
that --tls-cipher is an expert feature (i.e. easy to get wrong). Also add
a notice to the --show-tls output, referring to the man page explanation.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1430840857-6123-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9651
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The fact that the second parameter of --ifconfig is no longer
a "remote address" but a "netmask" when using --dev tun and
--topology subnet was not documented clearly enough.
Trac #370
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1430216419-11943-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9616
This patch adds support for using certificates stored in the Mac OSX
Keychain to authenticate with the OpenVPN server. This works with
certificates stored on the computer as well as certificates on hardware
tokens that support Apple's tokend interface. The patch is based on
the Windows Crypto API certificate functionality that currently exists
in OpenVPN.
This patch version implements management client which handles RSA-SIGN
command for RSA offloading. Also it handles new 'NEED-CERTIFICATE'
request to pass a certificate from the keychain to OpenVPN.
OpenVPN itself gets new 'NEED-CERTIFICATE" command which is called when
--management-external-cert is used. It is implemented as a multiline
command very similar to an existing 'RSA-SIGN' command.
The patch is against commit 3341a98c28.
v4:
- added '--management-external-cert' argument
- keychain-mcd now parses NEED-CERTIFICATE argument if 'auto' is passed
as cmdline's identity template
- fixed typo in help output option name
- added '--management-external-cert' info in openvpn(8) manpage
- added 'certificate' command documentation into doc/management-notes.txt
v3:
- used new 'NEED-CERTIFICATE' command for certificate data request
instead of 'NEED-OK'
- improved option checking
- improved invalid certificate selection string handling
- added man page for keychain-mcd
- handle INFO, FATAL commands from openvpn and show them to user
* ACK from Arne Schwabe for OpenVPN part
* ACK from James based on Arne's testing
v2 (http://sourceforge.net/p/openvpn/mailman/message/33225603/):
- used management interface to communicate with OpenVPN process
v1 (http://sourceforge.net/p/openvpn/mailman/message/33125844/):
- used RSA_METHOD to extend openvpn itself
Signed-off-by: Vasily Kulikov <segoon@openwall.com>
--
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20150225160718.GA6306@cachalot>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9486
Signed-off-by: Gert Doering <gert@greenie.muc.de>
As requested on the mailing list and in trac ticket #410, add an option to
disable 'traditional' Diffie Hellman key exchange. People want to be able
to create ecdh-only configurations.
This patch also disables RSA key exchange by default for OpenSSL builds, to
prevent that people who set "--dh none" but have an OpenSSL version that
doesn't support ECDH end up with a less secure connection. Note that users
that specify their own --tls-cipher override these defaults and thus can
still use whatever OpenSSL supports (and might thus end up with less secure
connections).
PolarSSL does not allow to easily disable RSA key exchange during runtime,
but its default compile options do not include RSA key exchange based
cipher suites.
Finally update the manpage to reflect the new behaviour, and while touching
it change the text to motivate users towards a more secure configuration.
v2 - disable RSA key exchange by default
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1420141569-11773-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9376
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Remove the --disable-ssl configure option and accompanying ENABLE_SSL
defines in the master/2.4 branch, to reduce the code and testing
complexity a bit.
This does not remove to runtime option to run without SSL, just the compile
time option to not include any SSL-related code.
During the community meeting in November 2014 there were no objections
amongst he developers present. Also, this has been announced on the -users
and -devel mailing lists two weeks ago, without any response whatsoever.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <54A4248A.1090501@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9371
Signed-off-by: Gert Doering <gert@greenie.muc.de>
If the user specifies --pkcs11-id or --pkcs-id-management but neglects
to explicitly provide a --pkcs11-provider argument, and if the system
has p11-kit installed, then load the p11-kit proxy module so that the
system-configured tokens are available.
Trac: 490
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1418303015.31745.78.camel@infradead.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9342
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 6f1d3cf062)
This is not a full update, but just updates some data channel-related docs
I came across. Other pages probably need a bit of attention too.
Stuff that was changed:
* Explain data channel crypto format in crypto.h
* Add P_DATA_V1 and P_DATA_V2 packet format spec
* Remove '2.1' from title
* Update some OpenSSL-specific text
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1417978095-19427-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9318
Signed-off-by: Gert Doering <gert@greenie.muc.de>
In older version OpenVPN would hash a --tls-auth file
if it does not conform to the expected format
Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <1417871704-30273-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9306
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Because using TLS 1.2 breaks certain setups, a user might want to enforce
a maximum TLS version to use. This patch adds that option.
This patch removes a number of #ifdefs from ssl_polarssl.c, because the
polarssl versions we currently support (polar 1.2 for openvpn 2.3, and
polar 1.3 for openvpn-master) have all versions unconditionally enabled.
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <544EC052.3080809@fox-it.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/9210
Signed-off-by: Gert Doering <gert@greenie.muc.de>
The IPv4 routing code needs an IPv4 address to point a route to, and
in --topology subnet mode, the *server* did not have one set by default.
So we now just default --route-gateway to the next address right after
the server address - the specific address doesn't matter, as the correct
next-hop will not be resolved by the host OS but by the OpenVPN daemon.
All that is needed is "it's in the subnet routed to the tun interface".
Using the server address itself would work on unix, but doesn't work with
the Windows TAP driver (as it does not spoof ARP responses for itself).
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1405254527-23833-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8904
I revisited options.c to refine its brute-force upcasing behavior. Now, the
upcasing is done only if the option argument is all lowercase. Mixed-case
arguments and those with the "ext:" prefix are left unchanged. This
preserves the original intent of the "helpful" upcasing feature for
backwards compatibility while limiting its scope in a straightforward way.
Signed-off-by: Andris Kalnozols <andris@hpl.hp.com>
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <53B1BDD8.8020705@karger.me>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Point to correct kernel version for --multihome and IPv4-mapped
addresses (3.15, Tore Anderson).
Remove old reference to http://www.greenie.net/ from the IPv6 section,
as the code and documentation in here is more current than on that site.
Some more additions and clarifications.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Tore Anderson <tore@fud.no>
Message-Id: <1398511854-3609-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8642
This changes the representation of the tls_serial_{n} environment variable
from hex to decimal for PolarSSL builds, to match OpenSSL build behaviour.
Because hex representation for serials makes sense too, and to ease
transition for PolarSSL users, added tls_serial_hex_{n} that exports the
serial in hex represenation for both crypto library backends.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1398588561-18964-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8649
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Part of the information was confusing, part was outdated, and part was
just not making sense. Pointed out in trac#348.
Also add note about Linux IPv4-mapped issues as per trac#306.
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1398453555-19706-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8635
Commit 7d5e26cbb5 fixed extracting serial but did not change the format,
which always has been decimal. This patch fixes the manpage and
OSCP.sh script to conform with the implementation.
Acked-by: James Yonan <james@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1396001222-5033-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8409
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch is based on Jan Just Keijser's patch from Feb 7, 2012.
When OpenSSL 1.0.2+ or PolarSSL is used, lets the crypto library do the
heavy lifting. For OpenSSL builds, if a user specifies a curve using
--ecdh-curve, it first tries to override automatic selection using that
curve.
For older OpenSSL, tries the following things (in order of preference):
* When supplied, use the ecdh curve specified by the user.
* Try to extract the curve from the private key, use the same curve.
* Fall back on secp384r1 curve.
Note that although a curve lookup might succeed, OpenSSL 1.0.0 and older do
*not* support TLSv1.1 or TLSv1.2, which means no that no EC-crypto can be
used.
Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <53597BEA.6080408@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8625
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Documentation examples, description and code were disagreeing on what
this option actually does. Now they will all agree that it will
*prepend* a random-byte string to the hostname name before resolving
to work around DNS caching (needs a "*" wildcard record in the zone).
Fix trac #143
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1384698620-27946-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7999
With this patch OpenVPN will listen on Ipv4 as well as IPv6 when an IPv6
socket is used. Using bind ipv6only will disable this behavior
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1385382680-5912-7-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8052
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch contains a number of changes. I did not further spit this since some changes make only sense being changed together.
Always use connection_list, simplifies the reconnection logic.
Change meaning of --connect-retry-max and --connect-retry to be used
all connections. This now allows OpenVPN to quit after n unsuccessful
udp connection attempts
Remove the tcp reconnection logic. Failing a TCP connection will now
cause a USR1 like a UDP connection. Also extend sig->source from bool to
int to specify signal source. This allows a finer grained reconnection
logic if necessary in the future.
Dual-Stack support: if an address resolves to multiple records each
address is tried in sequential order. Then proceed to next connection
entry. Introduce the field current_remote to represent the current
connecting remote. Also change some fields to struct addrinfo* form
openvn_addr to store multiple addresses needed for the dual stack support.
Change meaning from udp and tcp to allow both IPv4 and IPv6. Introducue
new udp4 and tcp4 to force IPv4.
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1385382680-5912-6-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8058
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Message-ID: <20131129194258.GL161@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8071
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This delays error reporting from config parsing to resolving of host
addresses. But it allows statements like
remote openvpn.example.org openvpn
port https
management localhost ntp
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1385064495-25877-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8018
Signed-off-by: Gert Doering <gert@greenie.muc.de>
It looks like it's possible to specify an optional authfile as third
argument of the "socks-proxy" directive. This patch updates the man page to
document that.
Signed-off-by: Davide Brini <dave_br@gmx.com>
Acked-by: Heiko Hund <heiko.hund@sophos.com>
Message-Id: <0MTjMy-1VU1I42Lo0-00QV4k@mail.gmx.com>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7875
Signed-off-by: Gert Doering <gert@greenie.muc.de>
There are some patched OpenVPN versions out there without source code
(e.g. NDMVPN) that support adding custom http header.
This patch adds custom header to OpenVPN and supports the syntax that the
"in the wild" variants use.
Patch v3 also prints all custom headers with other http options in --verb 5
Patch v4 does clean up the add_proxy_header function
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1382688143-17247-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7946
Signed-off-by: Gert Doering <gert@greenie.muc.de>
directive that follows is recognized, it will be processed
as if the "setenv opt" prefix was absent. If present and if
the directive that follows is not recognized, the directive
will be ignored rather than cause a fatal error.
For example, suppose you are distributing a client
configuration file and want to set the minimum TLS version
that the client requires from the server to 1.2.
By using the following directive,
setenv opt tls-version-min 1.2 or-highest
only newer clients that understand the tls-version-min directive
would process it, while older clients would ignore it.
(cherry picked from commit 27713761e4110bb92f1c6dfe85db291e8c6e0f56)
Signed-off-by: James Yonan <james@openvpn.net>
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7771
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7744
URL: 27713761e4
Acked-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: David Sommerseth <davids@redhat.com>
Updated the TLS negotiation logic to adaptively try to connect using
the highest TLS version supported by both client and server.
Previously, OpenVPN (when linked with OpenSSL) would always connect
using TLS 1.0.
Also added tls-version-min directive to force a higher TLS version
than 1.0:
tls-version-min <version> ['or-highest'] -- sets the minimum
TLS version we will accept from the peer. Examples for version
include "1.0" (default), "1.1", or "1.2". If 'or-highest' is
specified and version is not recognized, we will only accept
the highest TLS version supported by the local SSL implementation.
Examples:
tls-version-min 1.1 -- fail the connection unless peer can
connect at TLS 1.1 or higher.
tls-version-min 1.2 or-highest -- require that the peer
connect at TLS 1.2 or higher, however if the local SSL
implementation doesn't support TLS 1.2 (as it wouldn't
if linked with an older version of OpenSSL), reduce the
minimum required version to the highest version supported
by the local SSL implementation (such as TLS 1.0). This
is intended to allow client configurations to target higher
TLS versions that are supported on the server, even if some
older clients don't support these versions yet.
[
This is a merged patch from on the following commits
on git://github.com/jamesyonan/openvpn.git
03a5599202bdc3ba07983dc4efdae387fb8fb436
d23005413b0e0f28a3c48a6342f494763d5c9b40
]
Signed-off-by: James Yonan <james@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7743
URL: http://thread.gmane.org/gmane.network.openvpn.devel/7744
Message-Id: 51C77F12.1090802@openvpn.net
Signed-off-by: David Sommerseth <davids@redhat.com>
Mac OS X 10.7+ natively supports tun devices (called utun). The "standard"
utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko
do not work together).
When OpenVPN is compiled with utun support it will if no dev-node is given
first try to use utun and if that is not available will try the
traditional tun devices
v2: Fixed tap support, get device name via ioctl, add manage
v3.1: Fix compiling without if/utun.h, fix manage errors
v4/v5: Don't try open to dynamically open utun0 -255 when early utun
initialization fails, fix fallback to tun, give fatal error message when
utun fails but no tun fallback should be done
v6: add commit message change log, replace strstr with strncmp, move
v7: Throw error if a user does the strange combination of --dev tun
--dev-type tap and --dev-node utun
A lot good input on earlier patches by Jonathan K. Bullard
<jkbullard@gmail.com>
Parts of the patches are inspired from Peter Sagerson's
<psagers@ignorare.net> utun patch
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Tested-by: Jonathan K. Bullard <jkbullard@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1371811708-8528-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7739
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Added support for the Snappy compression algorithm which has shown to
have considerably better compression speed than LZO at a comparable
compression ratio.
To enable Snappy add:
compress snappy
to both client and server config files.
Alternatively, enable compression framing on the client:
compress
and have the server selectively push "compress snappy" to the client.
This change also extends the client capability handshake to include
IV_SNAPPY so the server can be aware that a connecting client supports
Snappy.
Note that the Snappy implementation also includes an improved framing
approach where the first byte of the compressed payload is replaced by
the compression control byte (the first payload byte is moved to the end
of the packet). This solves off-by-one alignment issues, which improves
performance on ARM.
By default, the configure script will try to build with Snappy support.
To disable, use the --disable-snappy option.
The --enable-lzo-stub configure directive is now --enable-comp-stub
(because it's not actually "lzo" but "compression-enabled packet framing")
Add compression overhead to extra buffer unconditionally, as long
as USE_COMP is defined.
OpenVPN SVN r8206 (2.1.21a) and r8212 (2.1.21b)
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1366393268-27392-3-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7531
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Also fix a minor mistake in the manpage.
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1367353997-6669-1-git-send-email-arne@rfc2549.org>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7571
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Add the option --verify-x509-name to provide the functionality
of the now deprecated --tls-remote.
The new option accepts RFC 2253 subject DNs only and compares
RDN or RDN prefix only if configured explicitly.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: 1362670601-18660-1-git-send-email-heiko.hund@sophos.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/7376
Signed-off-by: Gert Doering <gert@greenie.muc.de>
man page patch to include the options that were made connection-entry
specific in 2.3.0
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-ID: 510E4344.6010608@nikhef.nl
Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch removes the support for the system() call, and enforces the
usage of execve() on the *nix platform and CreateProcessW() on Windows.
This is to enhance the overall security when calling external scripts.
Using system() is prone to shell expansions, which may lead to security
breaches. Which is also why the execve() approach has been the default
since commit a828135275 which
re-introduced the system() in Nov. 2008.
After having asked on the mailing list and checked around on the IRC
channels, the genereal consensus is that very few uses system() these
days.
The only annoyance I've been made aware of is that this will now
require adding a full path to the script interpreter together with the
script, and not just put in the script name alone. But to just use the
script name in Windows, you had to configure --script-security with the
'system' flag earlier too. So my conclusion is that it's better to add
a full path to the script interpreter in Windows and raise the overal
security with OpenVPN, than to continue to have a possible potentially
risky OpenVPN configuration just to make life "easier" for Windows
script users.
Removal of the system() call, also solves a nasty bug related to the
usage of putenv() on the *nix platforms.
For more information please see:
http://thread.gmane.org/gmane.network.openvpn.devel/7090https://community.openvpn.net/openvpn/ticket/228
Trac-ticket: 228
Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1351539352-17371-1-git-send-email-dazo@users.sourceforge.net>
URL: http://article.gmane.org/gmane.network.openvpn.devel/7114
With this option, users can basically undo the changes of the UTF-8
support commit 5e86fd9377. It's here for
short term compatibility and should be removed again as soon as possible.
When OpenSSL is used, the subject strings will be in the proprietary
format again. Generally username, X.509 CN, and X.509 subject will again
be subject to '_' replacemant, unless the "no-remapping" flag is
also specified. That flag ensures compatibility with setups using the
--no-name-remapping option, that has been removed in 2.3.
[v2: More comments related to compat_flags() added by DS plus using
COMPAT_FLAG_QUERY expclit]
[v3: Improved the man page entry for --compat-names, after suggestions
from Bernhard R. Link]
Signed-off-by: Heiko Hund <heiko.hund@sophos.com>
Signed-off-by: David Sommerseth <davids@redhat.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: David Sommerseth <davids@redhat.com>
Message-Id: 1347377664-15462-1-git-send-email-dazo@users.sourceforge.net
URL: http://article.gmane.org/gmane.network.openvpn.devel/7053
This patch documents the usage of inline files in OpenVPN. Hackish ways of
inline files are deliberately left out. For tls-auth and
secret the key-direction option is right way of specifying the direction
and not by using two tls-auth/secret lines where the first sets the
direction and has a dummy file name and the second sets the inline file
data but does not reset the direction parameter.
Also pkcs12 [[INLINE]] base64encoded_data works but is a quirk of how the
config parser works
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: 1345756860-2044-1-git-send-email-arne@rfc2549.org
URL: http://article.gmane.org/gmane.network.openvpn.devel/7006
Signed-off-by: David Sommerseth <davids@redhat.com>
Make openvpn query for proxy information through the
management interface. This allows GUIs to provide (automatically
detected) proxy information on a per connection basis.
This new option supersedes the undocumented --http-proxy-fallback
option and puts the responsibilty for HTTP proxy fallback handling
to the GUI caring for such.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com>
Reviewed-by: James Yonan <james@openvpn.net>
Message-Id: 1342009010-9735-1-git-send-email-heiko.hund@sophos.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6841
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
During discussion on FOSDEM 2012 it was decided that proxy auto detection
is best done in the GUI as it's highly platform specific and shouldn't be
handled in openvpn itself for every supported platform in openvpn itself.
This removes --auto-proxy from openvpn.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com>
Acked-by: David Sommerseth <davids@redhat.com>
Message-Id: 1328446029-30523-1-git-send-email-heiko.hund@sophos.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/5333
Signed-off-by: David Sommerseth <davids@redhat.com>
This also changes the descriptions of several options to note that they accept
a "command"; change the description of --client-connect and --client-disconnect
indicate that the temporary file's path is passed as the last argument to the
command, not the first argument; and Adds a description of --route-pre-down to
the descriptions of the other --route options.
[DS: This patch is based on parts of the options.c.diff and the complete
openvpn.8.diff patch sent to the mailing list - where these docs changes
are merged together into this patch]
Signed-off-by: Jonathan K. Bullard <jkbullard@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: CAEsd45RkyJw6yUk1Jwkip70HkCjKYoU+V=do3N7SH7JOaHBZdw@mail.gmail.com
URL: http://article.gmane.org/gmane.network.openvpn.devel/6194
Signed-off-by: David Sommerseth <davids@redhat.com>
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
Acked-by: Adriaan de Jong <dejong@fox-it.com>
Acked-by: David Sommerseth <davids@redhat.com>
Signed-off-by: David Sommerseth <davids@redhat.com>
