connection to linux openvpn 2.3.2 failed, ideas?

[eak]

I have working openvpn servers running on two machines, and several clients (primarily Tunnelblick) that connect to those servers. I would like to move from client connections to Asuswrt-Merlin, so I created a .ovpn file for my ASUS RT-AC66U and uploaded it to OpenVPN Client 1. When I slide the enable switch from on to off, it says processing for a while and then returns to the OpenVPN Client window with slider turned back off. The server log file contains no mention of a connection attempt. I have elided things that don't need to be posted with "...".

Any ideas on what might be wrong or how to debug this?

One question: my certificate authority create ECDSA keys by default. Is this supported by Asuswrt-Merlin?

Here is the uploaded .ovpn file:
# Mode
client

# IP Protocol
proto udp

# Local UDP port for packet transport
nobind

# Internet address of maple.killian.com
remote 216.229.97.145 1194

# Enable compression
comp-lzo

# Choose encryption algorithm
reneg-sec 1800
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
cipher AES-128-CBC

# Choose digest algorithm
auth SHA256

#
# Authentication/encryption
#

# In SSL/TLS key exchange, we will assume the client role
tls-client

# Verify maple.killian.com's CN
verify-x509-name '...' subject

# Certificate Authority file
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<crl-verify>
-----BEGIN X509 CRL-----
...
-----END X509 CRL-----
</crl-verify>

# Our certificate/public key
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

# Our private key
<key>
-----BEGIN EC PARAMETERS-----
...
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
...
-----END EC PRIVATE KEY-----
</key>

 

[eak]

Asuswrt-Merlin version

I forgot to mention that I am running Firmware:3.0.0.4.374.38_1

 

[sinshiva]

the private key brackets should probably only enclose the key, move the parameters

 

[eak]

where?

Thank for the suggestion. Could you say where they should be moved to? On Linux system where I use OpenVPN, the parameters are generated by openssl ecparam, and it puts they in a .key file, which I then reference in a .conf/.ovpn file via the key statement. I'm not sure where I would move them to in the file I upload to the RT-AC66U.

 

[sinshiva]

above or below the brackets should work, i'd think

[edit/]
you know what, i have no idea, sorry. if it is meant to be separated, it would likely need some kind of <something></something> brackets, but i've not dealt with that one before and google didn't help me much. maybe it does actually go within those key brackets. sorry about this

 

[connorm]

oooooooooo

 

[eak]

cannot locate HMAC

I found two problems. One, it appears the crl-verify is not supported. My <crl-verify>...</crl-verify> was not being parsed correctly. Second the line
verify-x509-name 'C=US, ST=California, O=Killian.COM, CN=maple.killian.com' subject
lost its quotes when uploaded, as was visible in the "Custom Configuration" section. Adding them back in there, doing an Apply, and then turning on the client worked to start things going, but the connection did not work. The server log file is now showing
openvpn[30058]: message repeated 4 times: [ TLS Error: cannot locate HMAC in incoming packet from [AF_INET]x.y.w.z:54919]
openvpn[30058]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]x.y.z.w:59894

So this appears to reveal one bug (quotes stripped) and one feature missing (crl-verify).

Does anyone have ideas on he HMAC?

 

[sinshiva]

can you post the server configuration? (without the keys, of course)

[edit/]scratch that, i see you said the log is from the server

it sounds like the static key is messed up

oh, try adding this line to the client ovpn; remote-cert-tls server

[edit/] a little late, but that line actually just tells the client to check that the server is using tls, iirc.

 

[RMerlin]

One question: my certificate authority create ECDSA keys by default. Is this supported by Asuswrt-Merlin?

Here's what's supported:

admin@stargate4:/tmp/home/root# openvpn --show-digests
The following message digests are available for use with
OpenVPN.  A message digest is used in conjunction with
the HMAC function, to authenticate received packets.
You can specify a message digest as parameter to
the --auth option.

MD5 128 bit digest size
RSA-MD5 128 bit digest size
SHA 160 bit digest size
RSA-SHA 160 bit digest size
SHA1 160 bit digest size
RSA-SHA1 160 bit digest size
DSA-SHA 160 bit digest size
DSA-SHA1-old 160 bit digest size
MDC2 128 bit digest size
RSA-MDC2 128 bit digest size
DSA-SHA1 160 bit digest size
RSA-SHA1-2 160 bit digest size
DSA 160 bit digest size
RIPEMD160 160 bit digest size
RSA-RIPEMD160 160 bit digest size
MD4 128 bit digest size
RSA-MD4 128 bit digest size
ecdsa-with-SHA1 160 bit digest size
RSA-SHA256 256 bit digest size
RSA-SHA384 384 bit digest size
RSA-SHA512 512 bit digest size
RSA-SHA224 224 bit digest size
SHA256 256 bit digest size
SHA384 384 bit digest size
SHA512 512 bit digest size
SHA224 224 bit digest size
whirlpool 512 bit digest size

admin@stargate4:/tmp/home/root# openvpn --show-tls
Available TLS Ciphers,
listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-AES-256-CBC-SHA
TLS-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-PSK-WITH-AES-256-CBC-SHA
TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA
TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA
TLS-RSA-WITH-3DES-EDE-CBC-SHA
TLS-PSK-WITH-3DES-EDE-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-DSS-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-SEED-CBC-SHA
TLS-DHE-DSS-WITH-SEED-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA
TLS-ECDH-RSA-WITH-AES-128-CBC-SHA
TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-AES-128-CBC-SHA
TLS-RSA-WITH-SEED-CBC-SHA
TLS-RSA-WITH-CAMELLIA-128-CBC-SHA
IDEA-CBC-SHA (No IANA name known to OpenVPN, use OpenSSL name.)
TLS-PSK-WITH-AES-128-CBC-SHA
TLS-ECDHE-RSA-WITH-RC4-128-SHA
TLS-ECDHE-ECDSA-WITH-RC4-128-SHA
TLS-ECDH-RSA-WITH-RC4-128-SHA
TLS-ECDH-ECDSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-SHA
TLS-RSA-WITH-RC4-128-MD5
TLS-PSK-WITH-RC4-128-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-RSA-WITH-DES-CBC-SHA
TLS-DH-RSA-EXPORT-WITH-DES40-CBC-SHA
TLS-DH-DSS-EXPORT-WITH-DES40-CBC-SHA
TLS-RSA-EXPORT-WITH-DES40-CBC-SHA
TLS-RSA-EXPORT-WITH-RC2-CBC-40-MD5
TLS-RSA-EXPORT-WITH-RC4-40-MD5

No idea on your issue however, I'm not an expert on OpenVPN.

 

[eak]

got it working

So there were three problems that I ran into trying to get things working. First, the quotes were dropped on the verify-x509-name statement. Second, crl-verify was not supported. Third, when I uploaded the .ovpn file, it did not recognize that the "Extra HMAC authorization (tls-auth)" setting needed to be set to Bi-directional (it was still set to Disabled).

I suppose I could have used the "Verify Server Certificate" feature rather than verify-x509-name in the .ovpn file, but this was a configuration that was generated from perl scripts that works for other systems, and I was trying to change as little as possible to keep things common.

Anyway, thanks to the people who posted suggestions. I appreciate the help. And thank you for Asuswrt-Merlin. Perhaps the above will suggest some fixes/features in future releases.

 

[RMerlin]

I found two problems. One, it appears the crl-verify is not supported. My <crl-verify>...</crl-verify> was not being parsed correctly. Second the line
verify-x509-name 'C=US, ST=California, O=Killian.COM, CN=maple.killian.com' subject
lost its quotes when uploaded, as was visible in the "Custom Configuration" section.

When parsing the config file, Asus is converting the line into separate parameters, so they can be properly stored in nvram if they match a parameter directly supported by the firmware. That conversion specifically removes any single or double quote. However any unsupported parameter gets written to the custom field in its processed format.

I don't know how trivial it will be to have the unprocessed line written to the custom field, I will have to study Asus's parser code.

crl-verify is indeed not implemented at the firmware level. You would have to configure this manually if you want to use this specific option.

 

[eak]

verify-x509-name

Thank you RMerlin. Since I would like to make importing a .ovpn file require minimal twiddling after the import, I have one question.

On the verify-x509-name issue, if I had used
verify-x509-name xyz.com name
instead of
verify-x509-name "C=..., CN=xyz.com" subject
would it have used the GUI "Verify Server Certificate" feature without the quoting problem?

 

[RMerlin]

Thank you RMerlin. Since I would like to make importing a .ovpn file require minimal twiddling after the import, I have one question.

On the verify-x509-name issue, if I had used
verify-x509-name xyz.com name
instead of
verify-x509-name "C=..., CN=xyz.com" subject
would it have used the GUI "Verify Server Certificate" feature without the quoting problem?

No. The verify-x509-name setting is not recognized by the firmware, so it will always end up in the custom section.

Try using "tls-remote commonname" - that's what will toggle the Verify Server Certificate option at import time. Not sure if it's exactly the same as what verify-x509-name would have done, I'm not familiar enough with OpenVPN.

 

[eak]

deprecated

Just so you know, the OpenVPN 2.3.2 man page says:
--tls-remote name (DEPRECATED)
...
Please also note: This option is now deprecated. It will be removed either in OpenVPN v2.4 or v2.5. ...

 

[RMerlin]

Just so you know, the OpenVPN 2.3.2 man page says:
--tls-remote name (DEPRECATED)
...
Please also note: This option is now deprecated. It will be removed either in OpenVPN v2.4 or v2.5. ...

Ya. The original TomatoVPN code on which mine is based goes back to OpenVPN 2.2 (if not older).

That's a bridge I'll cross when I get there tho. In the mean time it might get what you need.