Read udpv6 unknown error code 10054

---

---

---

---

---

---

---

---

OpenVPN greatly improves your online privacy. Often, OpenVPN clients do not work correctly and show up connection errors too.

One such error is “OpenVPN error 10054“. Unfortunately, it happens when the OpenVPN server connection gets a reset.

At Bobcares, we solve OpenVPN connection errors for our customers as part of our Managed VPN Services.

Today, we’ll see how our Support Engineers diagnose and fix “OpenVPN error 10054”.

What causes “OpenVPN error 10054”?

OpenVPN works on a client-server model. In simple words, the OpenVPN client initiates a connection to the OpenVPN server. Further, all communication happens via this channel. That’s how OpenVPN take care of the privacy of user data.

At times, when this connection is reset, it shows the error:

Jan 23 17:41:39 2019 read UDP: Unknown error (code=10054)
Jan 23 17:42:10 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 23 17:42:10 2019 TLS Error: TLS handshake failed

This errors shows that the UDP packets could not make it to the OpenVPN server.

Now, let’s see the top reasons that can cause this connection reset error.

1. Wrong firewall settings

Primarily, VPN connection reset can happen due to the wrong Firewall settings on the computer that runs the OpenVPN client. As the firewall blocks the connection, the data packets do not even reach the server.

Sometimes, even the firewall at the Internet Service Provider (ISP) also can cause OpenVPN error.

Recently, when a customer reported problems with OpenVPN error 10054, it was the ISP firewall affecting the connection. Here, the ISP router was assigning all the devices the same public IP address, which created conflict.

2. Wrong port forwarding

Whenever VPN uses Network Address Translation aka NAT firewall,  then there is a need for remote port forwarding. Here, port forwarding forwards all incoming connections with a matching port number to the internal computer with specific address.

However, when there are wrong port forwarding rules set in the OpenVPN server, it can again result in “OpenVPN error 10054.”

How we fix “OpenVPN error 10054”

We just saw the typical causes for the error. Now, let’s take a look on how our Support Engineers fix the OpenVPN connection.

1. Check server connection

Firstly, we check the connection from the home computer to the OpenVPN server. For this, we use the telnet command in the format

telnet  

If the connection do not work properly, we then check on the server side to see if there are connections reaching the OpenVPN server from this particular client.

2. Disabling firewall

If connections are not even reaching the server, obviously the client computer firewall will have a role in it. To isolate this firewall dependency, our Dedicated Engineers suggest customers to completely turn off firewall and repeat the telnet check. For example, in case of Windows customers, we ask them to disable Windows Firewall completely and try connecting.

Again, if there are further error messages, it means there is something beyond the computer firewall.

3. Edit port forwarding rules

At this point, we check the port forwarding rules in the OpenVPN server. We look for typos in the rules and fix them. That solves the OpenVPN error 10054, and make OpenVPN work fine.

[Are you getting “OpenVPN error 10054“? Our VPN experts can easily fix it for you.]

Conclusion

In short, OpenVPN error 10054 happens mainly due to firewall settings or wrong port forwarding rules in the OpenVPN server. Today, we saw the typical reasons for the error and how our Support Engineers restore VPN connectivity.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

OpenVPN Support Forum

Community Support Forum

Working until yesterday, now Unknown error (code = 10054)

Working until yesterday, now Unknown error (code = 10054)

Post by vitangelo » Mon Feb 26, 2018 11:44 am

Hi,
I have already installed an openvpn server on a raspberry pi 2 from a month, which I access from 4 clients, and that worked well until yesterday.
but today it always gives me error read UDP: Unknown error (code = 10054), I tried both connecting from the internet, and in local with local ip, and both from windows pc and from android, but nothing, always give me error code 10054, what can I verify, or what could have happened?
The connection with the raspberry works correctly, I have also done an apt-get update, but it has not solved.

dev tun
dev tun
proto udp
port 1194

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 10.7.0.0 255.255.255.0
#ifconfig-pool-persist /etc/openvpn/easy-rsa/ipp.txt

push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»
log-append /var/log/openvpn

persist-key
persist-tun
user nobody
proto udp
port 1194

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 10.7.0.0 255.255.255.0
#ifconfig-pool-persist /etc/openvpn/easy-rsa/ipp.txt

push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»
log-append /var/log/openvpn

Источник

Error when connect : read UDP: Unknown error (code=10054) #223

I got those message when I’m trying to connect on my VPN (host in a VPS with the autoscript)
And I don’t really find anything on google

Thu Feb 22 20:53:02 2018 SIGUSR1[soft,tls-error] received, process restarting Thu Feb 22 20:53:02 2018 MANAGEMENT: >STATE:1519329182,RECONNECTING,tls-error. Thu Feb 22 20:53:02 2018 Restart pause, 40 second(s) Thu Feb 22 20:53:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]5.135.102.7:1194 Thu Feb 22 20:53:42 2018 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Feb 22 20:53:42 2018 UDP link local: (not bound) Thu Feb 22 20:53:42 2018 UDP link remote: [AF_INET]XX.XX.XX.XX:1194 Thu Feb 22 20:53:42 2018 MANAGEMENT: >STATE:1519329222,WAIT. Thu Feb 22 20:53:42 2018 read UDP: Unknown error (code=10054) Thu Feb 22 20:53:44 2018 read UDP: Unknown error (code=10054) Thu Feb 22 20:53:48 2018 read UDP: Unknown error (code=10054)

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

On windows, socket error 10054 means connection reset (as per msdn). Could be a temporary issue with your server. If the server is working fine (i.e other clients can connect and stay on), and the problem is persistent, then open a ticket in openvpn trac with any relevant info (OS, openvpn version and server/client configs etc.).

I’m having this issue too:

Winsocks error 10065 is host unreachable (in this case the direct link to the VPN server) which could happen if you lost the default route or the vpn network conflicts with your LAN IP etc.

Please post a verb = 4 log. To get such a log add «verb 4» (without quotes) to the config file and reconnect. The log file may be opened using the view log menu of the GUI. Also include the output of «ifconfig /all» and «route print» run from a command prompt.

Источник

OpenVPN Support Forum

Community Support Forum

Not stable connection with Windows IPEnableRouter

Not stable connection with Windows IPEnableRouter

Post by mazurep » Wed Feb 06, 2019 9:19 pm

Hi
I installed OpenVPN server on Windows machine (tested server installation on Windows 7 and Windows 2012R2 two different internet connections with the same issue).
Till IPEnableRouter in Windows registry is 0 connection to VPN server is stable. When I enable IPEnableRouter in registry connection becomes unstable as below.
Reply from 10.135.136.1: bytes=32 time=73ms TTL=128
Reply from 10.135.136.1: bytes=32 time=66ms TTL=128
Reply from 10.135.136.1: bytes=32 time=75ms TTL=128
Request timed out.
Reply from 10.135.136.1: bytes=32 time=3300ms TTL=128
Reply from 10.135.136.1: bytes=32 time=64ms TTL=128
Reply from 10.135.136.1: bytes=32 time=67ms TTL=128
Request timed out.
Reply from 10.135.136.1: bytes=32 time=3816ms TTL=128
Reply from 10.135.136.1: bytes=32 time=70ms TTL=128
Reply from 10.135.136.1: bytes=32 time=104ms TTL=128
Request timed out.
Reply from 10.135.136.1: bytes=32 time=3309ms TTL=128
Reply from 10.135.136.1: bytes=32 time=65ms TTL=128
Reply from 10.135.136.1: bytes=32 time=59ms TTL=128

Already tried decrease MTU on both ends, use mssfix, disable Windows firewall, enable compression, change cipher with no changes.
Below server config

port 1194
proto udp
dev tun
ca «C:\OpenVPN\config\ca.crt»
cert «C:\OpenVPN\config\server.crt»
key «C:\OpenVPN\config\server.key»
dh «C:\OpenVPN\config\dh2048.pem»
server 10.135.136.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push «route 192.168.1.0 255.255.255.0»
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-GCM
comp-lzo
persist-key
persist-tun
verb 3
mssfix 1450

client
dev tun
proto udp
remote xx.xx.xx.xx 1194
nobind
persist-key
persist-tun
mute-replay-warnings
ca ca.crt
cert pawelpc2.crt
key pawelpc2.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-GCM
comp-lzo
verb 7
tls-client
mssfix 1450

OpenVPN Windows package version 2.4.6
Any chance to take a look what I’m doing wrong ?
Thanks a lot
Pawel

Источник

Read udpv6 unknown error code 10054

Open VPN uncommonly chips away at your electronic cover. Oftentimes, Open VPN clients don’t work successfully and show up connection errors also. This Windows error message suggests the connection was reset. which probably implies you need either port sent viably or firewall planned exactly.

One such error is Open VPN error 10054. “Read UDP: Unknown Error (Code=10054)” happens when the OpenVPN server connection gets reset. Around here at ARZHOST , we address Open VPN connection errors for our customers as a part of our Managed VPN Services.

Today will see how our Hosting Expert Planners examine and fix OpenVPN error 10054.

Table of Contents

What causes Open VPN error 10054?

OpenVPN manages a client-server model. In essential words, the OpenVPN client begins a relationship with the OpenVPN server. “ Read UDP: Unknown Error (Code=10054) ”, Further, all correspondence occurs through this channel. That is how OpenVPN manages the security of customer data.

Occasionally, when this connection is reset, it shows the slip-up:

• ##Jan 23 17:41:39 2019 read UDP: Unknown mix-up (code=10054)
• Jan 23 17:42:10 2019 TLS Error: TLS key trade fail to occur inside 60 seconds (truly investigate your association accessibility)
• #Jan 23 17:42:10 2019 TLS Error: TLS handshake failed

This slip-up shows that the UDP bundles couldn’t go to the Open VPN server.

As of now, “Read UDP: Unknown Error (Code=10054)”, let’s see the top reasons that can cause this connection reset error.

1. Wrong firewall settings

VPN connection reset can happen given some unsuitable Firewall settings on the PC that runs the Open VPN client. As the firewall impedes the connection, the data packs don’t show up at the server.

To a great extent, “Read UDP: Unknown Error (Code=10054)”, even the firewall at the Internet Service Provider (ISP) moreover can cause Open VPN error.

Lately, when a customer uncovered issues with Open VPN error 10054, it was the ISP firewall affecting the connection. Here, the ISP switch was giving all of the devices a comparable public IP address, which made conflict.

2. Wrong port sending

Whenever VPN uses Network Address Translation otherwise called NAT firewall, then, there is a requirement for remote port sending. Here, port sending propels all moving toward a relationship with planning with the port number to within PC with the express area.

Regardless, when there are mistaken port sending rules set in the Open VPN server, it can again achieve Open VPN error 10054.

People Also Ask

Question # 1: How do I fix network Socket Error 10054?

Answer: Solution 1. Check Peer Peer connection

1. If the address of the computer or host is correct.
2. The other computer or the host, if it is still on or disabled.
3. Make sure the network between you and the other computer is still up.
4. Check the network configuration of the other computer if it is unreachable.

Question # 2: What port should OpenVPN listen to?

Answer: By default, the OpenVPN Access Server comes configured with OpenVPN daemons that listen on port 1194 UDP, and OpenVPN daemons that listen on port 443 TCP. While the best connection for an OpenVPN tunnel is via the UDP port, we implement TCP 443 as a fallback method.

Read More———-

Question # 3: Does OpenVPN port forward?

Answer: One of the greatest benefits of OVPN is that it allows port forwarding when connected. By forwarding a port, you can, for example, run a web server on your device even though that device is connected to OVPN.

Question # 4: Where is the OpenVPN client config file?

Answer: 4. x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192.168. 4.4. Open up the server’s firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).

Question # 5: What is a socket error on the Internet speed test?

Answer: As it turns out, the ‘socket error’ when running an Internet speed test with your browser can be caused by your firewall – even if you’re using the built-in firewall (Windows Firewall). This scenario is most encountered on a Wi-Fi connection. Press Windows key + R to open up a Run dialog box. Next, type ‘firewall.

How do we fix Open VPN error 10054?

We just saw the ordinary purposes behind the error. As of now, “Read UDP: Unknown Error (Code=10054)”, let’s research how our Hosting Expert Planners fix the OpenVPN connection.

1. All things considered investigate server connection

First thing, we investigate the relationship between the home PC to the OpenVPN server. For this, we use the telnet request in the association

Accepting the connection doesn’t fill in true to form. “Read UDP: Unknown Error (Code=10054)”, We then, mind the server side to check whether connections are showing up at the Open VPN server from this particular client.

2. Shocking firewall

On the off chance that connections are on no occasion, showing up at the server the client PC firewall will have an impact on it. To disengage this firewall dependence, our Dedicated Engineers prescribe customers to slow down the firewall and repeat the telnet check. For example, in the case of Windows customers, we demand that they cripple Windows Firewall absolutely and have a go at interfacing.

Again, if there are further screw-up messages, “Read UDP: Unknown Error (Code=10054)”, it suggests there is something past the PC firewall.

3. Adjust port sending rules

Presently, we check the port sending rules in the Open VPN server. We look for language errors in the rules and fix them. “Read UDP: Unknown Error (Code=10054)”, handles the Open VPN error 10054, and makes Open VPN end up extraordinary.

Conclusion

To lay it out simply, Open VPN error 10054 happens mainly due to firewall settings or wrong port sending rules in the Open VPN server. Today, “Read UDP: Unknown Error (Code=10054)”, we saw the normal clarifications behind the mistake and how our Hosting Expert Planners restore VPN openness.

Источник

OpenVPN Support Forum

Community Support Forum

TLS Error: TLS key negotiation failed — read UDP: Unknown error (code=10054)

TLS Error: TLS key negotiation failed — read UDP: Unknown error (code=10054)

Post by net.admin » Wed Oct 04, 2017 12:17 pm

This is my first non point to point openvpn and it’s doing my head in.

I’m using Win7 as the server, and Win10 as a client. This is a proof of concept test environment. N0 router or firewall (software or hardware) is in use. The client lives on the same subnet as the server and can ping it. The server address of 192.11.5.199 is the actual Win7 server address. Client machine is currently on 192.11.5.x.

In the below log I see two errors, the «unknown 10054» and the tls. I’m presuming one is causing the other, but that’s somewhat a guess also.

If someone could kindly take a look I’d appreciate a nudge in the right direction. I’m guessing I’ve missed something but I’m damned if I can see what.

client
dev tun
proto udp
remote 192.11.5.199 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca «C:\Program Files\OpenVPN\config\ca.crt»
cert «C:\Program Files\OpenVPN\config\markg.crt»
key «C:\Program Files\OpenVPN\config\markg.key»

tls-auth «C:\Program Files\OpenVPN\config\ta.key» 1

#################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# «C:\Program Files\OpenVPN\config\foo.key» #
# #
# Comments are preceded with ‘#’ or ‘;’ #
#################################################

# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
;proto tcp
proto udp

# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don’t need this.
;dev-node MyTap

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).

ca «C:\Program Files\OpenVPN\config\ca.crt»
cert «C:\Program Files\OpenVPN\config\server.crt»
key «C:\Program Files\OpenVPN\config\server.key»

# This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh «C:\Program Files\OpenVPN\config\dh4096.pem»

# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
;topology subnet

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0

# Maintain a record of client virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

# Configure server mode for ethernet bridging.
# You must first use your OS’s bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0. Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses. You must first use
# your OS’s bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
;server-bridge

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push «route 192.168.10.0 255.255.255.0»
;push «route 192.168.20.0 255.255.255.0»

# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory «ccd» for client-specific
# configuration files (see man page for more info).

# EXAMPLE: Suppose the client
# having the certificate common name «Thelonious»
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious’ private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using «dev tun» and «server» directives.

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2

# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push «redirect-gateway def1 bypass-dhcp»

# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push «dhcp-option DNS 208.67.222.222»
;push «dhcp-option DNS 208.67.220.220»

# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
;client-to-client

# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE «COMMON NAME»,
# UNCOMMENT THIS LINE OUT.
;duplicate-cn

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
tls-auth «C:\Program Files\OpenVPN\ta.key» 0
# This file is secret

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC

# Enable compression on the VPN link and push the
# option to the client (v2.4+ only, for earlier
# versions see below)
;compress lz4-v2
;push «compress lz4-v2»

# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo

# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100

# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 6

# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1

Источник

I want to set up an OpenVPN Server on a CentOS 7 server. From my ISP, I only have public IPv6 address, the IPv4 is NAT-ed at the ISP, so I decided to configure my VPN to be based on IPv6.

I followed this tutorial, which means I used the downloaded script to set things up for me with IPv4, then alter the config to be IPv6 compatible. The result is:

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.10.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem

log-append /var/log/openvpn.log

server-ipv6 2001:db8:0:123::/64
tun-ipv6
push tun-ipv6
ifconfig-ipv6 2001:db8:0:123::1 2001:db8:0:123::2
push "route-ipv6 2001:db8:0:abc::/64"
push "route-ipv6 2000::/3"

The server started up successfully, so I downloaded the client.ovpn file on the client, but I get Thu Jan 10 23:53:23 2019 read UDP: Unknown error (code=10054), which should mean that it failed to connect to the host, but I’m already connected to the target machine with SSH. I also have the port 1194 open on the firewall.

server log:

Thu Jan 10 22:55:02 2019 us=932367 event_wait : Interrupted system call (code=4)
Thu Jan 10 22:55:02 2019 us=933688 TCP/UDP: Closing socket
Thu Jan 10 22:55:02 2019 us=933822 Closing TUN/TAP interface
Thu Jan 10 22:55:02 2019 us=933907 /sbin/ip addr del dev tun0 10.8.0.1/24
RTNETLINK answers: Operation not permitted
Thu Jan 10 22:55:02 2019 us=943788 Linux ip addr del failed: external program exited with error status: 2
Thu Jan 10 22:55:02 2019 us=943944 /sbin/ip -6 addr del 2001:db8:0:123::1/64 dev tun0
RTNETLINK answers: Operation not permitted
Thu Jan 10 22:55:02 2019 us=948530 Linux ip -6 addr del failed: external program exited with error status: 2
Thu Jan 10 22:55:02 2019 us=963888 SIGTERM[hard,] received, process exiting
Thu Jan 10 22:55:03 2019 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Thu Jan 10 22:55:03 2019 us=23634 Current Parameter Settings:
Thu Jan 10 22:55:03 2019 us=23684   config = 'server.conf'
Thu Jan 10 22:55:03 2019 us=23720   mode = 1
Thu Jan 10 22:55:03 2019 us=23754   persist_config = DISABLED
Thu Jan 10 22:55:03 2019 us=23788   persist_mode = 1
Thu Jan 10 22:55:03 2019 us=23822   show_ciphers = DISABLED
Thu Jan 10 22:55:03 2019 us=23855   show_digests = DISABLED
Thu Jan 10 22:55:03 2019 us=23889   show_engines = DISABLED
Thu Jan 10 22:55:03 2019 us=23922   genkey = DISABLED
Thu Jan 10 22:55:03 2019 us=23955   key_pass_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=23989   show_tls_ciphers = DISABLED
Thu Jan 10 22:55:03 2019 us=24022   connect_retry_max = 0
Thu Jan 10 22:55:03 2019 us=24056 Connection profiles [0]:
Thu Jan 10 22:55:03 2019 us=24092   proto = udp
Thu Jan 10 22:55:03 2019 us=24126   local = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=24160   local_port = '1194'
Thu Jan 10 22:55:03 2019 us=24193   remote = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=24227   remote_port = '1194'
Thu Jan 10 22:55:03 2019 us=24279   remote_float = DISABLED
Thu Jan 10 22:55:03 2019 us=24313   bind_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=24346   bind_local = ENABLED
Thu Jan 10 22:55:03 2019 us=24380   bind_ipv6_only = DISABLED
Thu Jan 10 22:55:03 2019 us=24413   connect_retry_seconds = 5
Thu Jan 10 22:55:03 2019 us=24447   connect_timeout = 120
Thu Jan 10 22:55:03 2019 us=24482   socks_proxy_server = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=24515   socks_proxy_port = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=24549   tun_mtu = 1500
Thu Jan 10 22:55:03 2019 us=24583   tun_mtu_defined = ENABLED
Thu Jan 10 22:55:03 2019 us=24616   link_mtu = 1500
Thu Jan 10 22:55:03 2019 us=24650   link_mtu_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=24683   tun_mtu_extra = 0
Thu Jan 10 22:55:03 2019 us=24717   tun_mtu_extra_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=24750   mtu_discover_type = -1
Thu Jan 10 22:55:03 2019 us=24784   fragment = 0
Thu Jan 10 22:55:03 2019 us=24818   mssfix = 1450
Thu Jan 10 22:55:03 2019 us=24854   explicit_exit_notification = 0
Thu Jan 10 22:55:03 2019 us=24887 Connection profiles END
Thu Jan 10 22:55:03 2019 us=24920   remote_random = DISABLED
Thu Jan 10 22:55:03 2019 us=24956   ipchange = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=24990   dev = 'tun'
Thu Jan 10 22:55:03 2019 us=25023   dev_type = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=25057   dev_node = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=25090   lladdr = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=25124   topology = 3
Thu Jan 10 22:55:03 2019 us=25157   ifconfig_local = '10.8.0.1'
Thu Jan 10 22:55:03 2019 us=25193   ifconfig_remote_netmask = '255.255.255.0'
Thu Jan 10 22:55:03 2019 us=25227   ifconfig_noexec = DISABLED
Thu Jan 10 22:55:03 2019 us=25274   ifconfig_nowarn = DISABLED
Thu Jan 10 22:55:03 2019 us=25307   ifconfig_ipv6_local = '2001:db8:0:123::1'
Thu Jan 10 22:55:03 2019 us=25341   ifconfig_ipv6_netbits = 64
Thu Jan 10 22:55:03 2019 us=25377   ifconfig_ipv6_remote = '2001:db8:0:123::2'
Thu Jan 10 22:55:03 2019 us=25411   shaper = 0
Thu Jan 10 22:55:03 2019 us=25445   mtu_test = 0
Thu Jan 10 22:55:03 2019 us=25478   mlock = DISABLED
Thu Jan 10 22:55:03 2019 us=25512   keepalive_ping = 10
Thu Jan 10 22:55:03 2019 us=25547   keepalive_timeout = 120
Thu Jan 10 22:55:03 2019 us=25581   inactivity_timeout = 0
Thu Jan 10 22:55:03 2019 us=25616   ping_send_timeout = 10
Thu Jan 10 22:55:03 2019 us=25650   ping_rec_timeout = 240
Thu Jan 10 22:55:03 2019 us=25685   ping_rec_timeout_action = 2
Thu Jan 10 22:55:03 2019 us=25720   ping_timer_remote = DISABLED
Thu Jan 10 22:55:03 2019 us=25755   remap_sigusr1 = 0
Thu Jan 10 22:55:03 2019 us=25789   persist_tun = ENABLED
Thu Jan 10 22:55:03 2019 us=25825   persist_local_ip = DISABLED
Thu Jan 10 22:55:03 2019 us=25861   persist_remote_ip = DISABLED
Thu Jan 10 22:55:03 2019 us=25894   persist_key = ENABLED
Thu Jan 10 22:55:03 2019 us=25940   passtos = DISABLED
Thu Jan 10 22:55:03 2019 us=25975   resolve_retry_seconds = 1000000000
Thu Jan 10 22:55:03 2019 us=26009   resolve_in_advance = DISABLED
Thu Jan 10 22:55:03 2019 us=26043   username = 'nobody'
Thu Jan 10 22:55:03 2019 us=26078   groupname = 'nobody'
Thu Jan 10 22:55:03 2019 us=26114   chroot_dir = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=26150   cd_dir = '/etc/openvpn/'
Thu Jan 10 22:55:03 2019 us=26183   selinux_context = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=26219   writepid = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=26278   up_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=26313   down_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=26347   down_pre = DISABLED
Thu Jan 10 22:55:03 2019 us=26381   up_restart = DISABLED
Thu Jan 10 22:55:03 2019 us=26415   up_delay = DISABLED
Thu Jan 10 22:55:03 2019 us=26450   daemon = DISABLED
Thu Jan 10 22:55:03 2019 us=26484   inetd = 0
Thu Jan 10 22:55:03 2019 us=26519   log = ENABLED
Thu Jan 10 22:55:03 2019 us=26555   suppress_timestamps = DISABLED
Thu Jan 10 22:55:03 2019 us=26591   machine_readable_output = DISABLED
Thu Jan 10 22:55:03 2019 us=26624   nice = 0
Thu Jan 10 22:55:03 2019 us=26660   verbosity = 4
Thu Jan 10 22:55:03 2019 us=26696   mute = 0
Thu Jan 10 22:55:03 2019 us=26729   gremlin = 0
Thu Jan 10 22:55:03 2019 us=26762   status_file = 'openvpn-status.log'
Thu Jan 10 22:55:03 2019 us=26796   status_file_version = 1
Thu Jan 10 22:55:03 2019 us=26829   status_file_update_freq = 60
Thu Jan 10 22:55:03 2019 us=26863   occ = ENABLED
Thu Jan 10 22:55:03 2019 us=26896   rcvbuf = 0
Thu Jan 10 22:55:03 2019 us=26929   sndbuf = 0
Thu Jan 10 22:55:03 2019 us=26962   mark = 0
Thu Jan 10 22:55:03 2019 us=26996   sockflags = 0
Thu Jan 10 22:55:03 2019 us=27029   fast_io = DISABLED
Thu Jan 10 22:55:03 2019 us=27062   comp.alg = 0
Thu Jan 10 22:55:03 2019 us=27098   comp.flags = 0
Thu Jan 10 22:55:03 2019 us=27132   route_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27166   route_default_gateway = '10.8.0.2'
Thu Jan 10 22:55:03 2019 us=27200   route_default_metric = 0
Thu Jan 10 22:55:03 2019 us=27234   route_noexec = DISABLED
Thu Jan 10 22:55:03 2019 us=27295   route_delay = 0
Thu Jan 10 22:55:03 2019 us=27330   route_delay_window = 30
Thu Jan 10 22:55:03 2019 us=27366   route_delay_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=27402   route_nopull = DISABLED
Thu Jan 10 22:55:03 2019 us=27438   route_gateway_via_dhcp = DISABLED
Thu Jan 10 22:55:03 2019 us=27472   allow_pull_fqdn = DISABLED
Thu Jan 10 22:55:03 2019 us=27507   management_addr = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27544   management_port = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27580   management_user_pass = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27614   management_log_history_cache = 250
Thu Jan 10 22:55:03 2019 us=27651   management_echo_buffer_size = 100
Thu Jan 10 22:55:03 2019 us=27685   management_write_peer_info_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27721   management_client_user = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27755   management_client_group = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27789   management_flags = 0
Thu Jan 10 22:55:03 2019 us=27826   shared_secret_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=27860   key_direction = 0
Thu Jan 10 22:55:03 2019 us=27896   ciphername = 'AES-256-CBC'
Thu Jan 10 22:55:03 2019 us=27930   ncp_enabled = ENABLED
Thu Jan 10 22:55:03 2019 us=27964   ncp_ciphers = 'AES-256-GCM:AES-128-GCM'
Thu Jan 10 22:55:03 2019 us=27998   authname = 'SHA512'
Thu Jan 10 22:55:03 2019 us=28034   prng_hash = 'SHA1'
Thu Jan 10 22:55:03 2019 us=28068   prng_nonce_secret_len = 16
Thu Jan 10 22:55:03 2019 us=28105   keysize = 0
Thu Jan 10 22:55:03 2019 us=28138   engine = DISABLED
Thu Jan 10 22:55:03 2019 us=28174   replay = ENABLED
Thu Jan 10 22:55:03 2019 us=28210   mute_replay_warnings = DISABLED
Thu Jan 10 22:55:03 2019 us=28260   replay_window = 64
Thu Jan 10 22:55:03 2019 us=28332   replay_time = 15
Thu Jan 10 22:55:03 2019 us=28377   packet_id_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=28422   use_iv = ENABLED
Thu Jan 10 22:55:03 2019 us=28476   test_crypto = DISABLED
Thu Jan 10 22:55:03 2019 us=28519   tls_server = ENABLED
Thu Jan 10 22:55:03 2019 us=28561   tls_client = DISABLED
Thu Jan 10 22:55:03 2019 us=28604   key_method = 2
Thu Jan 10 22:55:03 2019 us=28646   ca_file = 'ca.crt'
Thu Jan 10 22:55:03 2019 us=28689   ca_path = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=28731   dh_file = 'dh.pem'
Thu Jan 10 22:55:03 2019 us=28776   cert_file = 'server.crt'
Thu Jan 10 22:55:03 2019 us=28819   extra_certs_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=28864   priv_key_file = 'server.key'
Thu Jan 10 22:55:03 2019 us=28910   pkcs12_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=28952   cipher_list = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=28995   tls_cert_profile = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=29037   tls_verify = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=29080   tls_export_cert = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=29123   verify_x509_type = 0
Thu Jan 10 22:55:03 2019 us=29166   verify_x509_name = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=29208   crl_file = 'crl.pem'
Thu Jan 10 22:55:03 2019 us=29267   ns_cert_type = 0
Thu Jan 10 22:55:03 2019 us=29319   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29362   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29405   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29448   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29491   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29533   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29576   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29619   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29661   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29704   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29747   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29789   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29832   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29875   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29917   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=29960   remote_cert_ku[i] = 0
Thu Jan 10 22:55:03 2019 us=30005   remote_cert_eku = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=30048   ssl_flags = 0
Thu Jan 10 22:55:03 2019 us=30091   tls_timeout = 2
Thu Jan 10 22:55:03 2019 us=30134   renegotiate_bytes = -1
Thu Jan 10 22:55:03 2019 us=30177   renegotiate_packets = 0
Thu Jan 10 22:55:03 2019 us=30220   renegotiate_seconds = 3600
Thu Jan 10 22:55:03 2019 us=30288   handshake_window = 60
Thu Jan 10 22:55:03 2019 us=30332   transition_window = 3600
Thu Jan 10 22:55:03 2019 us=30375   single_session = DISABLED
Thu Jan 10 22:55:03 2019 us=30417   push_peer_info = DISABLED
Thu Jan 10 22:55:03 2019 us=30460   tls_exit = DISABLED
Thu Jan 10 22:55:03 2019 us=30502   tls_auth_file = 'ta.key'
Thu Jan 10 22:55:03 2019 us=30545   tls_crypt_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=30588   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30631   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30673   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30716   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30759   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30801   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30844   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30889   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30931   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=30974   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31016   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31059   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31102   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31144   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31187   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31229   pkcs11_protected_authentication = DISABLED
Thu Jan 10 22:55:03 2019 us=31299   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31344   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31387   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31431   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31474   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31517   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31560   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31603   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31646   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31689   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31733   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31776   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31819   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31862   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31905   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31948   pkcs11_private_mode = 00000000
Thu Jan 10 22:55:03 2019 us=31993   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32035   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32078   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32120   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32163   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32205   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32260   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32309   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32351   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32394   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32437   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32479   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32522   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32565   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32607   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32650   pkcs11_cert_private = DISABLED
Thu Jan 10 22:55:03 2019 us=32703   pkcs11_pin_cache_period = -1
Thu Jan 10 22:55:03 2019 us=32746   pkcs11_id = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=32789   pkcs11_id_management = DISABLED
Thu Jan 10 22:55:03 2019 us=32837   server_network = 10.8.0.0
Thu Jan 10 22:55:03 2019 us=32883   server_netmask = 255.255.255.0
Thu Jan 10 22:55:03 2019 us=32931   server_network_ipv6 = 2001:db8:0:123::
Thu Jan 10 22:55:03 2019 us=32975   server_netbits_ipv6 = 64
Thu Jan 10 22:55:03 2019 us=33021   server_bridge_ip = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=33067   server_bridge_netmask = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=33114   server_bridge_pool_start = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=33160   server_bridge_pool_end = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=33203   push_entry = 'redirect-gateway def1 bypass-dhcp'
Thu Jan 10 22:55:03 2019 us=33258   push_entry = 'dhcp-option DNS 192.168.10.1'
Thu Jan 10 22:55:03 2019 us=33308   push_entry = 'tun-ipv6'
Thu Jan 10 22:55:03 2019 us=33351   push_entry = 'route-ipv6 2001:db8:0:abc::/64'
Thu Jan 10 22:55:03 2019 us=33393   push_entry = 'route-ipv6 2000::/3'
Thu Jan 10 22:55:03 2019 us=33436   push_entry = 'tun-ipv6'
Thu Jan 10 22:55:03 2019 us=33479   push_entry = 'route-gateway 10.8.0.1'
Thu Jan 10 22:55:03 2019 us=33521   push_entry = 'topology subnet'
Thu Jan 10 22:55:03 2019 us=33564   push_entry = 'ping 10'
Thu Jan 10 22:55:03 2019 us=33606   push_entry = 'ping-restart 120'
Thu Jan 10 22:55:03 2019 us=33649   ifconfig_pool_defined = ENABLED
Thu Jan 10 22:55:03 2019 us=33697   ifconfig_pool_start = 10.8.0.2
Thu Jan 10 22:55:03 2019 us=33742   ifconfig_pool_end = 10.8.0.253
Thu Jan 10 22:55:03 2019 us=33787   ifconfig_pool_netmask = 255.255.255.0
Thu Jan 10 22:55:03 2019 us=33830   ifconfig_pool_persist_filename = 'ipp.txt'
Thu Jan 10 22:55:03 2019 us=33873   ifconfig_pool_persist_refresh_freq = 600
Thu Jan 10 22:55:03 2019 us=33919   ifconfig_ipv6_pool_defined = ENABLED
Thu Jan 10 22:55:03 2019 us=33976   ifconfig_ipv6_pool_base = 2001:db8:0:123::1000
Thu Jan 10 22:55:03 2019 us=34020   ifconfig_ipv6_pool_netbits = 64
Thu Jan 10 22:55:03 2019 us=34065   n_bcast_buf = 256
Thu Jan 10 22:55:03 2019 us=34107   tcp_queue_limit = 64
Thu Jan 10 22:55:03 2019 us=34153   real_hash_size = 256
Thu Jan 10 22:55:03 2019 us=34196   virtual_hash_size = 256
Thu Jan 10 22:55:03 2019 us=34255   client_connect_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=34307   learn_address_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=34352   client_disconnect_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=34395   client_config_dir = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=34440   ccd_exclusive = DISABLED
Thu Jan 10 22:55:03 2019 us=34485   tmp_dir = '/tmp'
Thu Jan 10 22:55:03 2019 us=34530   push_ifconfig_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=34577   push_ifconfig_local = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=34622   push_ifconfig_remote_netmask = 0.0.0.0
Thu Jan 10 22:55:03 2019 us=34668   push_ifconfig_ipv6_defined = DISABLED
Thu Jan 10 22:55:03 2019 us=34715   push_ifconfig_ipv6_local = ::/0
Thu Jan 10 22:55:03 2019 us=34760   push_ifconfig_ipv6_remote = ::
Thu Jan 10 22:55:03 2019 us=34802   enable_c2c = DISABLED
Thu Jan 10 22:55:03 2019 us=34845   duplicate_cn = DISABLED
Thu Jan 10 22:55:03 2019 us=34887   cf_max = 0
Thu Jan 10 22:55:03 2019 us=34931   cf_per = 0
Thu Jan 10 22:55:03 2019 us=34974   max_clients = 1024
Thu Jan 10 22:55:03 2019 us=35017   max_routes_per_client = 256
Thu Jan 10 22:55:03 2019 us=35060   auth_user_pass_verify_script = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=35102   auth_user_pass_verify_script_via_file = DISABLED
Thu Jan 10 22:55:03 2019 us=35145   auth_token_generate = DISABLED
Thu Jan 10 22:55:03 2019 us=35188   auth_token_lifetime = 0
Thu Jan 10 22:55:03 2019 us=35231   port_share_host = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=35291   port_share_port = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=35334   client = DISABLED
Thu Jan 10 22:55:03 2019 us=35376   pull = DISABLED
Thu Jan 10 22:55:03 2019 us=35419   auth_user_pass_file = '[UNDEF]'
Thu Jan 10 22:55:03 2019 us=35475 OpenVPN 2.4.6 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 26 2018
Thu Jan 10 22:55:03 2019 us=35542 library versions: OpenSSL 1.0.2k-fips  26 Jan 2017, LZO 2.06
Thu Jan 10 22:55:03 2019 us=40832 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jan 10 22:55:03 2019 us=43372 Diffie-Hellman initialized with 2048 bit key
Thu Jan 10 22:55:03 2019 us=45102 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Jan 10 22:55:03 2019 us=45176 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Jan 10 22:55:03 2019 us=45273 TLS-Auth MTU parms [ L:1621 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Thu Jan 10 22:55:03 2019 us=51203 TUN/TAP device tun0 opened
Thu Jan 10 22:55:03 2019 us=51391 TUN/TAP TX queue length set to 100
Thu Jan 10 22:55:03 2019 us=51480 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Thu Jan 10 22:55:03 2019 us=51564 /sbin/ip link set dev tun0 up mtu 1500
Thu Jan 10 22:55:03 2019 us=57581 /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Thu Jan 10 22:55:03 2019 us=62748 /sbin/ip -6 addr add 2001:db8:0:123::1/64 dev tun0
Thu Jan 10 22:55:03 2019 us=69805 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Thu Jan 10 22:55:03 2019 us=71518 Could not determine IPv4/IPv6 protocol. Using AF_INET
Thu Jan 10 22:55:03 2019 us=71646 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Jan 10 22:55:03 2019 us=71934 UDPv4 link local (bound): [AF_INET][undef]:1194
Thu Jan 10 22:55:03 2019 us=71981 UDPv4 link remote: [AF_UNSPEC]
Thu Jan 10 22:55:03 2019 us=72044 GID set to nobody
Thu Jan 10 22:55:03 2019 us=72105 UID set to nobody
Thu Jan 10 22:55:03 2019 us=72209 MULTI: multi_init called, r=256 v=256
Thu Jan 10 22:55:03 2019 us=72335 IFCONFIG POOL IPv6: (IPv4) size=252, size_ipv6=65536, netbits=64, base_ipv6=2001:db8:0:123::1000
Thu Jan 10 22:55:03 2019 us=72405 IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=1
Thu Jan 10 22:55:03 2019 us=72477 IFCONFIG POOL LIST
Thu Jan 10 22:55:03 2019 us=72676 Initialization Sequence Completed

client log (SO wouldn’t let me paste it in here)

Anyone has any input on how to solve this issue?

Что не так проброшенонастроено?

конфиг сервера

На стороне сервера нет доступа к рутёру, но по моей просьбе пробросили UDP 1194 и 5194

Лог: