Tls error tls crypt unwrapping failed from

OpenVPN Support Forum

Community Support Forum

OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:32 pm

Tue Jan 10 00:31:14 2017 tls-crypt unwrap error: packet too short
Tue Jan 10 00:31:14 2017 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:93.245.255.104:55912

How to fix this error?

OpenVPN 2.4.0 windows (server)
and
OpenVPN 2.4.0 Linux (openWRT/DD-wrt/LEDE they all have the same message) as client

windows — windows client I don’t see this error
linux — linux I don’t see it either.

windows server — linux client = error message..

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:38 pm

ehm.. I know reverting back to tls-auth solves this error message, but that’s not what I’m asking really although it fixes the error..

I do want to use the tls-crypt but working LOL

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:58 pm

never mind.. although I ./scripts/feeds update -a
and ./scripts/feeds install -a

then I did make and it did show 2.4.0 in the GUI interface but in command openvpn shows version 2.3.13

so I guess I have to do make dirclean

or even make distclean which I hope to avoid so my menuconfig remains..

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 10, 2017 2:16 am

well. I now have definately 2.4.0 running and still the error.

tls-crypt with the ta.key under linux can’t connect to a windows 2.4.0 with tls-crypt.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 10, 2017 12:27 pm

than everything is working out of the box and all verifications result in OK and no errors whatsoever!

So it’s really the tls-crypt on the linux side as other windows clients with tls-crypt just work fine!

Re: TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Tue Jan 10, 2017 5:06 pm

I have a W10 Server and a Linux client both running openvpn-2.4.0 with — tls-crypt enabled correctly and it works perfectly for me. You must restart your server & client if you change a configuration option.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 11, 2017 9:09 pm

Thank you for your reply.
I did already restart the whole system. Shutdown. No power.
So I’m pretty sure it’s not a restart issue.

If it works on your end, then I presume it’s working and thus something
is wrong on my end.

I’ll build the firmware from scratch. Maybe some old 2.3 objects still somewhere
in the firmware, although it says 2.4.0 when I openvpn —version.

But thank you anyway, now I know it’s working for someone, it means it should be working
for me as well.

Re: TLS Error: tls-crypt unwrapping failed from

Post by chuckler » Sun Jan 15, 2017 6:06 pm

I’m having the same problem with a LEDE build in a router. I’m using OpenVPN 2.4.0 but still it looks like the

is not applied to the LEDE code, because if you enabled it you can still connect to the server if you disable the tls-auth option in the server config.

Maybe it’s something to do with LEDE/OpenWRT, I’ll open a new post in their forums.

Re: TLS Error: tls-crypt unwrapping failed from

Post by chuckler » Sun Jan 15, 2017 6:13 pm

this is the post on the LEDE forums.

Maybe we could help them.

Re: TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Sun Jan 15, 2017 8:25 pm

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 24, 2017 8:46 pm

I found out the error comes from AES-256-GCM

or any other encryption method.

The only thing that tls-crypt is compatible with is AES-256-CTR

All other encryption options are now just useless if you want to use tls-crypt.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 25, 2017 7:43 am

Ok, so it should work with AES-256-GCM as it applies CTR

Must be LEDE/OpenWRT specific then.

Back to LEDE forums

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 25, 2017 9:05 am

Solution to the problem I wrote in the last comment:

will be applied to the standard git some time in future. Maybe even today, maybe next month.
But there’s a manual fix for those who are interested.

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Wed Jan 25, 2017 2:51 pm

Openvpn was not involved in that.

With regard to this:

AES-256-CTR has been initially selected for use with — tls-crypt because it is » a nonce misuse-resistant authenticated encryption scheme«.

— tls-crypt only effects the control channel not the data channel. Ciphers available to the data channel are as they always have been and can be configured with — cipher and/or negotiated internally by openvpn with — ncp-ciphers, which is enabled by default in 2.4

It is complicated but well documented .. worth your time to read.

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Fri Apr 07, 2017 7:52 pm

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by xioxify » Sun Jan 21, 2018 7:47 am

Thanks mrgenie for sharing your experience.
I have this problem too.
You said «The only thing that tls-crypt is compatible with is AES-256-CTR», by this you mean I change GCM in the config line » cipher AES-256-GCM» to AES-256-CTR or change the GCM in this line: «tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384» .

Another question:
you used the tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM- SHA384 and the «auth SHA384». They have to be the same SHA384 or can I use the «auth SHA512»??

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Sun Jan 21, 2018 3:28 pm

This is simply wrong .. you are mixing up different options that are not linked.

Источник

OpenVPN Support Forum

Community Support Forum

tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — see th

tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — see th

Post by mbelchin » Wed Jan 08, 2020 4:05 pm

I just recently installed a new vpn server using openvpn 2.4.7-1 on a debian 10.2 machine.

My problem is that I have server configured to use

This is my server config.

and this is my client config:

Can someone help me out with that ? I’m not sure if the mute-reply-warnings isn’t working or it’s just appearing because of some misconfiguration.

Thanks in advance.

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by TinCanTech » Wed Jan 08, 2020 5:02 pm

Note: —tls-crypt does not require a direction parameter.

You should probably report that as a bug to which ever script you used (pivpn?)

Set —verb 4 and remove —mute-replay-warnings and then post your complete log as per this:
viewtopic.php?f=30&t=22603#p68963

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by mbelchin » Thu Jan 09, 2020 9:23 pm

Thanks for answering. Will follow your instructions

Can you or any other administrator remove this threat ?

Forgot to remove remote ip from config

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by TinCanTech » Fri Jan 10, 2020 12:22 am

Источник

OpenVPN Support Forum

Community Support Forum

TLS Error: tls-crypt unwrapping failed

TLS Error: tls-crypt unwrapping failed

Post by xioxify » Sun Jan 21, 2018 5:12 pm

I’m sorry. I’m new to OpenVPN. Here is my config and I get this error: TLS Error: tls-crypt unwrapping failed from
I got this error when I added tls-crypt to the config.
Would you please check for the problem? Or is this config right form all aspects?
Thanks

port 1194
proto udp4
dev tun
topology subnet
tls-server

ca ca.crt
cert server.crt
key server.key
dh dh4096.pem
tls-crypt tls.tlsauth

remote-cert-eku «TLS Web Client Authentication»
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-CBC
auth SHA512
reneg-sec 60

server 10.8.0.0 255.255.255.0
push «redirect-gateway autolocal def1»
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»
push «dhcp-option DNS 10.8.0.1»

compress lz4-v2
push «compress lz4-v2»

keepalive 10 120
persist-key
persist-tun
explicit-exit-notify 1
status openvpn-status.log
verb

client
tls-client
dev tun
proto udp4
remote **************
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
redirect-gateway autolocal
compress lz4-v2

remote-cert-eku «TLS Web Server Authentication»
tls-crypt tls.tlsauth

tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
reneg-sec 60

Источник

tls-crypt unwrap error: packet too short #21

I have tls-auth enabled on my ovpn server. I supply the required file (the TLS key from the server, which the script accepts and sends) but the command fails saying CRIT: Not responding .

Checking the ovpn logs I see that it was having trouble reading the tls key.

Here us the command being run:

The text was updated successfully, but these errors were encountered:

Can I get some help.

Can you verify that the very same tls key file works with other clients?

@Engineer-of-Stuff can you post your openvpn server config? and the version of the server binary please.

hello guys, I am confirming that tls-crypt does not work at all.

I am getting the following error:
Sat Feb 9 14:07:47 2019 tls-crypt unwrap error: packet authentication failed

Here is my server.conf:
mode server
tls-server
tls-crypt /etc/openvpn/certs/tlscrypt.key 0
proto udp
dev tun0
port 1194
topology subnet
group openvpn
user openvpn
auth SHA512
cipher AES-256-GCM
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
duplicate-cn
reneg-sec 0
persist-key
compress lz4-v2
fast-io
tun-mtu 1200
verb 3
max-clients 250
auth-retry interact
ping-restart 15
ping 5
inactive 1800
management 127.0.0.1 5555
status /var/log/openvpn/status.log
log-append /var/log/openvpn/access.log
tmp-dir /etc/openvpn/tmp
plugin /etc/openvpn/plugins/openvpn-plugin-auth-script.so /etc/openvpn/scripts/authenticate.sh

Version of openvpn server binary:
openvpn-2.4.6-1.el7.x86_64

Can you help me please ?

Thank you very much.

@Engineer-of-Stuff i see «Tue Dec 18 21:23:01 2018 TCP connection established with [AF_INET]myip» but for the check script you use udp.
@drajcan i just tested it for my setup and it works. maybe «tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384» is the problem here.

Источник

OpenVPN Support Forum

Community Support Forum

unwrap error: packet too short

unwrap error: packet too short

Post by tontonjab » Tue Jul 27, 2021 4:08 pm

Hello again !
Now, i am facing a very weird issue. My connected devices are ok for 4-7 days, and. then, they disconnect. And i need a reboot to make them work again.

Mon Jul 26 23:43:57 2021 gate_******/92.184.***.***:60371 SIGUSR1[soft,ping-restart] received, client-instance restarting
Mon Jul 26 23:43:58 2021 [gate_******] Inactivity timeout (—ping-restart), restarting
Mon Jul 26 23:43:58 2021 SIGUSR1[soft,ping-restart] received, client-instance restarting
Tue Jul 27 03:18:27 2021 tls-crypt unwrap error: packet too short
Tue Jul 27 03:18:27 2021 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:*******:59555
Tue Jul 27 06:36:48 2021 tls-crypt unwrap error: packet too short
Tue Jul 27 06:36:48 2021 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:*********:58319
Tue Jul 27 09:25:09 2021 tls-crypt unwrap error: packet too short
Tue Jul 27 09:25:09 2021 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:*************:54677

i read some advices about switching from UDP to TCP. Do you think that might help ?

Re: unwrap error: packet too short

Post by TinCanTech » Tue Jul 27, 2021 4:29 pm

Well, you should not because Openvpn recovers from that problem easily.

Re: unwrap error: packet too short

Post by tontonjab » Wed Jul 28, 2021 11:07 am

Thx you, and sorry for the lack of infos:

SERVEUR
Linux ns3033356 5.8.0-43-generic #49-Ubuntu SMP Fri Feb 5 03:01:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Linux klk-fevo-SERIAL 4.14.9-klk #1 SMP Tue Feb 18 14:41:02 CET 2020 armv7l armv7l armv7l GNU/Linux

Re: unwrap error: packet too short

Post by 300000 » Wed Jul 28, 2021 11:28 am

Inactivity timeout (—ping-restart), restarting

you server cut it off after no active you need make it active for keep open server running, just adding this into your server so it will work for you

Re: unwrap error: packet too short

Post by TinCanTech » Wed Jul 28, 2021 11:29 am

Re: unwrap error: packet too short

Post by tontonjab » Sat Jul 31, 2021 10:24 pm

Thx you a lot for your help, i wasnt able to access to internet for a while

OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021
library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_option_checking=no enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

keepalive 90 190
push «ping 190»

Re: unwrap error: packet too short

Post by TinCanTech » Sat Jul 31, 2021 10:55 pm

There has been a lot of development.

Upgrade your client or define your compression model.
See: — comp-lzo and — compress in the manual: https://community.openvpn.net/openvpn/w . n24ManPage

Re: unwrap error: packet too short

Post by tontonjab » Sat Jul 31, 2021 11:09 pm

I have to use LZO ? according to the doc, for backward comp. Why do you point this ?

A cant update openVPN, because its a device from the market. (LoRa gateway).

Re: unwrap error: packet too short

Post by TinCanTech » Sun Aug 01, 2021 1:37 pm

Re: unwrap error: packet too short

Post by tontonjab » Mon Aug 02, 2021 3:52 pm

Hello TinCan, i have added LZO to my conf, now i have:

[olog]
Mon Aug 2 15:46:13 2021 us=667023 *.*.*.*:41551 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1550′, remote=’link-mtu 1549′
Mon Aug 2 15:46:13 2021 us=667049 *.*.*.*:41551 WARNING: ‘comp-lzo’ is present in local config but missing in remote config, local=’comp-lzo’
Mon Aug 2 15:46:13 2021 us=728478 *.*.*.*:41551 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit EC, curve: prime256v1
Mon Aug 2 15:46:13 2021 us=728548 *.*.*.*:41551 [gate-02082021_0000003] Peer Connection Initiated with [AF_INET6]::ffff:*.*.*.*:41551
Mon Aug 2 15:46:13 2021 us=738208 gate-02082021_0000003/*.*.*.*:41551 MULTI_sva: pool returned IPv4=10.8.0.4, IPv6=fd42:42:42:42::1002
Mon Aug 2 15:46:13 2021 us=738270 gate-02082021_0000003/*.*.*.*:41551 MULTI: Learn: 10.8.0.4 -> gate-02082021_0000003/*.*.*.*:41551
Mon Aug 2 15:46:13 2021 us=738284 gate-02082021_0000003/*.*.*.*:41551 MULTI: primary virtual IP for gate-02082021_0000003/*.*.*.*:41551: 10.8.0.4
Mon Aug 2 15:46:13 2021 us=738296 gate-02082021_0000003/*.*.*.*:41551 MULTI: Learn: fd42:42:42:42::1002 -> gate-02082021_0000003/*.*.*.*:41551
Mon Aug 2 15:46:13 2021 us=738309 gate-02082021_0000003/*.*.*.*:41551 MULTI: primary virtual IPv6 for gate-02082021_0000003/*.*.*.*:41551: fd42:42:42:42::1002
Mon Aug 2 15:46:14 2021 us=915069 gate-02082021_0000003/*.*.*.*:41551 PUSH: Received control message: ‘PUSH_REQUEST’
Mon Aug 2 15:46:14 2021 us=915225 gate-02082021_0000003/*.*.*.*:41551 SENT CONTROL [gate-02082021_0000003]: ‘PUSH_REPLY,dhcp-option DNS 94.140.14.14,dhcp-option DNS 94.140.15.15,redirect-gateway def1 bypass-dhcp,tun-ipv6,route-ipv6 2000::/3,redirect-gateway ipv6,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd42:42:42:42::1002/112 fd42:42:42:42::1,ifconfig 10.8.0.4 255.255.255.0,peer-id 2,cipher AES-128-GCM’ (status=1)
Mon Aug 2 15:46:14 2021 us=915311 gate-02082021_0000003/*.*.*.*:41551 Data Channel MTU parms [ L:1550 D:1450 EF:50 EB:406 ET:0 EL:3 ]
Mon Aug 2 15:46:14 2021 us=915514 gate-02082021_0000003/*.*.*.*:41551 Outgoing Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 15:46:14 2021 us=915553 gate-02082021_0000003/*.*.*.*:41551 Incoming Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 15:46:15 2021 us=249623 gate-02082021_0000003/*.*.*.*:41551 Bad LZO decompression header byte: 96
Mon Aug 2 15:46:15 2021 us=303133 gate-17072021-TEST/176.176.203.106:39416 Bad LZO decompression header byte: 42
Mon Aug 2 15:46:15 2021 us=328973 gate-17072021-TEST/176.176.203.106:49496 Bad LZO decompression header byte: 42
Mon Aug 2 15:46:19 2021 us=2714 gate-02082021_0000003/*.*.*.*:41551 Bad LZO decompression header byte: 96
Mon Aug 2 15:46:25 2021 us=520043 gate-17072021-TEST/176.176.203.106:39416 Bad LZO decompression header byte: 42
Mon Aug 2 15:46:25 2021 us=538987 gate-17072021-TEST/176.176.203.106:49496 Bad LZO decompression header byte: 42
Mon Aug 2 15:46:26 2021 us=682303 gate-02082021_0000003/*.*.*.*:41551 Bad LZO decompression header byte: 96
[/olog]

I have to add compress lzo to client too ?

I have removed persist-tun. Why do you point this ?

Since i added compress lzo, everything fail. If i add compress lzo to the client too, i have:
Mon Aug 2 15:55:22 2021 us=903752 Float requested for peer 0 to 176.176.203.106:46397
Mon Aug 2 15:55:22 2021 us=903792 AEAD Decrypt error: cipher final failed
Mon Aug 2 15:55:32 2021 us=953478 Float requested for peer 0 to 176.176.203.106:46397
Mon Aug 2 15:55:32 2021 us=953526 AEAD Decrypt error: cipher final failed

Re: unwrap error: packet too short

Post by TinCanTech » Mon Aug 02, 2021 4:17 pm

Re: unwrap error: packet too short

Post by tontonjab » Mon Aug 02, 2021 4:37 pm

my server dont want to restart with this:

port 1194
proto udp6
dev tun
user nobody
group nogroup
persist-key
persist-tun
duplicate-cn
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push «dhcp-option DNS 94.140.14.14»
push «dhcp-option DNS 94.140.15.15»
push «redirect-gateway def1 bypass-dhcp»
server-ipv6 fd42:42:42:42::/112
tun-ipv6
push tun-ipv6
push «route-ipv6 2000::/3»
push «redirect-gateway ipv6»
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_XL98c6RoSdvOVX3E.crt
key server_XL98c6RoSdvOVX3E.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
client-to-client
management 127.0.0.1 17562
verb 4
mute 20
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
comp-lzo no
push «comp-lzo no»
compress no
push «compress no»

Re: unwrap error: packet too short

Post by tontonjab » Mon Aug 02, 2021 5:06 pm

now. i have this kind of logs:

[olog]
Mon Aug 2 17:00:09 2021 us=188822 gate-17072021-TEST/*.*.*.*:58701 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Mon Aug 2 17:00:09 2021 us=188887 gate-17072021-TEST/*.*.*.*:58701 Outgoing Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:00:09 2021 us=188897 gate-17072021-TEST/*.*.*.*:58701 Incoming Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:00:10 2021 us=548466 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:12 2021 us=797275 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:12 2021 us=797356 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:14 2021 us=715360 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:22 2021 us=942469 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:24 2021 us=155921 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:27 2021 us=995568 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:34 2021 us=320107 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:38 2021 us=68917 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:42 2021 us=76007 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:49 2021 us=23984 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:52 2021 us=351016 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:00:59 2021 us=603968 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:03 2021 us=67276 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:09 2021 us=115492 gate-17072021-TEST/*.*.*.*:48864 [gate-17072021-TEST] Inactivity timeout (—ping-restart), restarting
Mon Aug 2 17:01:09 2021 us=115563 gate-17072021-TEST/*.*.*.*:48864 SIGUSR1[soft,ping-restart] received, client-instance restarting
Mon Aug 2 17:01:09 2021 us=978005 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:13 2021 us=451673 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:15 2021 us=996043 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:18 2021 us=796970 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:19 2021 us=796852 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:25 2021 us=857026 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:29 2021 us=119242 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:30 2021 us=76079 gate-17072021-TEST/*.*.*.*:37423 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:35 2021 us=446638 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:36 2021 us=405866 *.*.*.*:58491 VERIFY OK: depth=0, CN=gate-17072021-TEST
Mon Aug 2 17:01:36 2021 us=444620 *.*.*.*:58491 [gate-17072021-TEST] Peer Connection Initiated with [AF_INET6]::ffff:*.*.*.*:58491
Mon Aug 2 17:01:36 2021 us=444712 gate-17072021-TEST/*.*.*.*:58491 MULTI_sva: pool returned IPv4=10.8.0.4, IPv6=fd42:42:42:42::1002
Mon Aug 2 17:01:36 2021 us=444821 gate-17072021-TEST/*.*.*.*:58491 MULTI: Learn: 10.8.0.4 -> gate-17072021-TEST/*.*.*.*:58491
Mon Aug 2 17:01:36 2021 us=444851 gate-17072021-TEST/*.*.*.*:58491 MULTI: primary virtual IP for gate-17072021-TEST/*.*.*.*:58491: 10.8.0.4
Mon Aug 2 17:01:36 2021 us=444883 gate-17072021-TEST/*.*.*.*:58491 MULTI: Learn: fd42:42:42:42::1002 -> gate-17072021-TEST/*.*.*.*:58491
Mon Aug 2 17:01:36 2021 us=444912 gate-17072021-TEST/*.*.*.*:58491 MULTI: primary virtual IPv6 for gate-17072021-TEST/*.*.*.*:58491: fd42:42:42:42::1002
Mon Aug 2 17:01:37 2021 us=552481 gate-17072021-TEST/*.*.*.*:58491 PUSH: Received control message: ‘PUSH_REQUEST’
Mon Aug 2 17:01:37 2021 us=552613 gate-17072021-TEST/*.*.*.*:58491 SENT CONTROL [gate-17072021-TEST]: ‘PUSH_REPLY,dhcp-option DNS 94.140.14.14,dhcp-option DNS 94.140.15.15,redirect-gateway def1 bypass-dhcp,tun-ipv6,route-ipv6 2000::/3,redirect-gateway ipv6,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd42:42:42:42::1002/112 fd42:42:42:42::1,ifconfig 10.8.0.4 255.255.255.0,peer-id 2,cipher AES-128-GCM’ (status=1)
Mon Aug 2 17:01:37 2021 us=552645 gate-17072021-TEST/*.*.*.*:58491 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Mon Aug 2 17:01:37 2021 us=552774 gate-17072021-TEST/*.*.*.*:58491 Outgoing Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:01:37 2021 us=552796 gate-17072021-TEST/*.*.*.*:58491 Incoming Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:01:38 2021 us=980755 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:41 2021 us=796708 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:43 2021 us=36509 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:44 2021 us=796586 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:51 2021 us=233395 gate-17072021-TEST/*.*.*.*:45815 [gate-17072021-TEST] Inactivity timeout (—ping-restart), restarting
Mon Aug 2 17:01:51 2021 us=233482 gate-17072021-TEST/*.*.*.*:45815 SIGUSR1[soft,ping-restart] received, client-instance restarting
Mon Aug 2 17:01:51 2021 us=836077 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:01:54 2021 us=671293 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:01 2021 us=219791 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:04 2021 us=540003 gate-17072021-TEST/*.*.*.*:58701 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:08 2021 us=476075 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:15 2021 us=136429 *.*.*.*:36621 VERIFY OK: depth=0, CN=gate-17072021-TEST
Mon Aug 2 17:02:15 2021 us=175268 *.*.*.*:36621 [gate-17072021-TEST] Peer Connection Initiated with [AF_INET6]::ffff:*.*.*.*:36621
Mon Aug 2 17:02:15 2021 us=175335 gate-17072021-TEST/*.*.*.*:36621 MULTI_sva: pool returned IPv4=10.8.0.5, IPv6=fd42:42:42:42::1003
Mon Aug 2 17:02:15 2021 us=175425 gate-17072021-TEST/*.*.*.*:36621 MULTI: Learn: 10.8.0.5 -> gate-17072021-TEST/*.*.*.*:36621
Mon Aug 2 17:02:15 2021 us=175444 gate-17072021-TEST/*.*.*.*:36621 MULTI: primary virtual IP for gate-17072021-TEST/*.*.*.* 10.8.0.5
Mon Aug 2 17:02:15 2021 us=175471 gate-17072021-TEST/*.*.*.*:36621 MULTI: Learn: fd42:42:42:42::1003 -> gate-17072021-TEST/*.*.*.*:36621
Mon Aug 2 17:02:15 2021 us=175501 gate-17072021-TEST/*.*.*.*:36621 MULTI: primary virtual IPv6 for gate-17072021-TEST/*.*.*.* fd42:42:42:42::1003
Mon Aug 2 17:02:16 2021 us=370302 gate-17072021-TEST/*.*.*.*:36621 PUSH: Received control message: ‘PUSH_REQUEST’
Mon Aug 2 17:02:16 2021 us=370406 gate-17072021-TEST/*.*.*.*:36621 SENT CONTROL [gate-17072021-TEST]: ‘PUSH_REPLY,dhcp-option DNS 94.140.14.14,dhcp-option DNS 94.140.15.15,redirect-gateway def1 bypass-dhcp,tun-ipv6,route-ipv6 2000::/3,redirect-gateway ipv6,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd42:42:42:42::1003/112 fd42:42:42:42::1,ifconfig 10.8.0.5 255.255.255.0,peer-id 3,cipher AES-128-GCM’ (status=1)
Mon Aug 2 17:02:16 2021 us=370489 gate-17072021-TEST/*.*.*.*:36621 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Mon Aug 2 17:02:16 2021 us=370625 gate-17072021-TEST/*.*.*.*:36621 Outgoing Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:02:16 2021 us=370648 gate-17072021-TEST/*.*.*.*:36621 Incoming Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:02:17 2021 us=724238 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:18 2021 us=744117 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:20 2021 us=796857 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:21 2021 us=796859 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:21 2021 us=836055 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:30 2021 us=236026 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:31 2021 us=376023 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:40 2021 us=964340 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:41 2021 us=468529 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:43 2021 us=36117 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:46 2021 us=876064 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:53 2021 us=210813 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:02:56 2021 us=190127 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:03 2021 us=569945 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:06 2021 us=285917 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:13 2021 us=279779 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:16 2021 us=520990 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:19 2021 us=579151 gate-17072021-TEST/*.*.*.*:55418 [gate-17072021-TEST] Inactivity timeout (—ping-restart), restarting
Mon Aug 2 17:03:19 2021 us=579230 gate-17072021-TEST/*.*.*.*:55418 SIGUSR1[soft,ping-restart] received, client-instance restarting
Mon Aug 2 17:03:20 2021 us=156134 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:23 2021 us=361720 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:31 2021 us=226888 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:33 2021 us=293767 gate-17072021-TEST/*.*.*.*:58491 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:41 2021 us=200360 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:42 2021 us=832979 *.*.*.*:33178 VERIFY OK: depth=0, CN=gate-17072021-TEST
Mon Aug 2 17:03:42 2021 us=872356 *.*.*.*:33178 [gate-17072021-TEST] Peer Connection Initiated with [AF_INET6]::ffff:*.*.*.*:33178
Mon Aug 2 17:03:42 2021 us=872415 gate-17072021-TEST/*.*.*.*:33178 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=fd42:42:42:42::1004
Mon Aug 2 17:03:42 2021 us=872469 gate-17072021-TEST/*.*.*.*:33178 MULTI: Learn: 10.8.0.6 -> gate-17072021-TEST/*.*.*.*:33178
Mon Aug 2 17:03:42 2021 us=872484 gate-17072021-TEST/*.*.*.*:33178 MULTI: primary virtual IP for gate-17072021-TEST/*.*.*.* 10.8.0.6
Mon Aug 2 17:03:42 2021 us=872499 gate-17072021-TEST/*.*.*.*:33178 MULTI: Learn: fd42:42:42:42::1004 -> gate-17072021-TEST/*.*.*.*:33178
Mon Aug 2 17:03:42 2021 us=872535 gate-17072021-TEST/*.*.*.*:33178 MULTI: primary virtual IPv6 for gate-17072021-TEST/*.*.*.* fd42:42:42:42::1004
Mon Aug 2 17:03:43 2021 us=901879 gate-17072021-TEST/*.*.*.*:33178 PUSH: Received control message: ‘PUSH_REQUEST’
Mon Aug 2 17:03:43 2021 us=901981 gate-17072021-TEST/*.*.*.*:33178 SENT CONTROL [gate-17072021-TEST]: ‘PUSH_REPLY,dhcp-option DNS 94.140.14.14,dhcp-option DNS 94.140.15.15,redirect-gateway def1 bypass-dhcp,tun-ipv6,route-ipv6 2000::/3,redirect-gateway ipv6,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd42:42:42:42::1004/112 fd42:42:42:42::1,ifconfig 10.8.0.6 255.255.255.0,peer-id 4,cipher AES-128-GCM’ (status=1)
Mon Aug 2 17:03:43 2021 us=902015 gate-17072021-TEST/*.*.*.*:33178 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Mon Aug 2 17:03:43 2021 us=902123 gate-17072021-TEST/*.*.*.*:33178 Outgoing Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:03:43 2021 us=902142 gate-17072021-TEST/*.*.*.*:33178 Incoming Data Channel: Cipher ‘AES-128-GCM’ initialized with 128 bit key
Mon Aug 2 17:03:45 2021 us=321892 gate-17072021-TEST/*.*.*.*:33178 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:47 2021 us=797199 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:48 2021 us=797169 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:49 2021 us=116115 gate-17072021-TEST/*.*.*.*:33178 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:57 2021 us=137855 gate-17072021-TEST/*.*.*.*:58548 [gate-17072021-TEST] Inactivity timeout (—ping-restart), restarting
Mon Aug 2 17:03:57 2021 us=137934 gate-17072021-TEST/*.*.*.*:58548 SIGUSR1[soft,ping-restart] received, client-instance restarting
Mon Aug 2 17:03:57 2021 us=276115 gate-17072021-TEST/*.*.*.*:33178 IP packet with unknown IP version=15 seen
Mon Aug 2 17:03:58 2021 us=505868 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:04:07 2021 us=414096 gate-17072021-TEST/*.*.*.*:33178 IP packet with unknown IP version=15 seen
Mon Aug 2 17:04:08 2021 us=143250 gate-17072021-TEST/*.*.*.*:36621 IP packet with unknown IP version=15 seen
Mon Aug 2 17:04:12 2021 us=635991 gate-17072021-TEST/*.*.*.*:33178 IP packet with unknown IP version=15 seen
[/olog]

Re: unwrap error: packet too short

Post by TinCanTech » Mon Aug 02, 2021 5:42 pm

Re: unwrap error: packet too short

Post by tontonjab » Tue Aug 03, 2021 8:02 am

Without persist tun, the IP is «refreshed» every connection ? What is the bets approach to point the right client then. Open vpn have a local DNS ?

https://community.openvpn.net/openvpn/ticket/952
According to this, «comp-lzo no» and «compress» options not compatible. Can you help me with this ?

comp-lzo no
push «comp-lzo no»
#compress no
#push «compress no

And it works. For the moment. I will see if my client drops.

I have something weird on my client:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.5 P-t-P:10.8.0.5 Mask:255.255.255.0
inet6 addr: fe80::eba7:fd9b:c714:239b/64 Scope:Link
inet6 addr: fd42:42:42:42::1003/112 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:38 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3668 (3.5 KiB) TX bytes:7288 (7.1 KiB)

tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.6 P-t-P:10.8.0.6 Mask:255.255.255.0
inet6 addr: fd42:42:42:42::1004/112 Scope:Global
inet6 addr: fe80::53fc:8b75:88e7:2ca3/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:47 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4424 (4.3 KiB) TX bytes:288 (288.0 B)

tun0 works. 10.8.0.5 ping from the server. Why i have tun1 ? I have only one conf in /etc/openvpn. What am i doing wrong ?

Источник

I have an openvpn connection that I’m creating on a linux host to another linux host. I believe that there may be a config error or misunderstanding here. I have my client keys and server keys generated, and the CA in place, but I can’t seem to connect at all to the server. the server logs are this:

Mon Jun 29 15:38:28 2020 tls-crypt unwrap error: packet authentication failed

Mon Jun 29 15:38:28 2020 TLS Error: tls-crypt unwrapping failed from [AF_INET]70.15.128.216:55352

On the client, this is what I see:

Mon Jun 29 11:40:18 2020 TLS Error: TLS handshake failed
Mon Jun 29 11:40:18 2020 SIGUSR1[soft,tls-error] received, process restarting
Mon Jun 29 11:40:18 2020 Restart pause, 5 second(s)
Mon Jun 29 11:40:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:40:23 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Jun 29 11:40:23 2020 UDP link local: (not bound)
Mon Jun 29 11:40:23 2020 UDP link remote: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:41:23 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jun 29 11:41:23 2020 TLS Error: TLS handshake failed
Mon Jun 29 11:41:23 2020 SIGUSR1[soft,tls-error] received, process restarting
Mon Jun 29 11:41:23 2020 Restart pause, 5 second(s)
Mon Jun 29 11:41:28 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:41:28 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Jun 29 11:41:28 2020 UDP link local: (not bound)
Mon Jun 29 11:41:28 2020 UDP link remote: [AF_INET]*.*.*.*:1194

Here is my client config file:

client
proto udp
remote *.*.*.* 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
dhcp-option DNS 8.8.8.8
verb 3

and my server config:

local *.*.*.*
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt ta.key 0
topology subnet
server 10.1.0.0  255.255.255.0
ifconfig-pool-persist ipp.txt
push "route *.*.*.* 255.255.255.255" #api
push "route *.*.*.* 255.255.255.255" #rabbitMQ
push "route *.*.*.* 255.255.255.255" #ui
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify
client-config-dir ccd
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log

I just want to confirm that the server is running and is accepting connections. I’m pretty sure my connection request is just malformed. The question is, what is malformed? just an FYI, I’ve used this tutorial to get me going thus far: Install OpenVPN on Debian 10

I’ve also ensured that the client.key file is 400 for permissions.

What is it?

OpenVPN is a software based on free software that allows us to build a virtual private network (VPN), to connect remotely to the server. This software allows us to configure two types of VPN architectures:

• Remote Access VPN: We have a central VPN server, and several VPN clients with the software installed on your computer, smartphone, tablet or other device, and they all connect centrally to the VPN server.
• Site-to-Site VPN: this architecture allows us to intercommunicate between different sites to share resources through a secure network, protected with end-to-end encryption. This type of VPN allows us to intercommunicate offices, company headquarters, etc.

Some very important features of OpenVPN are that it supports extensive configuration, both to improve performance as well as security. It is based on SSL / TLS, therefore, we can create digital certificates for the authentication of VPN clients, in addition, we could also authenticate with certificates plus a username / password that we add to the system. OpenVPN is much easier to configure than IPsec, and thanks to the great support from the community, we will be able to find OpenVPN on all desktop operating systems, servers and even on smartphones and tablets.

What is it for?

If we create an OpenVPN server in our home, it can help us to connect to the Internet in a secure way from any network, be it wired or WiFi, with WEP / WPA encryption or without encryption. All traffic will be encrypted through a tunnel from our computer where we connect to our home and from there it will go to the Internet, it is like being connected to the Internet at home. We must take into account several factors, such as having a good upload speed (30Mbps or higher), and having a public IP address in our home, since if we have CG-NAT we will not be able to connect because we will not be able to do port forwarding in the router.

By mounting an OpenVPN server in our home, we can also access each and every one of the shared resources we have, such as Samba servers, FTP and even access the printer, IP cameras that we have connected, etc. All access permits would be just as if we were physically in our home. OpenVPN is a solution for VPN that implements layer 2 or 3 connections, depending on the chosen connection mode, it will work in one way or another, in addition, an important detail is that the vast majority of operating systems today support OpenVPN, although not it is usually incorporated by hardware manufacturers for firewalls or routers.

OpenVPN uses a set of SSL / TLS protocols that work at the transport layer, and we have two types of operation:

• TUN : The TUN controller emulates a point-to-point device, it is used to create virtual tunnels operating with the IP protocol . In this way, all the packets that are transported through it can be encapsulated as TCP segments or UDP datagrams (later you will see that we choose UDP instead of TCP, and you will ask why, since TCP is connective, reliable and oriented to Connection). The machines behind each end of the link will belong to different subnets.
• TAP : Simulates an Ethernet network interface, more commonly known as bridge or bridge mode, these virtual tunnels directly encapsulate Ethernet packets . This situation allows packaging different fabrics than IP. The machines behind each end of the link can operate as part of the same subnet (if the IP protocol is used). The bridge operating mode is particularly useful to link remote users, since they can connect to the same server and virtually be part of the main network, however, if the private network where the origin is connected coincides with the destination, we will have Routing problems and communication will not work.

In the manual we will use TUN and see how we create a virtual subnet 10.8.0.0/24 where the OpenVPN clients will be when they connect. In this way, it will be much easier to identify the VPN clients that we have connected in the local network.

In this manual I am going to explain how to do it in GNU / Linux (in Debian 10) , although in essence, it is the same for Windows , only the commands in the console (cmd.exe), the certificates and the keys change, they are the The same for both , that is, you can create EVERYTHING in GNU / Linux and then pass it to Windows to use it (either client or server), you only have to change the client / server extension .conf to .ovpn , although in the latest versions OpenVPN for Windows already allows us to recognize and use .conf configuration files, so we will not have to change the extension.

In this manual I am going to show you how to make a very secure OpenVPN configuration, customizing the symmetric, asymmetric and hash encryption algorithms. In this way, we can have the best possible encryption of communications.

Summary of the cryptography to use

• Digital certificates : We will use EC (Elliptical Curves) for the creation of the Public Key Infrastructure . We will create both the certificates of the CA (Certification Authority), as well as the certificates of the server and VPN clients that want to connect. The EC algorithm used is secp521r1, although we have many others available. The hash algorithm that we will use will be SHA512 . An important detail is that not all OpenVPN clients / servers support it, we must have our OpenVPN and cryptographic libraries updated, but nowadays it is rare to find ourselves in a scenario that is not compatible.
• OpenVPN control channel : we will use at least TLS 1.2, and always using PFS (Perfect Forward Secrecy) based on Diffie-Hellmann with elliptic curves (ECDHE). That is, we will use a selection of secure crypto suites, such as TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. If you want to check if your server or client supports this type of encryption, you should put in the console “openvpn –show-tls”.
• OpenVPN data channel : We will use the AES-256-GCM symmetric encryption algorithm, the most secure currently and which has been incorporated into OpenVPN 2.4 and later. If you want to check if your server or client supports this type of encryption, you must put in the console « openvpn –show-ciphers «. If we use AES-256-GCM as data channel encryption, we will not use any HASH algorithm since it is AEAD, however, if we use AES-256-CBC we will use SHA512.

In addition to these security measures, we will include an additional HMAC signature for the first TLS negotiation, in this way, we will protect the system from possible denial of service attacks, UDP Port Flooding attacks and also TCP SYN attacks. When connecting to the server, if the client does not have the correct HMAC signature, it will be blocked. In previous versions of OpenVPN 2.4 the directive was tls-auth , which was only responsible for the authentication of a pre-shared key generated by OpenVPN itself. Now in versions higher than OpenVPN 2.4 it is called tls-crypt , the main difference is that in addition to authenticating, it also encrypts the channel so that no one is able to capture said pre-shared key. The configuration is very similar, the generation of the key is exactly the same in both.

Finally, we will use the UDP protocol instead of TCP, because it is stronger against denial of service attacks, we must remember that UDP is non-connective, unreliable and connection-oriented. However, we can use TCP without any problem to provide the VPN with all the benefits of this protocol.

Steps to follow to work with OpenVPN

Below you will be able to see in detail how to install this software, and also everything you need to start it up with the best possible security provided by this solution to create a virtual private network.

Download and install

The first thing we have to do is install OpenVPN on our computer, either with Windows or Linux. If you use Windows you must go to the official OpenVPN download website and install everything in the installation wizard. If you use an operating system like Debian (we will be using Debian 10 throughout this manual), you will have to enter the following command:

sudo apt update

sudo apt install openvpn

Easy-RSA 3 download for certificates

Once installed, we must download the Easy-RSA 3 software package, this software package is used to create digital certificates easily and quickly. We can modify the length of the key, the type of key, if we want to put a password to the private keys etc. On the official website of the Easy-RSA 3 project on GitHub you have all the information and the possibility of downloading a .zip with everything.

If you are on a Linux system, we recommend using the wget command to download the .zip:

wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz

Next, we must unzip this downloaded file and enter the folder to start configuring the vars file.

tar -zxvf EasyRSA-3.0.8.tgz

Configure Easy-RSA 3 «vars»

The vars.example file is the center of all the configuration of the certificates, it is where we must define if we want to create certificates based on RSA or based on EC. Likewise, it will also allow us to sign the certificates with SHA256 or SHA512 among others. That is, we must configure this configuration file correctly to later create the digital certificates.

The first thing we must do is copy the file vars.example in the same folder with name “vars”, if we do not have it with this name “vars” it will not work. We also have the possibility to rename the file vars.example in “vars”, but we recommend you better make a backup in case you delete something and then it doesn’t work for you.

We go to the main folder of Easy-RSA3 and copy the file in this way:

cp vars.example vars

Once we have the “vars” file, we must edit it with any file editor via console or graphical interface, we will use nano due to its ease. In the following «vars» configuration file you can see how EC would look with the secp521r1 algorithm, signed with SHA512 and we have used a DN (Distinguished Name) putting the CN (Common Name) instead of the typical «organization data »As we have always done before, in this way, we facilitate the creation of certificates, however, we could also do it by indicating the typical organization data.

In the file itself are the original comments in English, and in Spanish we have put ours to facilitate the location of what needs to be modified. A very important detail, WordPress automatically puts these symbols << and >> when it should just put double quotes: »

# Easy-RSA 3 parameter settings

# NOTE: If you installed Easy-RSA from your distro’s package manager, don’t edit
# this file in place – instead, you should copy the entire easy-rsa directory
# to another location so future upgrades don’t wipe out your changes.

# HOW TO USE THIS FILE
#
# vars.example contains built-in examples to Easy-RSA settings. You MUST name
# this file ‘vars’ if you want it to be used as a configuration file. If you do
# not, it WILL NOT be automatically read when you call easyrsa commands.
#
# It is not necessary to use this config file unless you wish to change
# operational defaults. These defaults should be fine for many uses without the
# need to copy and edit the ‘vars’ file.
#
# All of the editable settings are shown commented and start with the command
# ‘set_var’ – this means any set_var command that is uncommented has been
# modified by the user. If you’re happy with a default, there is no need to
# define the value to its default.

# NOTES FOR WINDOWS USERS
#
# Paths for Windows * MUST * use forward slashes, or optionally double-esscaped
# backslashes (single forward slashes are recommended.) This means your path to
# the openssl binary might look like this:
# “C: / Program Files / OpenSSL-Win32 / bin / openssl.exe”

# A little housekeeping: DON’T EDIT THIS SECTION
#
# Easy-RSA 3.x doesn’t source into the environment directly.
# Complain if a user tries to do this:
if [-z “$ EASYRSA_CALLER”]; then
echo “You appear to be sourcing an Easy-RSA ‘vars’ file.” > & 2
echo «This is no longer necessary and is disallowed. See the section called »> & 2
echo “‘How to use this file’ near the top comments for more details.” > & 2
return 1
fi

# DO YOUR EDITS BELOW THIS POINT

# This variable is used as the base location of configuration files needed by
# easyrsa. More specific variables for specific files (eg, EASYRSA_SSL_CONF)
# may override this default.
#
# The default value of this variable is the location of the easyrsa script
# itself, which is also where the configuration files are located in the
# easy-rsa tree.

#set_var EASYRSA “$ {0% / *}”

# If your OpenSSL command is not in the system PATH, you will need to define the
# path to it here. Normally this means a full path to the executable, otherwise
# you could have left it undefined here and the shown default would be used.
#
# Windows users, remember to use paths with forward-slashes (or escaped
# back-slashes.) Windows users should declare the full path to the openssl
# binary here if it is not in their system PATH.

#set_var EASYRSA_OPENSSL “openssl”
#
# This sample is in Windows syntax – edit it for your path if not using PATH:
#set_var EASYRSA_OPENSSL “C: / Program Files / OpenSSL-Win32 / bin / openssl.exe”

# Edit this variable to point to your soon-to-be-created key directory. By
# default, this will be “$ PWD / pki” (ie the “pki” subdirectory of the
# directory you are currently in).
#
# WARNING: init-pki will do a rm -rf on this directory so make sure you define
# it correctly! (Interactive mode will prompt before acting.)

#set_var EASYRSA_PKI “$ PWD / pki”

# Define X509 DN mode.
# This is used to adjust what elements are included in the Subject field as the DN
# (this is the «Distinguished Name.»)
# Note that in cn_only mode the Organizational fields further below aren’t used.
#
# Choices are:
# cn_only – use just a CN value
# org – use the “traditional” Country / Province / City / Org / OU / email / CN format

#ELEGIMOS cn_only FOR THE CREATION OF CERTIFICATES

set_var EASYRSA_DN “cn_only”

# Organizational fields (used with ‘org’ mode and ignored in ‘cn_only’ mode.)
# These are the default values for fields which will be placed in the
# certificate. Don’t leave any of these fields blank, although interactively
# you may omit any specific field by typing the «.» symbol (not valid for
# email.)

#set_var EASYRSA_REQ_COUNTRY “US”
#set_var EASYRSA_REQ_PROVINCE “California”
#set_var EASYRSA_REQ_CITY “San Francisco”
#set_var EASYRSA_REQ_ORG “Copyleft Certificate Co”
#set_var EASYRSA_REQ_EMAIL “me@example.net”
#set_var EASYRSA_REQ_OU “My Organizational Unit”

# Choose a size in bits for your keypairs. The recommended value is 2048. Using
# 2048-bit keys is considered more than sufficient for many years into the
# future. Larger keysizes will slow down TLS negotiation and make key / DH param
# generation take much longer. Values up to 4096 should be accepted by most
# software. Only used when the crypto alg is rsa (see below.)

#set_var EASYRSA_KEY_SIZE 2048

# The default crypto mode is rsa; ec can enable elliptic curve support.
# Note that not all software supports ECC, so use care when enabling it.
# Choices for crypto alg are: (each in lower-case)
# * rsa
# * ec

# WE CHOOSE ELIPTICAL CURVE FOR THE CREATION OF CERTIFICATES, BY DEFAULT IT IS RSA.

set_var EASYRSA_ALGO ec

# WE DEFINE THE NAME OF THE ELIPTICAL CURVE CHOSEN

set_var EASYRSA_CURVE secp521r1

# WE CONFIGURE THE EXPIRY OF THE AC

set_var EASYRSA_CA_EXPIRE 3650

# WE CONFIGURE THE EXPIRY OF THE CERTIFICATES CREATED.

set_var EASYRSA_CERT_EXPIRE 1080

# How many days until the next CRL publish date? Note that the CRL can still be
# parsed after this timeframe passes. It is only used for an expected next
# publication date.

# How many days before its expiration date a certificate is allowed to be
# renewed?
#set_var EASYRSA_CERT_RENEW 30

#set_var EASYRSA_CRL_DAYS 180

# Support deprecated “Netscape” extensions? (choices “yes” or “no”.) The default
# is “no” to discourage use of deprecated extensions. If you require this
# feature to use with –ns-cert-type, set this to “yes” here. This support
# should be replaced with the more modern –remote-cert-tls feature. If you do
# not use –ns-cert-type in your configs, it is safe (and recommended) to leave
# this defined to “no”. When set to “yes”, server-signed certs get the
# nsCertType = server attribute, and also get any NS_COMMENT defined below in the
# nsComment field.

#set_var EASYRSA_NS_SUPPORT “no”

# When NS_SUPPORT is set to «yes», this field is added as the nsComment field.
# Set this blank to omit it. With NS_SUPPORT set to “no” this field is ignored.

#set_var EASYRSA_NS_COMMENT “Easy-RSA Generated Certificate”

# A temp file used to stage cert extensions during signing. The default should
# be fine for most users; however, some users might want an alternative under a
# RAM-based FS, such as / dev / shm or / tmp on some systems.

#set_var EASYRSA_TEMP_FILE “$ EASYRSA_PKI / extensions.temp”

# !!
# NOTE: ADVANCED OPTIONS BELOW THIS POINT
# PLAY WITH THEM AT YOUR OWN RISK
# !!

# Broken shell command aliases: If you have a largely broken shell that is
# missing any of these POSIX-required commands used by Easy-RSA, you will need
# to define an alias to the proper path for the command. The symptom will be
# some form of a ‘command not found’ error from your shell. This means your
# shell is BROKEN, but you can hack around it here if you really need. estos
# shown values are not defaults: it is up to you to know what you’re doing if
# you touch these.
#
#alias awk = »/ alt / bin / awk»
#alias cat = »/ alt / bin / cat»

# X509 extensions directory:
# If you want to customize the X509 extensions used, set the directory to look
# for extensions here. Each cert type you sign must have a matching filename,
# and an optional file named ‘COMMON’ is included first when present. Note that
# when undefined here, default behavior is to look in $ EASYRSA_PKI first, then
# fallback to $ EASYRSA for the ‘x509-types’ dir. You may override this
# detection with an explicit dir here.
#
#set_var EASYRSA_EXT_DIR “$ EASYRSA / x509-types”

# OpenSSL config file:
# If you need to use a specific openssl config file, you can reference it here.
# Normally this file is auto-detected from a file named openssl-easyrsa.cnf from the
# EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA
# specific and you cannot just use a standard config file, so this is an
# advanced feature.

#set_var EASYRSA_SSL_CONF “$ EASYRSA / openssl-easyrsa.cnf”

# Default CN:
# This is best left alone. Interactively you will set this manually, and BATCH
# callers are expected to set this themselves.

#set_var EASYRSA_REQ_CN “ChangeMe”

# Cryptographic digest to use.
# Do not change this default unless you understand the security implications.
# Valid choices include: md5, sha1, sha256, sha224, sha384, sha512

# WE SELECTED THE HASH SHA512

set_var EASYRSA_DIGEST “sha512”

# Batch mode. Leave this disabled unless you intend to call Easy-RSA explicitly
# in batch mode without any user input, confirmation on dangerous operations,
# or most output. Setting this to any non-blank string enables batch mode.

#set_var EASYRSA_BATCH «»

Once we have modified everything, we save the file since later we are going to use it with these values.

PKI creation: CA, server and client certificates

When we have the «vars» file configured, we proceed to create the Public Key Infrastructure (PKI) with the following command (we assume that you are still in the main Easy-RSA3 directory):

./easyrsa init-pki

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa init-pki

Note: using Easy-RSA configuration from: ./vars

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/bron/EasyRSA-v3.0.6/pki

Once the PKI is initialized, we must create the Certification Authority (CA):

./easyrsa build-ca

Once executed, we must follow the simple CA generation wizard. The password that you ask us is to protect the private key of the CA, something fundamental.

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa build-ca

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
read EC key
writing EC key
Can’t load /home/bron/EasyRSA-v3.0.6/pki/.rnd into RNG
139864421569664: error: 2406F079: random number generator: RAND_load_file: Cannot open file: ../ crypto / rand / randfile.c: 98: Filename = / home / bron / EasyRSA-v3.0.6 / pki / .rnd
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [Easy-RSA CA]: AUTHORITY-CERTIFICATION

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/bron/EasyRSA-v3.0.6/pki/ca.crt

If we do not want to enter a password in the private key of the CA (it is not recommended for security reasons), we must put this command:

./easyrsa build-ca nopass

Once we have created the CA, we must create the server certificate and the client certificates. Next, we must sign it with the CA.

Create the server certificate and sign it with the CA

When creating the server and client certificates, we can give them a password for the private key, however, it is not recommended to do it on the server since every time we start it, it will ask us for the password to use it. If we do not want a password, we will put “nopass” behind each order that you will see below.

./easyrsa gen-req servidor-openvpn-redeszone nopass

The output of the terminal is as follows:

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req server-openvpn-redeszone nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating an EC private key
writing new private key to ‘/home/bron/EasyRSA-v3.0.6/pki/private/server-openvpn-redeszone.key.bHJsAFg0KR’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [server-openvpn-redeszone]:

Keypair and certificate request completed. Your files are:
req: /home/bron/EasyRSA-v3.0.6/pki/reqs/server-openvpn-redeszone.req
key: /home/bron/EasyRSA-v3.0.6/pki/private/servidor-openvpn-redeszone.key

Once the certificate is created, we must sign it with the CA in “server” mode:

./easyrsa sign-req server servidor-openvpn-redeszone

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa sign-req server server-openvpn-redeszone

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject =
commonName = server-openvpn-redeszone

Type the word ‘yes’ to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
commonName: ASN.1 12: ‘server-openvpn-redeszone’
Certificate is to be certified until Dec 23 11:40:22 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/bron/EasyRSA-v3.0.6/pki/issued/servidor-openvpn-redeszone.crt

And we have already created the .crt that we will use later in the OpenVPN configuration file.

Create client certificates and sign them with the CA

The steps that you will see below, we will have to perform once FOR EACH CLIENT that we are going to create. That is, if we are going to create 2 clients, we must follow the steps of creating and signing twice. In this part, it is advisable to create the client’s certificates with a password, so we can be sure that if we lose the certificate, no one can use it. We are not going to introduce any password in the manual (we will put nopass at the end).

./easyrsa gen-req cliente1-openvpn-redeszone nopass

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa gen-req client1-openvpn-redeszone nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating an EC private key
writing new private key to ‘/home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key.YflrPvFgdV’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, The field will be left blank.
—–
Common Name (eg: your user, host, or server name) [client1-openvpn-redeszone]:

Keypair and certificate request completed. Your files are:
req: /home/bron/EasyRSA-v3.0.6/pki/reqs/cliente1-openvpn-redeszone.req
key: /home/bron/EasyRSA-v3.0.6/pki/private/cliente1-openvpn-redeszone.key

Once created, we must sign it:

./easyrsa sign-req client cliente1-openvpn-redeszone

root @ debian-vm: /home/bron/EasyRSA-v3.0.6# ./easyrsa sign-req client client1-openvpn-redeszone

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a client certificate for 1080 days:

subject =
commonName = client1-openvpn-redeszone

Type the word ‘yes’ to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/bron/EasyRSA-v3.0.6/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/bron/EasyRSA-v3.0.6/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
commonName: ASN.1 12: ‘client1-openvpn-redeszone’
Certificate is to be certified until Dec 23 11:41:36 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/bron/EasyRSA-v3.0.6/pki/issued/cliente1-openvpn-redeszone.crt

If we wanted to create and sign a certificate number 2 for another client, we should put something like this:

./easyrsa gen-req cliente2-openvpn-redeszone nopass ./easyrsa sign-req client cliente2-openvpn-redeszone

Remember that if you want to put a password, we must remove the “nopass”.

Organize the server and client .crt and .key certificates

Something very important is to organize the server and client certificates by folders. The server and client certificates are in the path “/ pki / issued /” and the private keys are in “/ pki / private”, the ca.crt is in the root of the “pki” folder. We must create three folders with the following content (for now):

• server: ca.crt, server-openvpn-redeszone.crt, server-openvpn-redeszone.key
• client1: ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key
• client2: ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key

Create the Diffie-Hellmann parameters and the key tls-crypt (tls-auth on older systems)

Once we have the certificates created and signed, formerly we had to create the Diffie-Hellmann parameters to place them in the “server” folder, to generate them we used “./easyrsa gen-dh” but when using ECDHE it is not necessary to create or indicate it neither in the server configuration file. What we must create is the tls-crypt key with the name ta.key or whatever we want. The order that we must put is the following:

openvpn --genkey --secret ta.key

This key ta.key must be placed on the server and on ALL clients.

Once we get here, our folders with the certificates should have the following:

• server: ca.crt, server-openvpn-redeszone.crt, server-openvpn-redeszone.key, dh.pem (Diffie-Hellmann, OPTIONAL because we won’t use it with ECDHE), ta.key (tls-crypt)
• client1: ca.crt, client1-openvpn-redeszone.crt, client1-openvpn-redeszone.key, ta.key (tls-crypt)
• client2: ca.crt, client2-openvpn-redeszone.crt, client2-openvpn-redeszone.key, ta.key (tls-crypt)

If we are going to use tls-auth instead of tls-crypt (because it is not supported, for example), we must take this into account:

In the server configuration (server.conf or server.ovpn) we must put:

tls-auth ta.key 0 (0 from Incoming)

In the client configuration (client.conf or client.ovpn) we must put:

tls-auth ta.key 1 (1 from Outgoing)

Next, we put a table of what each certificate is (names vary).

When we have everything organized in folders, now is when we must create the configuration file (.conf for Linux systems and .ovpn for Windows systems). There are examples of the configuration files on the official OpenVPN website , and also in the path “/ usr / share / doc / openvpn / examples / examples-config-files /”.

The first thing we have to verify is if our server and clients support symmetric ciphers, tls-ciphersuites (TLS 1.3) and tls-cipher (TLS 1.2) and the configured elliptical curves. We must take it into account, since otherwise it will give us an error. To carry out these verifications we must execute:

• openvpn –show-ciphers
• openvpn –show-tls (it will show us whether it supports TLS 1.3 and which ones, like TLS 1.2)
• openvpn –show-curves

Configure the OpenVPN server and start it

The configuration of the OpenVPN server is essential to give access permissions to clients to our local network, configure the TLS negotiation. Because we have hundreds of configurations available, we are going to put our configuration with some comments explaining each parameter, you can copy and paste the configuration without problems. Remember that for Linux it must have a .conf extension and for Windows .ovpn.

#PORT TO BE USED BY TCP OR UDP, BY DEFAULT IS 1194.
#PROTOCOL TO USE TCP OR UDP
#TUNNELING MODE
port 11949
proto udp
dev tun

#CERTIFICATES
#IF WE HAVE THE .CONF IN THE SAME FOLDER, THERE IS NO MISSING TO METER ROUTE, ONLY THE NAME.
#IF THEY ARE ON ANOTHER ROUTE, WE SHOULD TEST THE ROUTE OF ALL OF THEM

ca ca.crt
cert server-openvpn-redeszone.crt
key server-openvpn-redeszone.key
#dh dh.pem (OPTIONAL BECAUSE WE USE ECDHE)
dh none
tls-crypt ta.key

# WE CHECK CUSTOMERS ‘CERTIFICATES (GREATER SECURITY)
remote-cert-tls client

# WE MODIFY THE SYMMETRIC ENCRYPTION OF THE DATA CHANNEL, THE TLS CONTROL CHANNEL AND THE ALGORITHM TO VERIFY THE INTEGRITY.
#IF WE USE AES-256-GCM IT IS NOT NECESSARY TO PUT THE AUTH DIRECTIVE SINCE IT IS NOT USED.

cipher AES-256-GCM
tls-ciphersuites TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
ecdh-curve secp521r1
tls-version-min 1.2
reneg-sec 0
auth SHA512

# NETWORK TOPOLOGY (SUBNET RECOMMENDED) AND VIRTUAL SUBNET WHERE THE CLIENTS WILL BE.

subnet topology
server 10.8.0.0 255.255.255.0

# WE CONFIGURE THE SERVER SO THAT THE CLIENTS HAVE THE SAME IP ALWAYS, ONCE THEY CONNECT.
ifconfig-pool-persist ipp.txt

# WE PROVIDE THE CUSTOMER ACCESS TO THE HOME NETWORK, WE PERFORM INTERNET REDIRECTION AND PROVIDE OPENDNS DNS. WordPress automatically puts these symbols << and >> when it should just put double quotes: »
push “route 192.168.2.0 255.255.255.0”
push “redirect-gateway def1”
push “dhcp-option DNS 208.67.222.222”
push “dhcp-option DNS 208.67.220.220”

# WE ENABLE COMMUNICATION BETWEEN CLIENTS, WE ENABLE KEEPALIVE TO KNOW IF THE TUNNEL HAS DROPPED, WE ENABLE COMPRESSION AND A MAXIMUM OF 100 CLIENTS SIMULTANEOUSLY
client-to-client
keepalive 10 120
max-clients 100

#NO USER PERMISSIONS IN OPENVPN, FOR SERVER SECURITY
user nobody
group nogroup

#KEY AND PERSISTENT TUNNEL
persist-key
persist-tun

# THE SERVER LOGS IN THAT FILE, CONFIGURATION VERB 3 FOR THE LOGS.
status openvpn-status.log
verb 3
explicit-exit-notify 1

So far we have arrived with the configuration of the server, to start it we will simply have to put “openvpn server.conf” in Linux systems and it will start automatically, at the end of the boot you must put “Initialization Sequence Completed”.

Configure the client (or clients)

Next, you can see the client configuration associated with the server that we have seen previously. The only difference between the different clients.conf is the path of the certificates, for example. Very important that the cipher, tls-cipher and other parameters are exactly the same, otherwise it will not connect to the server. Remember that for Linux it must have a .conf extension and for Windows .ovpn.

# WE CONFIGURE IN THE CLIENT MODE, TUN MODE, UDP PROTOCOL.

client
dev tun
proto udp

#THIS DIRECTIVE IS THE CONNECTION WITH THE PUBLIC IP OR DOMAIN OF THE OPENVPN SERVER, WE ALSO HAVE TO PUT THE SAME SERVER PORT
remote 127.0.0.1 11949

# CONTINUOUSLY RESOLVE THE IP OR DOMAIN TO CONNECT US, KEY AND PERSISTENT TUN AS THE SERVER.
resolv-retry infinite
nobind
persist-key
persist-tun

#RUTA DE LA CA, CLIENT CERTIFICATES AND TA.KEY.
#IF WE HAVE IT IN THE SAME FOLDER, IT IS NOT NECESSARY TO PUT THE ENTIRE ROUTE.
ca ca.crt
cert client1-openvpn-redeszone.crt
key client1-openvpn-redeszone.key
tls-crypt ta.key

#CHECK THE SERVER IDENTITY, USE GCM SYMMETRIC ENCRYPTION, TLS 1.2 AND AUTH CONFIGURATION. If our client does not support TLS 1.3.
remote-cert-tls server
cipher AES-256-GCM
auth SHA512

compress

#If our client supports TLS 1.3, we add this directive:
# tls-ciphersuites TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256

#If our client supports TLS 1.2 only, we add this directive:
# tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384: TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256

# ENABLE VERBOSE LEVEL 3 LOG

verb 3

If you use Windows, the folder of the certificates with the configuration file in the extension .ovpn must be in the default OpenVPN path, which is C: UsersBronOpenVPNconfig by default, although we can change it. Once this is done, if we right click on OpenVPN in the lower right bar we will see the name of the client file to connect successfully. At the end of the boot you must put “Initialization Sequence Completed” and we will have successfully connected to the configured OpenVPN server.

Create static route in our router

In order to have connectivity with the local network of our home, it is necessary to create a static route in our home router. With the configuration of 10.8.0.0/24 that we have configured in the OpenVPN server, we must create a static route with this information:

• Subnet IP: 10.8.0.0
• Mask: 255.255.255.0
• Gateway: local IP where we start the OpenVPN server, if for example we have installed on a Raspberry PI with IP 192.168.1.100, we must put this IP.

Main problems and connection failures when connecting

When we first set up an OpenVPN server, we may have different problems connecting the different clients. Before listing the different problems and connection failures that may appear, we must tell you that if you have followed the tutorial step by step, you should not have any errors when connecting, since we have checked the configuration in detail. The configuration of both the server and the clients is in “verb 3”, that is, a recommended registration level for all users, in case of having a connection problem, if we do not find the failure we will have to increase the registration level , and put “verb 5” to have more details of everything that happens in the connection.

RESOLVE: Cannot resolve host address: xxxx.no-ip.org:11949 (Unknown host.)

This error is because the OpenVPN server cannot be found, we must check that the domain that we put is correct, this error is because it cannot find any public IP associated with that domain. The most common is that we have put the domain wrong in the VPN client, that the domain that we have entered does not exist because we have not created it yet, or because the dynamic DNS service is not working correctly.

Could not determine IPv4 / IPv6 protocol

This error is related to the previous one, we have entered a domain that it is not able to find, either using the IPv4 protocol or the IPv6 protocol.

SIGUSR1 [soft, init_instance] received, process restarting

This warning tells us that the connection process with the VPN server is going to be restarted, it simply indicates that there has been an error previously and that it is going to try the connection again.

MANAGEMENT:> STATE: 1603127258, WAIT ,,,,,,

Although this is not an error itself, if the OpenVPN client continually stays in this section of the connection, it is because we do not have any open ports on our router or firewall to the VPN server, depending on whether we have used TCP or UDP, and of the selected port, we must open one port or another. This is because the client is able to locate the IP address without problems, but it waits for a response from the OpenVPN server, a response that will never arrive.

This error also usually happens when we do not have the VPN server started, if we have forgotten to start it at the beginning, we will have this problem. The solution is to start it up and wait for the first clients to appear.

NOTE: –user option is not implemented on Windows

In Windows operating systems we do not need to put the “user nobody” directive, something that in Linux-based operating systems it is advisable to put it.

NOTE: –group option is not implemented on Windows

In Windows operating systems we do not need to put the “group nogroup” directive, something that in Linux-based operating systems it is advisable to put it.

WARNING: Ignoring option ‘dh’ in tls-client mode, please only include this in your server configuration

In the VPN client we do not have to put anything related to Diffie-Hellmann, this directive is only in the server configuration file, in the client it is simply unnecessary.

tls-crypt unwrap error: packet authentication failed and TLS Error: tls-crypt unwrapping failed from [AF_INET]

Authentication with the tls-crypt directive has failed, this is usually because the content of the ta.key file on the server and the clients is different. We must remember that the ta.key must be exactly the same both on the server and on all the VPN clients that we are going to use.

TLS Error: Unroutable control packet received from [AF_INET] and TLS Error: local / remote TLS keys are out of sync

The TLS keys that we have used are not correct on the server and / or client, it is necessary to check the configuration of the certificates and also the ta.key. This error occurs especially when we have the ta.key incorrectly configured.

TLS Error: Unroutable control packet received from

This is a general error of the TLS connection, you may have wrongly copied the CA, the server certificate (in the server settings), the client certificate (in the client settings). This error is due to a failure when copying the different certificates.

WARNING: ‘link-mtu’ is used inconsistently, local = ‘link-mtu 1549 ′, remote =’ link-mtu 1550 ′

This error appears because it is necessary that the MTU is the same both in local (client) and also in remote (VPN server), if the MTU is incorrectly configured, the connection will be established, but we will have a very low performance, and it is possible that the VPN connection is cut at any time.

This error also occurs when we have activated data compression on the VPN server, and we do not have it configured on the client. It also happens when we have different compression algorithm on server / clients. It is necessary for the server and the clients to use the same compression, or not to use compression, which is the most recommended for security.

To solve this error, just put the directive: «compress» on the client, so that it accepts the compression sent by the server through the «PUSH» it performs.

WARNING: ‘comp-lzo’ is present in remote config but missing in local config, remote = ‘comp-lzo’

This error occurs when on the VPN server we have activated data compression with comp-lzo, and on the clients we have no compression at all. It is necessary that both the server and the clients have exactly the same compression algorithm. To solve this error, just put the directive: «compress» on the client, so that it accepts the compression sent by the server through the «PUSH» it performs.

The error “write to TUN / TAP: Unknown error (code = 122)” may also appear due to this compression feature.

TLS Error: TLS handshake failed

An error occurred when negotiating the information on the control channel, it is possible that we have different tls-cipher or tls-ciphersuites and there is no common control channel algorithm, this causes the “handshake” to fail and cannot continue.

Updates and news in the new versions of OpenVPN

OpenVPN does not stop updating and releasing new versions with bug fixes, performance improvements and also security improvements, with the ultimate goal that VPN connections are as secure as possible. Next, we are going to explain some of the improvements that OpenVPN 2.5 will have that will come very soon, since it is in the “Release Candidate” phase.

Tls-crypt-v2 is added

tls-crypt is a functionality that allows us to mitigate DoS and DDoS attacks on OpenVPN servers, thanks to these keys that we create directly in OpenVPN, we will be able to make each client pre-authenticate, to later enter the authentication phase with their client certificate. The first version tls-crypt requires that both the server and all clients have the exact same tls-crypt key. With tls-crypt-v2 we can make each client have their own tls-crypt key, in this way, very large organizations or OpenVPN providers can adequately protect their servers by creating several of these keys.

ChaCha20-Poly1305 encryption support

Currently the most secure symmetric encryption that can be used on the data channel is AES-256-GCM and AES-128-GCM. With the latest version of OpenVPN 2.5 we will also have the possibility to choose the popular ChaCha20-Poly1305 encryption that uses VPN like WireGuard.

Enhanced encryption negotiation on the data channel

Closely related to the previous point, we have that in the new version of OpenVPN 2.5, the ncp-ciphers option has been renamed to data-ciphers, although the old name will continue to be accepted. The change is in order to avoid the ambiguity of “–cipher” and “–tls-cipher”. Now the VPN clients will tell the server what type of ciphers it supports, and the server will choose the first common cipher from the list of supported data ciphers, instead of using the first one on the list, which will make the VPN establishment be faster. This also allows us that if the server has the configuration of “data-ciphers” ChaCha20-Poly1305: AES-256-GCM, and the client has ChaCha20-Poly1305, it will use it because the client supports it.

Support for BF-CBC is removed in default settings

Now the default OpenVPN configuration will not allow using BF-CBC, the latest version will only accept AES-256-GCM and AES-128-GCM ciphers for the data channel. We must remember that in OpenVPN we have BG-CBC when we do not have the option of –cipher or –ncp-ciphers in the configuration. If you want to use this type of encryption, you will need to explicitly enable it.

We hope this manual has been helpful to you. If you have any questions you can comment, we recommend you visit the official OpenVPN HOWTO where you will find all the information about the different parameters to use. The MAN PAGE of OpenVPN 2.4 where you have all the parameters available is also very helpful.