We Keep Coding

How would I go about connecting to a VPN providing a certificate file (.ovpn) then also specifying a username and password?

I have recently been trying to create a VPN client in C# utilizing OpenVPN, I want my users to be able to select a .ovpn file, then enter a username and password to make a connection to the VPN. Is this possible? I'm using C# in Visual Studio 2019.

A hint on how you are currently interfacing can make a huge difference, i will for now assume you just start/stop the service with commandline commands.
You could start a specific ovpn file by running openvpn --config sample.ovpn
On how to add login and password to that config i will refer you to https://forums.openvpn.net/viewtopic.php?t=11342
However do note that storing any password is unsafe unless done very carefully and secure and always notify your users you are storing it! Saving plaintext is not an option!
An alternative might be looking for an existing (open-source) c# app that provides this functionality and maybe forking the code. For example: https://github.com/AirVPN/Eddie
Note: I am not in any way connected to AirVPN or Eddie project other than knowing it exists. I am sure there are many more alternatives out there, this was purely an example.

Is the security of this .net application flawed?

Ok, I know that every obfuscated .Net application can be reverse engineered.
And I know that it is better if I go the open source way if possible. But unfortunately I cannot because there is no copyright law to protect me where I live.
So I've come up with a plan to make it harder. Since I'm very very novice regarding the security I hope that you will help me find any loopholes in this plan.
The user downloads the application
The user enters his username/password and starts working
He need to export the results to a specific file format
The application connects to the server, and checks the username/password
The data required to create the file are sent to the server
The server creates the file on the server and sends it back to the user
Now if someone cracks the program by bypassing the username/password check the file won't be sent from the server and he won't be able to get the file he wants, something similar software as a service.
Now I want to know if this is the correct way to go? What suggestions to make it better?

Yes, one way to protect your IP is to hide parts of your application logic on a backend server where a cracker cannot simply remove simple piracy checks - they would need to reverse engineer your API to create their own service somewhere to keep the application working.
Note that while this makes things more difficult for crackers, it is not impossible to do, and there are several games who use this scheme that have successfully been "cracked".

Sending file in lan without a client/server solution

I working on a windows forms project, visual studio 2010, c#
I want to send some files to computers in our network but they don't have a "listener" as in client/server solution but i do have username/password. Is there any way to send files knowing this information? And as i said, i do not want to build a client / server solution.
Cant i use "Impersonate" somehow?

If you know the username password and your client is within the same domain, you might be able to use UNC with authentication (with $) and send the files to client PC. Something like: \\clientPC\c$. Once authenticated, you can just use File IO, e.g. File.Copy(..."\\clientPC\c$\yourfile.txt") to send file.
You can use the class posted here for UNC authentication.

Is this in the same domain as your machine? If so, do you have the ability to create a share? If you can, you may be able to just setup a share and transfer the files as you would locally. If this is possible there is no point in creating a verbose application for a trivial need.
I built similar for a company I used to work for, the "client" exposed a share and me; the "server" simply used File.Move() to transfer files.

Yes you can use impersonate,
Read this article
, Maybe it will helpful.

Best Practice for Connecting ASP.NET to SQL Server

We have an ASP.NET 4.0 Web application that connects to a SQL Server on a separate machine across a LAN. I use a ConnectionString (with SQL Server authentication) stored in my Web.config to do this. Basically, it's a fairly traditional Web-Server-to-SQL strategy.
However, one of our clients is arguing that this strategy is not secure. This client says that we should only connect to the SQL Server through a separate Web Services layer.
I really don't want to rewrite this app just to satisfy this client. What should I tell him? Does any one know how I might best refute this?
Thanks in advance...

Security is always a trade-off. What is the client really afraid of?
Having database credential "in the clear"? I have seen auditors point this out as a potential vulnerability, but really, if someone has compromised your web server they can run arbitrary code against the database, so encrypting database credentials doesn't really buy you much.
Your web app should be using a minimal-rights user to connect to the database, so compromising the web server should only give you the rights to read & update data. How would that change if everything went through a web services layer? Again, there is a very real cost - in complexity, and in performance - by going to a web services layer. Only the client can answer whether or not that cost is worth it.

If this is a web project, you need to change IIS servers running user to a domain user and give permission on sql server to that user.
Than you can use SSPI on your connection string like below.
Like this, you don't need to keep your username or password clearly on web.config.
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
and your connectionString
"Integrated Security=SSPI;Initial Catalog=TestDb;Data Source=10.10.10.10"

There are many customers that argue the work of an IT professional, just like there are many people visiting the doctor asking for the medicine instead of what disease they have, because they already know the answer since they read about it on the internet.
I mean, they ask you to build the application and you as an IT professional should know best when your application works as expected. You as a professional should have balls to tell your customer that if he think can get somewhere else better, he should go there or perhaps build the application himself; that's what have done in the past with positive results :)
Regarding security; perhaps for their confidence you can encrypt the web.config and show them, but actually it means nothing; if someone can access the server, they could decode it. On the other hand, someone that want to break in to your database should pass trough a lot of barriers. It's hard to break in, perhaps impossible. Another options is simply blocking connections from outside network the network or ip range or whatever. I think this shouldn't be something to worry about.
There much more and either more realistic concerns to worry about, such as preventing cross site scripting and such common treats.

The client is wrong introducing another tier would not automatically improve security.
In a nutshell use SQL server roles for data access for example the built in data_reader and data_writer roles are a good place to start. Always use the most appropriate least privilege account for the application. If you only need to read data use an account that only has access to read.
Use Windows authentication where possible, if this isn't possible then at least encrypt the connectionstring.
More information on how to do what I've described can be found at http://msdn.microsoft.com/en-us/library/ff650037.aspx#pagpractices0001_dataaccess

One possibility is to encrypt the section in the web.config. So, only user who can access the webserver directly can decrypt this section.
Here is how this works with the help of the iisreg-tool:
http://msdn.microsoft.com/en-us/library/zhhddkxy.aspx

You could enable Encrypted connections in your database and tell the client that the connections are encrypted so fully secure?

To make it more secure, and satisfy your customer you can use Tunneling between your computers.
You setup a server tunneling program where the database exist, and client tunneling programs on the client computer. You connect the one computer to the other via tunneling, and the database connection happens over tunneling.
And everything is exchange high secure (and compressed if the tunneling support it).
http://en.wikipedia.org/wiki/Tunneling_protocol
http://en.wikipedia.org/wiki/HTTP_tunnel
Ps I connect to my server only via tunneling for anything that I do.

I never liked using the web config. The registry is more secure.
Best Practices is to:
Hide the important items of the connection string in the registry
Encrypt the important items in the connection like user names, passwords and server name in the
registry
Access the registry through a class
Build the connection string on the fly and only when needed per page
Error handle every page so the connection string won't show, in case of error
Always close the connections once done. Avoid memory leaks
Always close and reset DataReaders
For additional Security
You can build a separate program to create the connection string and
reference that project as a library inside the solution
If you want to be really secure your client is correct. Send the information to a dll that will communicate with the DB. This is a lot of work
Sources:
From ScottGu # http://msdn.microsoft.com/en-us/library/Aa302406
Scalability:
In regards to scalability: Creating\Editing registry keys across a web farm can be accomplished very easily, with custom admin software.
http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx
On a final note to all the people who voted me down. Security out of the box is just not enough. Security is an Art and not Science.
Hackers know where the password is stored by default......
ASP.NET 4.0 Fans
Microsoft makes it easy for asp.net 4.0 web sites to deploy registry settings:
http://msdn.microsoft.com/en-us/library/dd394698.aspx

Approaches to manage files on remote *NIX sever from Windows client applications

My Windows client application (written in C#) works with the remote MySQL database deployed on *NIX server.
I'm going to add the ability to store files on the server. I was never fond of storing files in DB, so the files will be stored in the file system. The application will need to upload, download, and delete files from server.
Any approach I can think of requires additional service to be deployed on server.
So far my favorite is SFTP*, but there are other solutions which are IMO inferior:
Web Service - are there any? haven't done any research in this direction.
FTP server - brings at least all the problems connected with protocol itself
WebDAV - interesting option, considering there is Apache module and .NET libraries
Some ad-hoc script (clearly the worst solution)
*I intend to use SharpSSH library, and public key authentication to access special account on the server which will be restricted to SSH operations only
Edit: corrected some terms confusion, thanks to #vartec

SCP has rather limited functionality. SFTP and FISH give you a lot more then plain SCP. (note, that SFTP should not be confused with FTPS)
Example of SFTP C# implementation.
Advantage over other options — no extra configuration at server side required.

I would use vsftpd on the *NIX server side: it's small and easy to configure, and I haven't had any problems with it since I initially set it up about 6 months ago so it's also reliable. I just use regular FTP, but you can do SSL with vsftpd if you're concerned about security.
On the client side there is this free, open source, FTP Client Library for C# made by Dan at C-SharpCorner.com. It works, and it's easy to extend its functionality to do more things. For example, I added a function for changing file permissions on the remote server.

putty and winscp are all you need.