Posted: Fri Jul 22, 2016 21:10 Post subject: tun-ipv6 item in the VPN tunnel settings is the BAD thing!
Despite the ipv6 are disabled, the tun-ipv6 item appears at bottom of the "Status-->OpenVPN" tab of the router!
What is the meaning of such item (tun-ipv6) into the list of the used settings of the OpenVPN Client - especially when the ipv6 is disabled in the router??!?
I see this item in the router that is connected to the PIA VPN-provider with the AES256 and SHA256 used (at port 1197).
Whether this item about ipv6 (that are dangerous for the VPN tunnel) appears when another VPN-provider are used too?
Whether this item appears with the PIA when a NOT AES256 & SHA256 are used?
Quote:
This is the part of the text that is at the bottom of the "Status-->OpenVPN" tab:
It's just the information that the ipv6-ability of the tun interface is enabled in the openVPN config.
That has nothing to do with any encryption configuration.
If you diabled ipv6 in the DD-WRT Basic config ipv6 won't be treated by the Linux kernel (no routing, no service based on ipv6).
Therefore no security concerns are appropriate. _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
Posted: Sat Jul 23, 2016 21:38 Post subject: Back door? If yes then it had to be closed yesterday mornin
Mike42Smith wrote:
... the ipv6-ability of the tun interface is enabled in the openVPN config.
... ipv6 will not be treated by the Linux kernel (no routing, no service based on ipv6).
Thank you for your willing to help me to relax!
But I see two parts of your information as very stressful: ipv6 ability enabled and will not be used... So, why the ability of the TUNNEL (!) does NOT disabled?
Is there the ability to use the firewall to emulate the disabling of the TUNNEL's ability to transmit the ipv6? I'm prefer the BUNGED tunnel - but if it can not (???) be closed then I want be able to close the TUNNEL and not be rely to the second element that it will not send sometime somewhat through the OPENED TUNNEL by ipV6 (as the bug result, for example).
I'm prefer the TUNNEL (the PIPE) to be closed. I'm prefer the traffic jam in this TUNNEL!
Is there a way to disable the ipv6 ability of the TUNNEL??? Is there an ability to close the back-door???
VPN TUNNEL that are enabled for transmitting the ipv6??? Nonsense .
... ipv6 ability enabled and will not be used... So, why the ability of the TUNNEL (!) does NOT disabled?
But expressed as metaphor:
Even if the internet connection can transmit specific German letters like "ß" to you, you won't be able to handle this sign if you havn't learned the German language before (activate the German module in your brain).
So, as long as the IPv6 support is not enabled in the Setup section of your DD-WRT the tun interface of your openVPN connection won't get any IPv6 address or any ability to transmit IPv6 packages along this connection.
For your understanding and the point:
Quote:
Is there the ability to use the firewall to emulate the disabling of the TUNNEL's ability to transmit the ipv6?
As long as IPv6 is not generally enabled on your DD-WRT the linux kernel can not handle ipv6-iptables (firewall) at all (no kernel module for ipv6 is loaded).
As I explained there isn't any back door by the "tun-ipv6" entry in the openvpn config.
However, if you have any reasons to be paranoid you can modify the openvpn config manually after starting your DD-WRT wiht a start-up script (--> Administration --> Commands):
stopservice openvpn
sed -i -e /tun-ipv6/d /tmp/openvpncl/openvpn.conf
sleep 2
openvpn --config /tmp/openvpncl/openvpn.conf --route-up /tmp/openvpncl/route-up.sh --down-pre /tmp/openvpncl/route-down.sh --daemon _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
Posted: Sun Jul 24, 2016 14:51 Post subject: Thank you for willing to help with fix the vpn-Tunnel!!!
Vielen Dank for your help, Liebling Mike-42-Smit!
I hope that your script - same as the FW of the DD-WRT too - does not contain a bug and therefore it will help me be shure that any future bug in the DD-WRT FW will not cause me to be paranoid. In second, I hope this BACK-DOOR will be closed not by your manually enforced script, but by the trivial repairing of the built-in script of the DD-WRT FW.
I hope you will help us to reach this goal, and the IPV6 will be disabled in the VPN Tunnels in the next build of the DD-WRT FW, PLEASE!!!
Mike42Smith wrote:
However, if you have any reasons to be paranoid you can modify the openvpn config manually after starting your DD-WRT wiht a start-up script (--> Administration --> Commands):
Postskriptum.
As for now your script does not cause the changes that I can see in the log. With your script I got in the first lines of the log the following:
Quote:
19700101 02:00:09 I OpenVPN 2.3.11 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 24 2016
and at the bottom of the log i see the following:
Quote:
... mtu-disc yes fast-io tun-ipv6 tls-cipher ...
And I must to say this again: I prefer the BUNGED vpn-TUNNEL because Sometimes some bugs are somewhere.
Well, I am quite patient but this will be my last post regarding this topic.
In terms of your:
Quote:
I hope this BACK-DOOR will be closed not by your manually enforced script, but by the trivial repairing of the built-in script of the DD-WRT FW. ... the IPV6 will be disabled in the VPN Tunnels in the next build of the DD-WRT FW
I guess the developers of DD-WRT won't also see any bug or back-door in this part of configuration and won't change the concerning parameter just because of your fear, sorry.
Maybe you have to use another alternative firmware (e.g. openwrt) or build your own version of DD-WRT/openwrt.
Regarding your first log:
Quote:
OpenVPN 2.3.11 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 24 2016
This [IPv6] means that the application "OpenVPN" is build with the IPv6 option. That does not mean that IPv6 is activated generally! The application has just the proper modules for IPv6 included. Please understand that a lot of users want this option because it is the next gerneration of the IP-protocol.
... and regarding your second log:
Quote:
and at the bottom of the log i see the following: ... mtu-disc yes fast-io tun-ipv6 tls-cipher ...
If you follow the time stamp you will figure out that the OpenVPN client is automatically started after reboot / startup your system. At this initial start the tun-ipv6 option is included as start parameter.
With my lines in the startup-script you stop the openvpn client, delete the tun-ipv6 parameter from the openvpn config file and start the client again manually. After this restart you will see in the latest logs that the OpenVPN client is started without the option "tun-ipv6".
Sorry, but I have explained all I can. Now I am out of this discussion! _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
Posted: Tue Jul 26, 2016 5:06 Post subject: Excuse me, the tun-ipv6 appears WITH YOUR SCRIPT :(
Excuse me, BUT the tun-ipv6 appears WITH YOUR SCRIPT TOO
As I posted earlier:
Quote:
With your script at the bottom of the log I see the following:
Quote:
... mtu-disc yes fast-io tun-ipv6 tls-cipher ...
Any restart does not appear in my log, even your script was in the start-up section of the script of my router -- and TUN-ipV6 apeear in my log when your script was used .
Mike42Smith wrote:
With my lines in the startup-script you stop the openvpn client, delete the tun-ipv6 parameter from the openvpn config file and start the client again manually. After this restart you will see in the latest logs that the OpenVPN client is started without the option "tun-ipv6".
In addition: I do not see any reason to use VPN tunnel with ability to transmit the ipV6 packets. Excuse me for my fear -- but VPN tunnel with ipV6 ability is the nonsense. Is foolish. Is oxymoron in politically correct words...
I do not recognize any reason to keep the problem in the code even there are ability to fix this problem with patch (your script, for example, I hope, it does not helpful only into my router). I do not recognize any reason to keep the bug in the realization even the programmers do not want to make bad product! Why the product can not be absolutely safe, without exercises about foolish fear of the open door? Why we need to keep the problem into the code???
Attacker do not must use the brute force if there are the features/peculiarities of a realization that he can use for the attack - even when we do not able to recognize into the realization such ability(s) which are helpful for the attacker.
Posted: Fri Aug 05, 2016 18:33 Post subject: The "tun_ipv6 = DISABLED" -- OR the long dispute
Instead of the long clever dispute about the patches that can fix the OpenVPN Tunnel security leaking problem -- instead of all this dispute the simplest command can be used in the builtin settings of the DD-WRT firmware.
Why push me to the another FW ("for example, OpenWRT") and suggest a patches instead of ask the developers to put the "disabled" word into their code???
Why push me to the another FW ("for example, OpenWRT") and suggest a patches instead of ask the developers to put the "disabled" word into their code???
tun_ipv6 = DISABLED -- and all will be done...
Sorry mate but you mix up configuration and build (compiling a program). I just want to help you to unterstand. The developers compiled the OpenVPN package with the IPv6 option because a lot of people want this feature what has to enabled in the OpenVPN configuration file.
Quote:
With your script at the bottom of the log I see the following:
Quote:
... mtu-disc yes fast-io tun-ipv6 tls-cipher ...
As I explained above this shows all modules which are compiled within OpenVPN. But they are not all actived by default. If you don't want this module be compiled within the OpenVPN package you have to build your own DD-WRT firmware (or OpenWRT) because the developers can't build for everybody a specific firmware version.
Please test the openWRT precompiled firmware images any you will see there will be the same module compiled within the OpenVPN package, because IPv6 might be the future and a lot of users want to have to opportunity to activate this module in the config file. _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
Posted: Sun Aug 14, 2016 2:36 Post subject: Thank you for this explanation! And HELP us, PLEASE!!!
Mike42Smith wrote:
Sorry mate but you mix up configuration and build (compiling a program). I just want to help you to unterstand.
Quote:
With your script at the bottom of the log I see the following:
Quote:
... mtu-disc yes fast-io tun-ipv6 tls-cipher ...
As I explained above this shows all modules which are compiled within OpenVPN. But they are not all actived by default.
Thank you for your explanation!!!
Can you solve my addition problem, please? As you note in your answer, some (much) users of the DD-WRT are used its OpenVPN for their own VPN tunnel. Despite to this goal some users of the DD-WRT firmware are used the OpenVPN CLIENT only - and are used this CLIENT with "external" OpenVPN SERVER. In such cases there is the big and SERIOUS problem with the security of the VPN tunnel (and I do not tell about the ipV6, that was explained yet).
The problem in the design of the "Settings" abilities of the user of the DD-WRT in case the user use the OpenVPN tunnel to an EXTERNAL server of the VPN-provider and they (the abilities and the problems) are as following.
Now the abilities of the user to choose the layer of the security of the OpenVPN tunnel it want to build to the server of the VPN-provider are listed in the PRE-COMPILED LIST of the TLS layers and in two lists of the type of ciphering of the data and of the hash. So, only an options from the LISTS are able to the user of the DD-WRT.
Unfortunately, today the VPN-providers have the servers that fortunately have the security abilities that MUCH MORE hardest and good then the best option in the list of the TLS layer options of the last versions of the DD-WRT firmware , DESPITE OF THE ABILITIES OF THE TLS LIBRARIES THAT ARE COMPILED WITH THE BUILD OF THE DD-WRT !!! . The meaning of this is that the DD-WRT was be able to provide much more hard layer of the security - the ellipse ciphering that are brute-force sustained.
The problem is that in current design of the OpenVPN Client Settings the user can not able to CHOOSE the strategy that will ensure to him the BEST LAYER OF THE SECURITY THAT CAN BE REACHED WITH THE CURRENT ABILITIES OF THE BOTH TLS-LIBRARIES OF THE CLIENT AND OF THE SERVER!!!
Help, please, to add to the DD-WRT firmware the ability to ask from the VPN-Server the best layer of the security it can provide, and THE ABILITY of the negotiation process for the agreement about the best layer of the security for both Server and client of the VPN tunnel. I hope that ability is the built-in ability of the OpenVPN library and such negotiation process must not be programmed by the DD-WRT. This is the standard ability of the OpenVPN protocol - BUT DD-WRT CAN NOT TO GIVE TO THEIR USERS THE ABILITY TO CHOOSE THE OPTION "NOT NOTED" FOR THE REQUESTED BY THE CLIENT THE LAYER OF THE SECURITY .
For my opinion such option in the List of the TLS options can be named, for example, as "The best possible layer" and thus the Lists with the Ciphering options and with Hash options must be becomes dimmed (not available to use).
Help us, please! I hope YOU will able to understand my plea.
There is the option in the OpenVPN standard to realize this way (that are the only clever way, are you aggrieve with me?).
First who says the computer what is the best TLS cipher, who makes a ranking? I mean the science society or even the web community would be agree on one ranking.
Further I "googled" some for you and found out that
Quote:
Today, OpenVPN does not support TLS-ECDHE-* or more exotic cipher-suites as there is no elliptic curve support currently.
Sorry to disappoint you. But maybe you should speak first in the OpenVPN community about your issue.
By the way, if you know the list of supported ciphers on the provider side you can choose the best cipher by yourselfe depending what ciphers are supported by your OpenVPN version.
OpenVPN SSL Library information:
openvpn --show-ciphers : Show cipher algorithms to use with --cipher option.
openvpn --show-digests : Show message digest algorithms to use with --auth option.
openvpn --show-engines : Show hardware crypto accelerator engines (if available).
openvpn --show-tls : Show all TLS ciphers (TLS used only as a control channel). _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
By the way, if you know the list of supported ciphers on the provider side you can choosethe best cipher by yourself depending what ciphers are supported by your OpenVPN version.
OpenVPN SSL Library information:
openvpn --show-ciphers : Show cipher algorithms to use with --cipher option.
openvpn --show-digests : Show message digest algorithms to use with --auth option.
openvpn --show-engines : Show hardware crypto accelerator engines (if available).
openvpn --show-tls : Show all TLS ciphers (TLS used only as a control channel).
Thank you again for your wish to help!
Unfortunately the basic and the most important problem is that your suggestion does not related to my post: there are NOT any ability to choose the TLS suite as my wish - but only the list of options can be used. This is the root of the problem and I was told about this in my post.
In the second, the current version of DD-WRT is COMPILED (you was explain me the difference of compiling from setting) with the SSL Library that HAVE the ecliptic ciphering abilities. You too can see them by using the --show-tls command.
And again: the best way (for my opinion) is the "automatic" way that use the ranking that build for the server and exist in the SSL Library of the client (of the DD-WRT firmware of router). BUT - now the design of the firmware does NOT permit to the user NOR the automatic negotiation between the VPN-server of the VPN-provider and NOR the free choice of the user -- ONLY the choice from the LIST of the weak TLS ranges .
The more details I was note in my previous post.
PS. In the addition, can you help us with an addition bug of the DD-WRT firmware, please? As I signed in one of my posts, the routers with BOTH 2.4 and 5 GHz radios are NOT able to use the GREAT an NICE feature that was work fine in the "small" routers with only ONE radio: the ability to alternate the status of the radio (on - off) by pressing on the button of auto-configuration of the radio-connectivity (excuse me for my NOT-layer of the knowledge, please! I do not know the name of the procedure). Now, with TWO radios this nice feature does not work! .
Unfortunately the basic and the most important problem is that your suggestion does not related to my post: there are NOT any ability to choose the TLS suite as my wish - but only the list of options can be used. This is the root of the problem and I was told about this in my post.
You can also choose the TLS-cipher by the an additional entry into the "Additional Config" and set TLS Cipher field to "None".
Example for "Additional Config":
Code:
remote-cert-tls server
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
Yes the --show-tls command seems to be confusing:
Quote:
In the second, the current version of DD-WRT is COMPILED (you was explain me the difference of compiling from setting) with the SSL Library that HAVE the ecliptic ciphering abilities. You too can see them by using the --show-tls command.
AFAIK that's a list of available ciphers, not usable or default.
For example, there's even SRP ciphers which can't be used in OpenVPN.
As I have written before, may you should as for more details in the OpenVPN forum!
Please mate read more about OpenVPN first. You can add different tls-ciphers sperated by : (TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-256-CBC-SHA256) in your openvpn config. But the ranking has to do by yourself. Alternatively the server has an own ranking demands a specific tls-cipher.
Your are wrong with your thoughts:
Quote:
now the design of the firmware does NOT permit to the user NOR the automatic negotiation between the VPN-server of the VPN-provider and NOR the free choice of the user -- ONLY the choice from the LIST of the weak TLS ranges
p.s. Sorry, but I don't know anythink about your addressed feature:
Quote:
... the ability to alternate the status of the radio (on - off) by pressing on the button of auto-configuration of the radio-connectivity ...
_________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
You are a very tough mate!
Yes the --show-tls command seems to be confusing:
Quote:
In the second, the current version of DD-WRT is COMPILED (you was explain me the difference of compiling from setting) with the SSL Library that HAVE the ecliptic ciphering abilities. You too can see them by using the --show-tls command.
AFAIK that's a list of available ciphers, not usable or default.
For example, there's even SRP ciphers which can't be used in OpenVPN.
I was reading this old CLOSED ticket and I understand that it WAS related to the wish of the clear list; to the wish to wipe the oldest antic ciphers from the list. In addition, in the next lines of the ticket you can see that the automatic negotiation are possible and is legal (of course) in OpenVPN. In addition you say by yourself in the next your lines that the server have (alternatively to the user (client) set of ranks) "has an own ranking".
- and this is EXACTLY my wish: I want the server be managing the negotiation by it own rank! Are you know the way to set this strategy in DD-WRT???
Quote:
As I have written before, may you should as for more details in the OpenVPN forum!
Please mate read more about OpenVPN first. You can add different tls-ciphers sperated by : (TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-256-CBC-SHA256) in your openvpn config. But the ranking has to do by yourself. Alternatively the server has an own ranking demands a specific tls-cipher. Your are wrong with your thoughts:
Quote:
now the design of the firmware does NOT permit to the user NOR the automatic negotiation between the VPN-server of the VPN-provider and NOR the free choice of the user -- ONLY the choice from the LIST of the weak TLS ranges
So, here I asking you again about the automatic negotiation: are you know the way the user of the DD-WRT can request the automatic negotiation of the TLS handshake???
Quote:
p.s. Sorry, but I don't know anything about your addressed feature:
Quote:
... the ability to alternate the status of the radio (on - off) by pressing on the button of auto-configuration of the radio-connectivity ...
I know... I was simple asking for your help with the fixing this bug by the developers of the DD-WRT.
... I want the server be managing the negotiation by it own rank! Are you know the way to set this strategy in DD-WRT???
Without the option tls-cipher in your DD-WRT config the client and server negotiate the cipher to use.
But then you have to trust your VPN provider using the predefined list of TLS ciphers in order of preference. Manipulations can be done on the server side by individual lists.
But if you had read the OpenVPN manual you would have already known it.
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage _________________ Ongoing experiences with:
Linksys E3000 and WRT610N v2
TP-Link Archer C9
Raspberry Pi and TP-Link TL-WR710N with OpenWRT
You are a very tough mate!