[SOLVED] openvpn server "UNDEF" in common name

[octopus]

I have updated my vpnserver with new sha256 HMAC Authentication.
When I connect with generated client1 key I can connect fine.
But when I connect with generated key2 I get "UNDEF" and no connection.
I want to use different keys if it possible.

Have somone have same problem and can shed some light on this?

 

[RMerlin]

UNDEF shows if a client fails to complete its connection - this is intended behaviour by the OpenVPN devs.

 

[octopus]

UNDEF shows if a client fails to complete its connection - this is intended behaviour by the OpenVPN devs.

Yes I know. I have generated all keys at same time with easy-rsa on router, eg octopus-1, octopus-2 with sama CA and only octopus-1 key can connect with same client.config file not with octopus-2 key.

./build-key octopus-1
./build-key octopus-2
You can create as many client keypairs as you need. The CA file will be what determines which keys are allowed to connect.

Next, let's build one client key/certificate pair. Same procedure (and once again pay attention to the Common Name, 
which must match the name you are specifying here instead of client1):

 

[RMerlin]

The System Log will tell you why it's rejecting the client.

 

[octopus]

The System Log will tell you why it's rejecting the client.

I get this in log:

Sat Apr  6 17:48:53 2019 192.168.12.122:61724 TLS: Initial packet from [AF_INET6]::ffff:192.168.12.122:61724, sid=d1df710d 5774cf6a
Sat Apr  6 17:49:53 2019 192.168.12.122:61724 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Apr  6 17:49:53 2019 192.168.12.122:61724 TLS Error: TLS handshake failed
Sat Apr  6 17:49:53 2019 192.168.12.122:61724 SIGUSR1[soft,tls-error] received, client-instance restarting

 

[RMerlin]

Check ciphers, hash and other TLS-related parameters.

Also make sure you test from outside your LAN, the loopback might have trouble dealing with connection requests initiated from inside.

 

[octopus]

Check ciphers, hash and other TLS-related parameters.

Also make sure you test from outside your LAN, the loopback might have trouble dealing with connection requests initiated from inside.

Thank you.....
Problem seems was loopback. Connecting from outside network. It have working before.....
I have "nobind" and should listen on all interface, strange!

Sat Apr 06 20:57:07 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Sat Apr 06 20:57:07 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Apr 06 20:57:07 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Sat Apr 06 20:57:08 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]158.174.xxx.xx:1000
Sat Apr 06 20:57:08 2019 UDP link local: (not bound)
Sat Apr 06 20:57:08 2019 UDP link remote: [AF_INET]158.174.xxx.xx:1000
Sat Apr 06 20:57:08 2019 [octopus] Peer Connection Initiated with [AF_INET]158.174.xxx.xx:1000
Sat Apr 06 20:57:10 2019 open_tun
Sat Apr 06 20:57:10 2019 TAP-WIN32 device [VPN-nat] opened: \\.\Global\{FE484EAF-8CE0-4A40-878C-1D153D0C6F86}.tap
Sat Apr 06 20:57:10 2019 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.30.0/10.8.30.2/255.255.255.0 [SUCCEEDED]
Sat Apr 06 20:57:10 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.30.2/255.255.255.0 on interface {FE484EAF-8CE0-4A40-878C-1D153D0C6F86} [DHCP-serv: 10.8.30.254, lease-time: 31536000]
Sat Apr 06 20:57:10 2019 Successful ARP Flush on interface [21] {FE484EAF-8CE0-4A40-878C-1D153D0C6F86}
Sat Apr 06 20:57:15 2019 Initialization Sequence Completed

 

[octopus]

Check ciphers, hash and other TLS-related parameters.
Also make sure you test from outside your LAN, the loopback might have trouble dealing with connection requests initiated from inside.

A little wonder about the loopback feature. I can see that there is lo in the INPUT chain but not in the FORWARD chain.
Looks in filter.default that "-A FORWARD -in lo -o lo -j ACCEPT" exists though.
When I testing my FTP from my Android on port 21 loopback seems to work fine.

 

[RMerlin]

A little wonder about the loopback feature. I can see that there is lo in the INPUT chain but not in the FORWARD chain.
Looks in filter.default that "-A FORWARD -in lo -o lo -j ACCEPT" exists though.
When I testing my FTP from my Android on port 21 loopback seems to work fine.

That's not for the NAT loopback, that's for the lo interface used internally/locally by Linux.