OpenVPN bug ccd/client

[Laxarus]

Hello,
I was trying to setup a two-way site2site OpenVPN server and noticed a particular bug or configuration mistake.
RT-AC5300 with merlin fw 386.3_2 as openvpn server
RT-AX86U with merlin fw 386.4 as openvpn client.

I used server 2 since server 1 was in use.
I have created a user from the VPN Server menu and setup my VPN server with "Allow only specified clients" setting then I used the newly created username on it. However, I got an autharization failure on the client side. when trying to connect to the server. When I looked at the logs on the server, I noticed the error line like this:

Jan 15 14:37:42 ovpn-server2[10325]: 176.232.59.7:27913 TLS Auth Error: --client-config-dir authentication failed for common name 'client' file='ccd/client'

It appears that the vpn server CN setting is not relayed correctly since it is looking for 'ccd/client', however, it should look for 'ccd/Guneycity'. Since it was the CN I assigned.

I have created another entry under the "Allowed Clients" and named it client. This time my VPN client successfully connected.

I am not sure if this is fixed in the latest version if not I would like to report it @RMerlin and cannot access the server side since I am not on site.

I hope this will be helpful. I can provide more logs if requested.

 

[eibgrad]

If you're using the certs and keys auto-generated by the router for the OpenVPN server, then the CN (Common Name) is client (it's part of the cert). You can't change this unless you generate your own certs and keys using EASY-RSA. Is that what you did?

 

[eibgrad]

BTW, post your entire OpenVPN server configuration page so we can see exactly how you configured it. There are so many options available, and depending on how you set them can greatly change how it works wrt authentication.

In fact, let's cut to the chase, dump the configuration file as well.

cat /tmp/etc/openvpn/server2/config.ovpn

 

[Laxarus]

This is the configuration:

daemon ovpn-server2
topology subnet
server 10.16.0.0 255.255.255.0
proto tcp-server
port 1195
dev tun22
txqueuelen 1000
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
keepalive 15 60
verb 3
push "route 192.168.1.0 255.255.255.0 vpn_gateway 500"
client-config-dir ccd
client-to-client
ccd-exclusive
route 192.168.50.0 255.255.255.0
route 192.168.50.0 255.255.255.0
push "dhcp-option DOMAIN laxhome.org"
push "dhcp-option DNS 192.168.1.45"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 192.168.1.1"
tls-auth static.key 1
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up 'ovpn-up 2 server'
down 'ovpn-down 2 server'
status-version 2
status status 5

And the screenshots:

I am using Guneycity username and password to connect the server but if I remove the "client" from the "Allowed Clients" it fails to authenticate.
The certs are auto generated.

 

[eibgrad]

Try adding the following directive to the OpenVPN server custom config field and see if you can now remove the entry for 'client'.

username-as-common-name

I'm assuming Guneycity is indeed a valid username.

 

[Laxarus]

Try adding the following directive to the OpenVPN server custom config field and see if you can now remove the entry for 'client'.

username-as-common-name

I'm assuming Guneycity is indeed a valid username.

That did the trick. Thanks.
However, logically you should not use any custom config at all if you add this CN to the list right?

 

[eibgrad]

That did the trick. Thanks.
However, logically you should not use any custom config at all if you add this CN to the list right?

Yes, but YOU insisted on distinguishing the user based on the username, when the default is the CN of the client's cert, which is 'client'. We added the username-as-common-name directive to override that default and satisfy your preference for username.

 

[Laxarus]

Yes, but YOU insisted on distinguishing the user based on the username, when the default is the CN of the client's cert, which is 'client'. We added the username-as-common-name directive to override that default and satisfy your preference for username.

Got it. Thanks for the explanation. It is not related but do you know anyway to pass the ip information through the vpn tunnel?

I mean when you access a machine at site A from site B, the logs on the machine shows only the vpn ip address which is in this case in 10.16.0.0/24 range. It is of course normal that it shows that way since it is the router itself acting as a bridge but is there a way to configure this so that real local ip information gets transferred? I am searching this but couldn't figure it out.

 

[eibgrad]

Got it. Thanks for the explanation. It is not related but do you know anyway to pass the ip information through the vpn tunnel?

I mean when you access a machine at site A from site B, the logs on the machine shows only the vpn ip address which is in this case in 10.16.0.0/24 range. It is of course normal that it shows that way since it is the router itself acting as a bridge but is there a way to configure this so that real local ip information gets transferred? I am searching this but couldn't figure it out.

The reason you lose the actual IP of the device initiating the contact is because the tunnel has been NAT'd. But you typically NAT only when you don't control the server, such as when connected to a commercial OpenVPN provider. That provider has no way to know how to route back to your local network (e.g., 192.168.1.0/24). So you mask all your 192.168.1.0/24 devices w/ the OpenVPN client's IP on the tunnel (e.g., 10.8.0.2), which obviously the OpenVPN provider *does* know how to route back.

But when YOU control both sides (client and server), NAT isn't necessary since you can configure the server to route that network (192.168.1.0/24) back over the tunnel w/ static routing! And that's why the Manage Client-Specific Options section exists. That is how you inform the server about what local/private network(s) lie behind the OpenVPN client. All the server requires is that you uniquely identify that client based on its CN, since there could be multiple OpenVPN clients connecting to the same server, each w/ their own local/private networks.

Since the router only creates *one* client cert (and keys) to be shared by all users, you were forced to use the username-as-common-name directive to disambiguate among those OpenVPN clients (assuming you actually have multiple OpenVPN clients; if you only have the one, using the CN would have sufficed, but you insisted on the username).

IOW, NAT and site-to-site are typically mutually exclusive, at least if you configure site-to-site correctly. There's absolutely no reason either side needs to NAT provided each has all the information necessary to know what local/private networks reside on each side, and therefore when to route them over the tunnel.

 

[John Fitzgerald]

VPN help via Microsoft, if this helps:

January 17, 2022—KB5010793 (OS Builds 19042.1469, 19043.1469, and 19044.1469) Out-of-band - Microsoft Support

support.microsoft.com