75 replies to this topic

[Pippin]

road warriors will usually be MASQUERADE

Nope, you have to set it yourself or add a route to the gateway.

 

to give Joe Average the chance to set up a secure and good working VPN.

A relatively secure standard config can be provided but doing crypto on these devices is soso.

But off course better then nothing

[Pippin]

1. remove --ns-cert-type server, instead use 3.

Cannot edit my post but should be:

1. remove --ns-cert-type server, instead use 2.

[daveraver]

I dont understand too many things. Can we join all knowledge to update the guide, chapter 2, which would be the secure ip/ip range to use??? it would be better to make a concretion of all the discussion. thank you.
if we change the openvpn version to 2.4, we have to update the parameters, so everybody can feel free to add more info in the wiki.

Edited by daveraver, 15 January 2017 - 13:09.

[Pippin]

By the way, great to see that things start moving and hope it will move on.

[SpaceRat]

4. add --topology subnet server side (pushed to clients automatically)

Not necessary, it's the default, as it is required for Windows clients.

[SpaceRat]

road warriors will usually be MASQUERADE

Nope, you have to set it yourself or add a route to the gateway

Let me re-phrase this:
For road warriors (using tun) you usually will want to use MASQUERADE.

My language reflects my attitude: I do not put the current limitations into my words but how things should be

[Pippin]

Not necessary, it's the default, as it is required for Windows clients

Euuh, you sure?

The default was net30 because of Windows could not handle topology subnet.....

 

If not stated otherwise, net30 still is in 2.3.x

For 2.4 the default is topology subnet......AFAIK

[Pippin]

For road warriors (using tun) you usually will want to use MASQUERADE

In our use case making it easy for users, yes indeed.

[SpaceRat]

For road warriors (using tun) you usually will want to use MASQUERADE

In our use case making it easy for users, yes indeed.

The use case(s) where this wouldn't be true would be company networks (Which company will use simple-rsa to set up OpenVPN on their E2 receiver? ) ...

... or clienting to "Privacy providers" using VPN software and I strongly discourage their use on non-border-devices.

People should be aware that they
a.) Turn their E2 box into a border device (Which it was never meant to be)
b.) Grant full access to anybody and his grandma (If that privacy provider doesn't put a firewall into the way on his side) or at least to the provider that way (unless they also figure out how to configure iptables on their E2 box ...)

[Pippin]

There could be a checkbox to allow/disallow traffic to LAN (ip_forward and MASQ) with info warning them of the possible consequences.

 

But really, I think that should not be offered to avoid shooting feet and adding work/maintenance for dev`s to implement  

Those who want should know what they do...I know, there are always users........

 

It won`t be fool proof and/or perfect anyway

[SpaceRat]

Scenario:
local LAN: 192.168.33.0/24
local gateway: 192.168.33.1
local gateway is also acting as a DNS resolver and the local domain is "box"

The user sets up OpenVPN on an E2 box named "quadbox"
There are two net-wide public hostnames (Usually IPv4 DynDNS hosts): mynet.mooo.com and mynet.hopto.org
There is also one host-specific hostname (Usually IPv6 DynDNS hosts): quadbox.mooo.com

The user choses to use port 443 for OpenVPN, "tun" and "TCP"

Resulting server config (Without certs, they will be appended):

proto tcp6
port 443
dev tun
server 172.31.33.0 255.255.255.0
comp-lzo yes
keepalive 10 60
verb 3
client-to-client
float
push "dhcp-option DNS 192.168.33.1"
push "dhcp-option DOMAIN box"
push "dhcp-option SEARCH box"
push "route 192.168.33.0 255.255.255.0"
push "route 172.31.33.0 255.255.255.0"
push "route-gateway "172.31.33.1"

Resulting client config (Without certs, they will be appended):

remote quadbox.mooo.com 443
remote mynet.mooo.com 443
remote mynet.hopto.org 443
proto tcp6-client
dev tun
resolv-retry infinite
mute-replay-warnings
comp-lzo
verb 3
keepalive 10 60
persist-key
persist-tun
nobind
tls-client
mute 20
ping-timer-rem

Any suggestions for enhancements/changes?

[SpaceRat]

There could be a checkbox to allow/disallow traffic to LAN (ip_forward and MASQ) with info warning them of the possible consequences.
But really, I think that should not be offered to avoid shooting feet and adding work/maintenance for dev`s to implement  

Actually I would consider doing MASQ and ip_forwarding to be less of a shooting into the feet then the other way around.

To put things clear:
I have a very conservative understanding of the term VPN.
VPN means Virtual Private Network and has the purpose to connect trusted remote clients to the local network as if they were local.

If you work in a home office and get some VPN access for that, it's logical that this VPN grants access to the company network's ressources that are not available on the public internet (Else you wouldn't need that VPN).
Similarily a VPN for private use is meant to grant remote access to - maybe even critical - network ressources for legitimate users without having to make them publically available.

This is the classical definition of a VPN and I'm not giving ground to those perverting the term, just as I refuse to call the Windows shell/console a "DOS box" when it can't even execute DOS commands anymore ...

Perverting the term "private" by either spreading client certs/profiles like Peter North spreads his semen or by tunneling public connections makes a VPN no longer qualify as a VPN.
Those are just tunnels, encrypted maybe, but they do not establish a VPN connection!

[SpaceRat]

Or in short:

• Do not hand out certs/keys/profiles for your VPN to people you wouldn't also give a key to your front door.
• Do not install certs/profiles for VPNs from people you wouldn't also give a key to your front door.

The more automated our homes become, the more this turns from a comparison into a synonym:
As soon as I replace my Doorcom Analog with a Doorcom IP, having access to my network would be the very same as a key to my house's front door!

[Pippin]

Yes, good points.

 

a VPN for private use is meant to grant remote access to

Controlled yes, but you right, here don`t need it.

 

 

Suggestions:

1. Remove --tls-client from client config, instead do 2.

2. Add --client, which expands to --tls-client and --pull, --pull you need because you --push on server

3. Add --remote-cert-tls server to client config so that client verifies server

4. Make client-to-client selectable? (personally not too fond of this option, I don`t use it but use iptables instead)

 

push "route-gateway "172.31.33.1"

Remove typo "

[SpaceRat]

New resulting server config:

proto tcp6
port 443
dev tun
server 172.31.33.0 255.255.255.0
comp-lzo yes
keepalive 10 60
verb 3
client-to-client
cipher CAMELLIA-256-CBC
float
push "dhcp-option DNS 192.168.33.1"
push "dhcp-option DOMAIN box"
push "dhcp-option SEARCH box"
push "route 192.168.33.0 255.255.255.0"
push "route 172.31.33.0 255.255.255.0"
push "route-gateway 172.31.33.1"

New resulting client config:

remote quadbox.mooo.com 443
remote mynet.mooo.com 443
remote mynet.hopto.org 443
proto tcp6-client
dev tun
resolv-retry infinite
remote-cert-tls server
mute-replay-warnings
comp-lzo
verb 3
keepalive 10 60
persist-key
persist-tun
client
mute 20
ping-timer-rem

Changes in server:
- Set "cipher" to avoid BF-CBC
Uses "AES-256-GCM" if available, falls back to "CAMELLIA-256-CBC" if available, falls back to "AES-256-CBC" if available
If none of the above is available, use BF-CBC but set keysize to 448
- Fixed a typo

Changes in client:
- Removed "nobind" from client, it's default for a client
- Changed "tls-client" to "client" (I was pretty sure that "proto xxx-client" expands to "client" too)
- Added "remote-cert-tls server"

[SpaceRat]

Suggestions still welcome

[Pippin]

Yup, it will override specified cipher to AES-GCM if both sides support it.

 

cipher CAMELLIA-256-CBC

Typo? AES-256-CBC preference for clients/servers that support AES-NI.

 

use BF-CBC but set keysize to 448

If the purpose is to mitigate SWEET32 in case only falback to blowfish is available, it is advised to use --reneg-bytes 64000000

Changing --keysize does not change blocksize so I think remove --keysize and add --reneg-bytes 64000000 to follow given advice from OpenVPN.

https://community.op...pn/wiki/SWEET32

Furthermore, use care to change --keysize according to manual.

 

However, on that page they state --reneg-bytes 64000 but is not correct.

Here it is correct:

https://sweet32.info/

[SpaceRat]

Yup, it will override specified cipher to AES-GCM if both sides support it.

What is this going to tell me?

 

cipher CAMELLIA-256-CBC

Typo? AES-256-CBC preference for clients/servers that support AES-NI.

No, intention.

AES was developed by NIST/NSA, CAMELLIA wasn't
That's why I set it to prefer CAMELLIA over AES if AES-GCM is not available.

Any objections?

 

use BF-CBC but set keysize to 448

If the purpose is to mitigate SWEET32 in case only falback to blowfish is available, it is advised to use --reneg-bytes 64000000

"If they don't control the server configuration, they can mitigate the attack by forcing frequent rekeying with reneg-bytes 64000000."
We do ...

Anyways, I wonder if this last fallback is ever going to happen, as I just implemented it for the theoretical case that neither AES nor CAMELLIA are available ...

[Pippin]

Any objections?

For me not really, you trust others (Japanese) ?

I think if one is in "their" picture one will use other methods, and they too.

How far one has to go for a STB.....

 

I wonder if this last fallback is ever going to happen

 

https://forums.openv...&p=66823#p66823

Seems to work ok.

 

What is this going to tell me?

That NCP is working

[SpaceRat]

Just for info:
[openvpn] Bump to 2.4.0 - https://github.com/o...ead2f12a049191c
Add easy-rsa package and add it to feeds - https://github.com/o...0afd99d068eba84