Re: [Openvpn-devel] [PATCH] Add a check for -Wl, --wrap support in linker
Hi, On Wed, Jan 18, 2017 at 03:42:52PM -0500, selva.n...@gmail.com wrote: > From: Selva Nair > > - Also make tests that require --wrap option to be > conditional on this support > > Signed-off-by: Selva Nair I said so in the PR already, but for the sake of the list - I think this is a reasonable approach: disable the --wrap tests if we can't run them, but keep the rest of the cmocka stuff active (way better than my initial "if it's not GNU ld, just disable cmocka"). I'm ready and willing to ACK and merge this, but would like to hear some voices from folks that understand autoconf better - is there anything wrong with this approach? Any suggestions how to do it better? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [openvpn-devel] --auth RSA-SHA512 vs --auth SHA512
On 18/01/17 19:17, David Sommerseth wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 18/01/17 18:19, debbie10t wrote: >> Hi, >> >> I have following config: >> >> >> ** Server Win10 (as per default generally) v2.4.0 with --auth >> *RSA-SHA512* --ncp-disable >> >> Log file shows: >> >> Wed Jan 18 17:04:34 2017 us=914797 Outgoing Control Channel >> Authentication: Using 512 bit message hash '*SHA512*' for HMAC >> authentication Wed Jan 18 17:04:34 2017 us=914797 Incoming Control >> Channel Authentication: Using 512 bit message hash '*SHA512*' for >> HMAC authentication >> >> >> ** Client Linux (as per default generally) v2.4.0 with --auth >> *RSA-SHA512* >> >> Log file shows: >> >> Wed Jan 18 17:05:00 2017 us=778089 Outgoing Control Channel >> Authentication: Using 512 bit message hash '*SHA512*' for HMAC >> authentication Wed Jan 18 17:05:00 2017 us=778182 Incoming Control >> Channel Authentication: Using 512 bit message hash '*SHA512*' for >> HMAC authentication >> >> The connection works but .. >> >> Because there is another digest called SHA512 why does the log >> *not* reflect the config correctly ? eg: hash '*RSA-SHA512*' >> >> (This had me very confused for sometime today) > > I am on thin ice here, as I've not dug much into the naming schemes of > the various algorithms. > > But ... I am fairly confident the hashing reference in the log refers > purely to the hashing algorithm, which most commonly is MD* or SHA* > variants (there are a few exceptions). > > And as I understand the code, the RSA-* stuff is just ignored, as that > is not used by by HMAC functions in our code. So using --auth SHA512 > would provide the same result. > Hi David, thanks for your reply On your explanation I tested with mixing things up. Server --auth SHA512** --ncp-disable Client --auth RSA-SHA512** (** Also the other way around) and I was able to connect any way around !! and ping etc .. I was badly distracted earlier on so may have not done restarts properly or more likely use SHA256 not 512 on one or other ends .. FTR --ncp-disable helped me focus a *lot* , recommended step for diagnostic problems. This question was related to trying to test mattock's aslr/dep version (which I can now test more thoroughly) and also to this forum post: https://forums.openvpn.net/viewtopic.php?f=4&t=23241 As you can see, it looks like I may have been wrong on that too :( (We all make mistakes) If you would like to improve my answer please do. If not, I will update tomorrow. Also, I received this from pippin (Thank you pippin): Found it: http://security.stackexchange.com/questions/91908/using-rsa-sha-as-instead-hmac-in-openvpn Shared: it also has an detailed explanation. Highest Regards R -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Add a check for -Wl, --wrap support in linker
From: Selva Nair
- Also make tests that require --wrap option to be
conditional on this support
Signed-off-by: Selva Nair
---
configure.ac | 26 ++
tests/unit_tests/openvpn/Makefile.am | 6 +-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 43487b0..0b7fea9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -582,6 +582,31 @@ AC_COMPILE_IFELSE(
[AC_MSG_RESULT([no])]
)
+saved_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,--wrap=exit"
+AC_MSG_CHECKING([linker supports --wrap])
+AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM(
+ [[
+ void exit(int);
+ void __real_exit(int);
+ void __wrap_exit(int i) {
+ __real_exit(i);
+ }
+ ]],
+ [[
+ exit(0);
+ ]]
+ )],
+ [
+ AC_MSG_RESULT([yes])
+ have_ld_wrap_support=yes
+ AC_DEFINE([HAVE_LD_WRAP_SUPPORT], [1], [Define to 1 if linker
supports -Wl,--wrap option])
+ ],
+ [AC_MSG_RESULT([no])],
+)
+LDFLAGS="$saved_LDFLAGS"
+
dnl We emulate signals in Windows
AC_CHECK_DECLS(
[SIGHUP],
@@ -1244,6 +1269,7 @@ AM_CONDITIONAL([GIT_CHECKOUT], [test "${GIT_CHECKOUT}" =
"yes"])
AM_CONDITIONAL([ENABLE_PLUGIN_AUTH_PAM], [test "${enable_plugin_auth_pam}" =
"yes"])
AM_CONDITIONAL([ENABLE_PLUGIN_DOWN_ROOT], [test "${enable_plugin_down_root}" =
"yes"])
AM_CONDITIONAL([ENABLE_CRYPTO], [test "${enable_crypto}" = "yes"])
+AM_CONDITIONAL([HAVE_LD_WRAP_SUPPORT], [test "${have_ld_wrap_support}" =
"yes"])
plugindir="${with_plugindir}"
sampledir="\$(docdir)/sample"
diff --git a/tests/unit_tests/openvpn/Makefile.am
b/tests/unit_tests/openvpn/Makefile.am
index fafe6b2..b902b20 100644
--- a/tests/unit_tests/openvpn/Makefile.am
+++ b/tests/unit_tests/openvpn/Makefile.am
@@ -1,6 +1,10 @@
AUTOMAKE_OPTIONS = foreign
-check_PROGRAMS = argv_testdriver buffer_testdriver
+check_PROGRAMS=
+
+if HAVE_LD_WRAP_SUPPORT
+check_PROGRAMS += argv_testdriver buffer_testdriver
+endif
if ENABLE_CRYPTO
check_PROGRAMS += tls_crypt_testdriver
--
2.1.4
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] More broadly enforce Allman style and braces-around-conditionals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Your patch has been applied to the following branches commit 4cd4899e8e80efae03c584a760fd107251735723 (master) commit 9c2506d4395de67dbc520b6458f25e99b99376eb (release/2.4) Author: Steffan Karger Date: Sat Jan 14 15:10:20 2017 +0100 More broadly enforce Allman style and braces-around-conditionals Signed-off-by: Steffan Karger Acked-by: Gert Doering Message-Id: <1484403020-6857-1-git-send-email-stef...@karger.me> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13875.html Signed-off-by: David Sommerseth - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYf8qpAAoJEIbPlEyWcf3yitwQAMZbK+6pQ062y2lnIEusYAR/ PPi44E2fjG83abu+ImFZwNNOIjlSg/XgkxkrQzs0IRrxihuhLl3qOPgsqoyxQD+a ZiFYcWm4R384KxfImGcAgjfDRSb9AlAG/MwVCU9N84yKPJrNks0401Jhn3LFaSrb mjSrBL8IcRVzHGeJXz+ZQU+b8mhtsCaFqH1n2pM7qOyNUBl2vjhVSNJicNqqRJvR /XI2aIR03hm4CQS9MhZ7eUSOqT8LpyeWnmS7n7M/55NCUasMSee0w0pjt9TKV/Nc ymd0i5d21fXNEiGGBUE5Til5hftsO+bzvIOLGVzMamgIMTFqg26LVE7X+tSLBYTT S+tieo3LblV+WF2gwhqQ3/N4udJOfwtuQ10OVIA3ZnxKmZN5rNDq2EreTeWX6ErZ HJnstpdSP2Px0AsOSjxnu+U4iwvVfnKB1qgwVhVdWXfg95dI/YD5aPt9uGOrpS3F W9UYq266zwAeskXxTFpwx47Zkuvf8Ybt12sdXwDULyukPf7yjGpisdjuCHZ3nlQW HdsuLyvvMrYXt3vRS8zIcu5drPp3oMhD1TCbpYW7kAHNvZagTQpjoaq/n+xETKds JqosWl9+n4sV1cdWruA01MpuouhBVO0YAU2aQcw6mDpIxmPgGKTsbvG4613nsjDo GpRfGRzPFbC7nkPs8NAY =evC1 -END PGP SIGNATURE- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] man: fix formatting for alternative option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for the late response. This was applied almost a week ago but seems to have missed the "Applied" sending. Anyhow, ACK! Your patch has been applied to the following branches commit d0d8a4b5f875bc802117647b20a3caa6d4fdb375 (master) commit 6204fccb2441b5bae8b3f6e0b31a4a0b232fc8e6 (release/2.4) Author: Christian Hesse Date: Wed Dec 28 08:54:20 2016 +0100 man: fix formatting for alternative option Signed-off-by: Christian Hesse Acked-by: David Sommerseth Message-Id: <20161228075420.348-1-l...@eworm.de> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13747.html Signed-off-by: David Sommerseth - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYf8XVAAoJEIbPlEyWcf3y73QQAJahatvtdZ6Iugzq8TghSkeG YmYG4ds6lq11oO4zmcj8rU/RBODFyCrB2FMDSWqoymYFI7WVzCB0yYDGEgGpHZhZ eRG4kx2f8sW0edOLMoySTp2Uz8uSytZZODb8WtPDPNYbpRTmmNLQkSQYq3oIuQ5Y 8SmtAnWDuEXHteO24H6aIEY+bH7tFEvUCiD5SjUhQfmu54kDa+NLzCxw6tW4NB5v tavrGGmOXzFLBmCtXgRMDY7DfWrmJ5pCHAQsbATfFhmmz53WwqiV0vboneQLIYm0 UP6hajnJyI7SULgHeqaE3bmxIIctqbfYpiInUCpWw4cs/imP12w0HCqKkmoi6Ni2 0YNnidebIT0+C2i9O4ZkPXqR3TntfgzpYLJs2WoVTV+WzEnUdbKKIsLsUE76UOHW A/uB5zK64KSzCKok9zV/QMsqXrdnCilyA6mMeS/UCTopfO1kc2IXRG79EnjBIjDi kxHgy8ERdVuleimAsbhtFY4c3bK3N1yuatwCasBK2S9CHl3EDpv8NaepyenLG32N FO8Rw4LC6BuSeYWraW5ePKBnlUpe/j0UgU8Yr2x5QBxY3R7W5lhC6D+ELRByxeIZ MEURyMFFzcFQLifrkzbdvb3eNlLTaLXGZ7wZvuDIfj3tZzS/W+7R0Xzfa7gsQxJ4 b4oSmzbBzQY6dvWbN0oY =S1dj -END PGP SIGNATURE- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [openvpn-devel] --auth RSA-SHA512 vs --auth SHA512
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/01/17 18:19, debbie10t wrote: > Hi, > > I have following config: > > > ** Server Win10 (as per default generally) v2.4.0 with --auth > *RSA-SHA512* --ncp-disable > > Log file shows: > > Wed Jan 18 17:04:34 2017 us=914797 Outgoing Control Channel > Authentication: Using 512 bit message hash '*SHA512*' for HMAC > authentication Wed Jan 18 17:04:34 2017 us=914797 Incoming Control > Channel Authentication: Using 512 bit message hash '*SHA512*' for > HMAC authentication > > > ** Client Linux (as per default generally) v2.4.0 with --auth > *RSA-SHA512* > > Log file shows: > > Wed Jan 18 17:05:00 2017 us=778089 Outgoing Control Channel > Authentication: Using 512 bit message hash '*SHA512*' for HMAC > authentication Wed Jan 18 17:05:00 2017 us=778182 Incoming Control > Channel Authentication: Using 512 bit message hash '*SHA512*' for > HMAC authentication > > The connection works but .. > > Because there is another digest called SHA512 why does the log > *not* reflect the config correctly ? eg: hash '*RSA-SHA512*' > > (This had me very confused for sometime today) I am on thin ice here, as I've not dug much into the naming schemes of the various algorithms. But ... I am fairly confident the hashing reference in the log refers purely to the hashing algorithm, which most commonly is MD* or SHA* variants (there are a few exceptions). And as I understand the code, the RSA-* stuff is just ignored, as that is not used by by HMAC functions in our code. So using --auth SHA512 would provide the same result. - -- kind regards, David Sommerseth OpenVPN Technologies, Inc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYf79HAAoJEIbPlEyWcf3yGm4P/RxyydWvK/kWuMFxOS7aGjx8 HhTB1eDep41eQTNyN6PJFExq3Be4B4Meo30tPqEbDuUGhZuvPYQb/04UET8vYgku 1XxqXA8OoTlk6cKU+hrj/ISClAAR3yd1ma2cfAMj5+ltS4mGzz8pPyKXxvIM7d++ gYiQyNb7Nu/oYN+TWDM0JZdIHWC9pUByugUoHmqhnBI79pQGjMfbtvdGFDFV70n4 jtXXJ6WIGunrW65zLRKGxuVd4K7cc9Aic259CcsVvIiarryEEtQt1ZbJBOm2O05v J5C+vynO1Ixcvq6wbVdmsnBrsjtK9BylVHB7oll3GX4axOn1S9AjC6DWDztsGbhL zzzKioIhv2dmB2OgufUXr6jMxWgWkvtcw4FspyzrUh1LbqaSd2iUiSnieB5fd7C4 z78zKznNGBQaqvRtH38aMRBH6vNrYZVM2bE05C7G5Vn0/xsPzrNt52FMMuKfgDMf eftK1JwbMjicLmbONmVDb2mEZewW/l0d8YkaFc74k1OXU5Kr+YP+jRSyHmHfLh6m eT+qgX/aUuUhWD98v1AiG1C6SqK9f1AaZuFh6BzpMVHmXUXaGAnrO5fgj1aJmnnI WLbqwSYY4ejAkubr0f2+dmcic2JTIhAwKF8wObGSrfE9kLgO5GM4TRMiUHwJplDD cdepFIgOVDQQhxA17EqD =bXK1 -END PGP SIGNATURE- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Servus, On Wed, Jan 18, 2017 at 04:43:22PM +0100, Thomas Schäfer wrote: > Client: > client > dev tun > proto udp6 > remote raspberrypi..myfritz.net 1194 udp6 [..] > redirect-gateway > verb 3 > > This works perfectly as long the client has still an IPv4-connection. > > But in case of an IPv6-only-client (not system-wide disabled, just not > getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't > set the IPv4-default route, since it can not find the old one. I can see the problem. The most elegant solution might be to use "redirect-gateway def1". The "def1" flag instructs the code to not add a 0.0.0.0/0 route (replacing and later restoring the existing default route) but to add 0.0.0.0/1 and 128.0.0.0/1 routes - which cover "the default" as well, but do not need to interfere with the existing /0 route. It might *still* fail, as the code might still want to check and install a v4 /32 host route for the VPN gateway, pointing to the existing default gateway. Which is arguably something that should not be done if we're not talking v4 in the first place, but I'm not sure that part of the code was ever adapted (I'd love to see a log with "def1" :-) ) - the v6 part is smart enough to only try looking at v6 routing tables if we're connecting over v6. In case "def1" is not enough, please try "redirect-gateway def1 local", which is a hack (but a documented one). "local" signals "do not install a host route pointing to the default gateway, because the VPN server is in the same locally connected network" (think "university wifi"). So that should make things succeed. If that is still not working, use brute force, and replace "redirect-gateway" with route 0.0.0.0/1 route 128.0.0.0/1 in the client config - that is the same thing as "def1 local" should give you, but explicitely only the "two half-default routes". (Whatever the outcome of your tests, I think our code should be smarter - the v4 code is 10+ years old, and has grown over time, and parts of it have been contributed by non-networking folks...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [openvpn-devel] --auth RSA-SHA512 vs --auth SHA512
Hi, I have following config: ** Server Win10 (as per default generally) v2.4.0 with --auth *RSA-SHA512* --ncp-disable Log file shows: Wed Jan 18 17:04:34 2017 us=914797 Outgoing Control Channel Authentication: Using 512 bit message hash '*SHA512*' for HMAC authentication Wed Jan 18 17:04:34 2017 us=914797 Incoming Control Channel Authentication: Using 512 bit message hash '*SHA512*' for HMAC authentication ** Client Linux (as per default generally) v2.4.0 with --auth *RSA-SHA512* Log file shows: Wed Jan 18 17:05:00 2017 us=778089 Outgoing Control Channel Authentication: Using 512 bit message hash '*SHA512*' for HMAC authentication Wed Jan 18 17:05:00 2017 us=778182 Incoming Control Channel Authentication: Using 512 bit message hash '*SHA512*' for HMAC authentication The connection works but .. Because there is another digest called SHA512 why does the log *not* reflect the config correctly ? eg: hash '*RSA-SHA512*' (This had me very confused for sometime today) Thanks. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Hi, In case of being totally wrong here, please redirect me to the right place (bug-systems, forum,...). Some words about the configuration: Server: shares a private IPv4-Network and ula-IPv6-Network IPv4-Adresses also NATed to the public. proto udp6 dev tun ca ca.crt cert server.crt key server.key dh dh2048.pem server 192.168.178.128 255.255.255.128 server-ipv6 fd00::1:1/112 push "route 192.168.178.0 255.255.255.0" push "route-ipv6 fd00::/64" keepalive 10 120 verb 3 Client: client dev tun proto udp6 remote raspberrypi..myfritz.net 1194 udp6 ca ca.crt cert client.crt key client.key remote-cert-tls server redirect-gateway verb 3 This works perfectly as long the client has still an IPv4-connection. But in case of an IPv6-only-client (not system-wide disabled, just not getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't set the IPv4-default route, since it can not find the old one. Regards, Thomas openvpn --config client.ovpn Wed Jan 18 16:11:34 2017 OpenVPN 2.4.0 x86_64-suse-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 27 2016 Wed Jan 18 16:11:34 2017 library versions: OpenSSL 1.0.2j-fips 26 Sep 2016, LZO 2.08 Wed Jan 18 16:11:34 2017 TCP/UDP: Preserving recently used remote address: [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:34 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Jan 18 16:11:34 2017 setsockopt(IPV6_V6ONLY=0) Wed Jan 18 16:11:34 2017 UDPv6 link local (bound): [AF_INET6][undef]:1194 Wed Jan 18 16:11:34 2017 UDPv6 link remote: [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:34 2017 TLS: Initial packet from [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194, sid=f70817fa 1f034096 Wed Jan 18 16:11:34 2017 VERIFY OK: depth=1, C=KG, ST=NA, L=BISHKEK, O=OpenVPN-TEST, emailAddress=me@myhost.mydomain Wed Jan 18 16:11:34 2017 Validating certificate key usage Wed Jan 18 16:11:34 2017 ++ Certificate has key usage 00a0, expects 00a0 Wed Jan 18 16:11:34 2017 VERIFY KU OK Wed Jan 18 16:11:34 2017 Validating certificate extended key usage Wed Jan 18 16:11:34 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Jan 18 16:11:34 2017 VERIFY EKU OK Wed Jan 18 16:11:34 2017 VERIFY OK: depth=0, C=KG, ST=NA, O=OpenVPN-TEST, CN=Test-Server, emailAddress=me@myhost.mydomain Wed Jan 18 16:11:34 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Wed Jan 18 16:11:34 2017 [Test-Server] Peer Connection Initiated with [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:36 2017 SENT CONTROL [Test-Server]: 'PUSH_REQUEST' (status=1) Wed Jan 18 16:11:36 2017 PUSH: Received control message: 'PUSH_REPLY,route 192.168.178.0 255.255.255.0,route-ipv6 fd00::/64,tun-ipv6,route 192.168.178.129,topology net30,ping 10,ping-restart 120,ifconfig-ipv6 fd00::1:1001/112 fd00::1:2,ifconfig 192.168.178.134 192.168.178.133,peer-id 0,cipher AES-256-GCM' Wed Jan 18 16:11:36 2017 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore. Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: timers and/or timeouts modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: --ifconfig/up options modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: route options modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: peer-id set Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: adjusting link_mtu to 1624 Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: data channel crypto options modified Wed Jan 18 16:11:36 2017 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Jan 18 16:11:36 2017 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Jan 18 16:11:36 2017 ROUTE: default_gateway=UNDEF Wed Jan 18 16:11:36 2017 GDG6: remote_host_ipv6=2003:63:2417:f900:ba27:ebff:feb6:f293 Wed Jan 18 16:11:36 2017 ROUTE6_GATEWAY fe80::da67:d9ff:fe6e:a242 IFACE=wlan0 Wed Jan 18 16:11:36 2017 TUN/TAP device tun0 opened Wed Jan 18 16:11:36 2017 TUN/TAP TX queue length set to 100 Wed Jan 18 16:11:36 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1 Wed Jan 18 16:11:36 2017 /bin/ip link set dev tun0 up mtu 1500 Wed Jan 18 16:11:36 2017 /bin/ip addr add dev tun0 local 192.168.178.134 peer 192.168.178.133 Wed Jan 18 16:11:36 2017 /bin/ip -6 addr add fd00::1:1001/112 dev tun0 Wed Jan 18 16:11:36 2017 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system Wed Jan 18 16:11:36 2017 /bin/ip route add 192.168.178.0/24 via 192.168.178.133 Wed Jan 18 16:11:36 2017 /bin/ip route add 192.168.178.129/32 via 192.168.178.133 Wed Jan 18 16:11:36 2017 add_route_ipv6(fd00::/64 -> fd00::1:2 metric -1) dev tun0 Wed Jan 18 16:11:36 2017 /bin/ip -6 route add fd00::/64 dev tun0 Wed Jan 18 16:11:36 2017 Initialization Sequence Completed -- Check out the vibrant tech community
