Assigin specific ip address for UserName (( Vpn Client Login ))

[Asusrouterlover]

Hi

I Want to Assign IP addresses for some usernames (open Vpn client Login) Because I Want these users to access the File server Only to do some file updates and disconnect the connection.

have someone any idea?

 

[eibgrad]

How you presently have the OpenVPN server configured will determine what's the best approach. Let me explain the big picture, then why it matters how you're presently configured.

You need to create a client-specific file (based on the CN (Common Name) of its cert) which contains the ifconfig-push directive, which specifies the IP and netmask you wish to be assigned (as opposed to what would automatically be assigned from that same IP pool).

ifconfig-push 10.8.0.254 255.255.255.0

Note, if you're using the one and only auto-generated client cert by the router (which most ppl are), then you need to add the following directive to the custom config field of the OpenVPN server so you can create these files based on the username rather than the CN.

username-as-common-name

Notice I started assigning IPs from the END of the pool. I did that because OpenVPN will NOT reserve these IP assignments just because you've defined them in these files. IOW, it's NOT like DHCP. It's dumb. And so you'll avoid problems if you start from the end of the IP pool and work backwards. Other ppl choose to use a completely different IP network to avoid such conflicts, but then you have to bind that IP network to the OpenVPN client and server. It does have the advantage of being able to treat anyone assigned to that IP network as a group (e.g., admins). But for now, I recommend keeping it simple and using the same IP network as the tunnel.

These client-specific files must be placed in the CCD directory (of your choosing), which is specified w/ the client-config-dir directive in the custom config field of the OpenVPN server.

client-config-dir /jffs/ccd

Now here's the tricky part.

If you're already using the "Allowed Clients" section of the Manage Client-Specific Options section of the OpenVPN server, then the router has already configured a CCD directory and client-specific files! But it does this "on the fly", during startup of the server, making it difficult to modify those files to include your own directives. If that's the case, you're better off to NOT use the "Allowed Clients" section, and manage all the per-client directives yourself, in your own CCD directory and files.

IOW, the "Allowed Clients" section is just a convenience. But it stops being a convenience once you have the need to also manage your own directives and not just those being managed by the router.

 

[Asusrouterlover]

How you presently have the OpenVPN server configured will determine what's the best approach. Let me explain the big picture, then why it matters how you're presently configured.

You need to create a client-specific file (based on the CN (Common Name) of its cert) which contains the ifconfig-push directive, which specifies the IP and netmask you wish to be assigned (as opposed to what would automatically be assigned from that same IP pool).

ifconfig-push 10.8.0.254 255.255.255.0

Note, if you're using the one and only auto-generated client cert by the router (which most ppl are), then you need to add the following directive to the custom config field of the OpenVPN server so you can create these files based on the username rather than the CN.

username-as-common-name

Notice I started assigning IPs from the END of the pool. I did that because OpenVPN will NOT reserve these IP assignments just because you've defined them in these files. IOW, it's NOT like DHCP. It's dumb. And so you'll avoid problems if you start from the end of the IP pool and work backwards. Other ppl choose to use a completely different IP network to avoid such conflicts, but then you have to bind that IP network to the OpenVPN client and server. It does have the advantage of being able to treat anyone assigned to that IP network as a group (e.g., admins). But for now, I recommend keeping it simple and using the same IP network as the tunnel.

These client-specific files must be placed in the CCD directory (of your choosing), which is specified w/ the client-config-dir directive in the custom config field of the OpenVPN server.

client-config-dir /jffs/ccd

Now here's the tricky part.

If you're already using the "Allowed Clients" section of the Manage Client-Specific Options section of the OpenVPN server, then the router has already configured a CCD directory and client-specific files! But it does this "on the fly", during startup of the server, making it difficult to modify those files to include your own directives. If that's the case, you're better off to NOT use the "Allowed Clients" section, and manage all the per-client directives yourself, in your own CCD directory and files.

IOW, the "Allowed Clients" section is just a convenience. But it stops being a convenience once you have the need to also manage your own directives and not just those being managed by the router.

deep answer and good description thank you so much
have you good website for openvpn? i need to read
i am totaly new in openvpn subject

 

[eibgrad]

The openvpn.net website has a wealth of information, including documentation of all options, tutorials, examples, forums, etc. A lot of questions users ask in the SNB forums are better addressed by OpenVPN. It's a resource far too many users overlook.

Regarding this specific topic, the following is directly from OpenVPN itself.

How To Guide: Set Up & Configure OpenVPN Client/server VPN | OpenVPN

This How TO guide provides step-by-step instructions for configuration and set up of OpenVPN 2.x client/server VPN.

openvpn.net

Notice they illustrate how to manage this process using different IP networks (something I mentioned above). Also notice they assume a net30 topology, NOT subnet (the router uses the latter by default, but you could change it). It only matters in terms of how you configure the ifconfig-push directive(s). Notice they don't need to worry about working backwards from the default IP network (10.8.0.0/24) because they're statically assigning IPs from additional IP networks (10.8.1.0/24, 10.8.2.0/24, etc.), which will never be used for automatic/arbitrary IP assignment like 10.8.0.0/24 will.

Just realize that documentation is NOT exhaustive in how you could configure this, but just one example.