Asus Merlin firmware OpenVPN multiple connection

[jasonwch]

Hi, maybe I am dumb. But I just find that I've create 1 OpenVPN server at Asus AX68U.

Device A connected to VPN, working fine
Device B connected to VPN, Device A network become not responding (tho it's still connected)

I can also see that they will all getting the same IP address.

I've tried create 2 login, but still the same issue.

Do I need to do some configuration to allow multiple connection, or I need to create another OpenVPN server for every connection?

Thanks

 

[DMS11X]

I found at least in my setup TCP performed better than the recommended UDP.

 

[jasonwch]

I found at least in my setup TCP performed better than the recommended UDP.

Just tried to change from UDP to TCP, A device connected, then when I connect from B device, A device will disconnect

 

[jasonwch]

I think I figured out by adding this to custom config:
duplicate-cn

But also aware that someone will also add one more line: username-as-common-name. I am not sure what this line do. Now I am working without this line, but clients can still communicate with each other by SMB file sharing (as a test). May I know what common name means inside the VPN routing?

 

[eibgrad]

The problem here is that you have NOT specifically described *how* you've configured the OpenVPN server. Without such details, we can't accurately explain your situation.

Using the default settings, the duplicate-cn directive is automatically added to the underlying config file. This is necessary because ALL connected clients *share* a single client cert/key. Without the duplicate-cn directive, the OpenVPN server will drop the current connection that's using that same cert/key in favor of the new connection.

But the fact you had to *manually* add the duplicate-cn directive tells me you are NOT using the default settings. You made a change that lead the router to remove it. And now I have to guess what that was.

One possibility? You enabled MCSO (Manage Client-Specific Options). That section assumes that each connecting client will have its own unique cert/key, differentiated by the CN (Common Name) on its cert. This differentiation is typically needed for the purposes of a site-to-site configuration, where each client is supporting different local IP networks on its side of the tunnel. And you can't support multiple, concurrent OpenVPN clients in this manner if the they don't have a unique cert! So the router removes the duplicate-cn directive.

The username-as-common-name directive is a workaround for those who insist on using a single shared client cert/key. What OpenVPN will now do is differentiate users based on their username rather than the CN on their cert.

But that might just be one possibility. There are a lot of options here, resulting in many different configurations. Shared cert, multiple certs (that you created), certs w/ and w/o username/password, no certs at all but just username/password, MCSO enabled/disabled, etc. If you leave out such details, we just have to guess.

 

[jasonwch]

The problem here is that you have NOT specifically described *how* you've configured the OpenVPN server. Without such details, we can't accurately explain your situation.

Using the default settings, the duplicate-cn directive is automatically added to the underlying config file. This is necessary because ALL connected clients *share* a single client cert/key. Without the duplicate-cn directive, the OpenVPN server will drop the current connection that's using that same cert/key in favor of the new connection.

But the fact you had to *manually* add the duplicate-cn directive tells me you are NOT using the default settings. You made a change that lead the router to remove it. And now I have to guess what that was.

One possibility? You enabled MCSO (Manage Client-Specific Options). That section assumes that each connecting client will have its own unique cert/key, differentiated by the CN (Common Name) on its cert. This differentiation is typically needed for the purposes of a site-to-site configuration, where each client is supporting different local IP networks on its side of the tunnel. And you can't support multiple, concurrent OpenVPN clients in this manner if the they don't have a unique cert! So the router removes the duplicate-cn directive.

The username-as-common-name directive is a workaround for those who insist on using a single shared client cert/key. What OpenVPN will now do is differentiate users based on their username rather than the CN on their cert.

But that might just be one possibility. There are a lot of options here, resulting in many different configurations. Shared cert, multiple certs (that you created), certs w/ and w/o username/password, no certs at all but just username/password, MCSO enabled/disabled, etc. If you leave out such details, we just have to guess.

UPDATE 1:
Seems like now I am using username-as-common-name, then the traffic can go back and forth for VPN clients and home devices behind Asus VPN server. But there are some tricks to make SMB works from Windows firewall settings as Windows firewall by default only allows local subnet IP to get through. So this come to another question, beside playing with Windows firewall setup, anyway to make all kind of devices (VPN client or home device, Windows, Mac, Android, IOS) to permit each other on both subnet local 192.168.50.X and VPN 10.8.0.X

Thanks and not sure if this is possible


Hi @eibgrad

Nice to meet you here, I've read a lot of your posts which also hints on adding this derivatives dupicate-cn

Please see attached for my OpenVPN setup. What I am trying to do is using just one *single* cert/config file which can applied by my own different devices (PCs, iPad and Android mobile). As from your comment, I may need use different account to login from different devices and use"username-as-common-name" instead of "duplicate-cn" becuase I also want to achieve the following:

My setup is simple, this OpenVPN is on my home router, there are some PCs, NAS behind it. My mobile devices (laptop, iPad, Andorid) will use OpenVPN Connect app to connect this VPN to play safe on some public wifi. Now, I can use *IP / full hostname* (e.g. homepc.domain) to access home devices (PCs,NAS) from VPN client (mobile devices). ALSO I can use *IP* (but NOT hostname) to access between VPN clients (e.g. Android phone to Laptop through SMB). BUT I cannot make home devices (device behind my OpenVPN router) to access VPN clients (e.g. from my home PC to my Windows laptop connected with OpenVPN through SMB).

From some of your posts and also other information on the web, My assumption is due to different subnet for home clients (192.168.1.X) and VPN clients (10.8.0.X). For VPN clients, the OpenVPN server will push the route back to home subnet, so OpenVPN client can access back to home devices. But there is no route from home devices to VPN clients because there are no VPN server involvement with home devices.

May I know what can I do to push these route on my home devices? or any setup I can do on VPN server to push VPN client's subnet information back to home subnet?

Thanks so much

 

[eibgrad]

UPDATE 1:
Seems like now I am using username-as-common-name, then the traffic can go back and forth for VPN clients and home devices behind Asus VPN server. But there are some tricks to make SMB works from Windows firewall settings as Windows firewall by default only allows local subnet IP to get through. So this come to another question, beside playing with Windows firewall setup, anyway to make all kind of devices (VPN client or home device, Windows, Mac, Android, IOS) to permit each other on both subnet local 192.168.50.X and VPN 10.8.0.X

Thanks and not sure if this is possible

How to allow openvpn clients to access my LAN PC?

Hey, guys！ I set up an OpenVPN server on my ASUS AC66U-B1 (running Merlin 386.3_2). I have to use tun mode to allow android phones. I set "Client will use VPN to access" to Both (the other two choices are "LAN only" and "Internet only"). My phone can access the USB drive connected to the...

www.snbforums.com

Hi @eibgrad

Nice to meet you here, I've read a lot of your posts which also hints on adding this derivatives dupicate-cn

Please see attached for my OpenVPN setup. What I am trying to do is using just one *single* cert/config file which can applied by my own different devices (PCs, iPad and Android mobile). As from your comment, I may need use different account to login from different devices and use"username-as-common-name" instead of "duplicate-cn" becuase I also want to achieve the following:

My setup is simple, this OpenVPN is on my home router, there are some PCs, NAS behind it. My mobile devices (laptop, iPad, Andorid) will use OpenVPN Connect app to connect this VPN to play safe on some public wifi. Now, I can use *IP / full hostname* (e.g. homepc.domain) to access home devices (PCs,NAS) from VPN client (mobile devices). ALSO I can use *IP* (but NOT hostname) to access between VPN clients (e.g. Android phone to Laptop through SMB). BUT I cannot make home devices (device behind my OpenVPN router) to access VPN clients (e.g. from my home PC to my Windows laptop connected with OpenVPN through SMB).

From some of your posts and also other information on the web, My assumption is due to different subnet for home clients (192.168.1.X) and VPN clients (10.8.0.X). For VPN clients, the OpenVPN server will push the route back to home subnet, so OpenVPN client can access back to home devices. But there is no route from home devices to VPN clients because there are no VPN server involvement with home devices.

May I know what can I do to push these route on my home devices? or any setup I can do on VPN server to push VPN client's subnet information back to home subnet?

Thanks so much

View attachment 44101

If you want home devices to initiate connections to OpenVPN clients, there should be NO NEED to enable MCSO, since that's only intended for site-to-site, where you need access to the devices *behind* the OpenVPN client on its own private IP network. As far as I can tell from your description, this is NOT a requirement.

And since there is no site-to-site here, there's no need to disambiguate OpenVPN clients based on either their CN or username. Again, that only becomes necessary in order to know which OpenVPN client is supporting which private IP network behind it.

So when all is said and done, you don't need anything more than the router defaults, which means a shared client cert and key, and optionally the user of username/passwords, but only for the purposes of additional security (esp. since everyone is sharing a client cert/key). But things like MCSO, username-as-common-name, etc., are just irrelevant. Those are site-to-site requirements, which don't apply to your use case.

If there's any remaining problem here at all, it's being able to tell which OpenVPN client has which assigned IP on the tunnel! IOW, what you probably want/need is *statically* assigned IPs on the tunnel. At least if you intend to have devices at home initiate connections to those OpenVPN clients.

 

[jasonwch]

How to allow openvpn clients to access my LAN PC?

Hey, guys！ I set up an OpenVPN server on my ASUS AC66U-B1 (running Merlin 386.3_2). I have to use tun mode to allow android phones. I set "Client will use VPN to access" to Both (the other two choices are "LAN only" and "Internet only"). My phone can access the USB drive connected to the...

www.snbforums.com

If you want home devices to initiate connections to OpenVPN clients, there should be NO NEED to enable MCSO, since that's only intended for site-to-site, where you need access to the devices *behind* the OpenVPN client on its own private IP network. As far as I can tell from your description, this is NOT a requirement.

And since there is no site-to-site here, there's no need to disambiguate OpenVPN clients based on either their CN or username. Again, that only becomes necessary in order to know which OpenVPN client is supporting which private IP network behind it.

So when all is said and done, you don't need anything more than the router defaults, which means a shared client cert and key, and optionally the user of username/passwords, but only for the purposes of additional security (esp. since everyone is sharing a client cert/key). But things like MCSO, username-as-common-name, etc., are just irrelevant. Those are site-to-site requirements, which don't apply to your use case.

If there's any remaining problem here at all, it's being able to tell which OpenVPN client has which assigned IP on the tunnel! IOW, what you probably want/need is *statically* assigned IPs on the tunnel. At least if you intend to have devices at home initiate connections to those OpenVPN clients.

Thank you so much, but seems the POSTROUTE is a bit overkill. I will leave it in my pocket...thanks anyway