What's new

[SOLVED] openvpn server "UNDEF" in common name

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

octopus

Part of the Furniture
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?
 

Attachments

  • tun22_octopus-1.jpg
    tun22_octopus-1.jpg
    34.6 KB · Views: 1,441
  • tun22_UNDEF.jpg
    tun22_UNDEF.jpg
    22.6 KB · Views: 1,304
UNDEF shows if a client fails to complete its connection - this is intended behaviour by the OpenVPN devs.
 
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.

Code:
./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.
Code:
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):
 
The System Log will tell you why it's rejecting the client.
 
The System Log will tell you why it's rejecting the client.
I get this in log:
Code:
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
 
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.
 
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!

Code:
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
 
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.
 
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.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top