Private VPN Server

What is a private VPN server used for?

A private VPN server puts an encrypted gateway that you control between your devices and the internet or your company systems. When a VPN (Virtual Private Network) connection is open, your device’s traffic travels encrypted to the server and reaches its destination from there. The target system sees the request coming from the VPN server’s static IP address, not from your home or café connection.

The most common reasons people run their own VPN server:

• Secure remote access: remote staff reach company servers, admin panels and internal apps only through the VPN.
• Static outbound IP address: connect from anywhere with the same address to services that work with IP allow lists, such as bank integrations, payment provider dashboards or client systems.
• Protection on public networks: make it harder for people on hotel, airport or café Wi-Fi to watch your traffic.
• Hiding management ports: close SSH, RDP and database admin interfaces to the internet and make them reachable only from the VPN network.
• Branch connectivity: build site-to-site tunnels that link networks in different locations.

How is your own VPN server different from a commercial VPN app?

Your own VPN server gives you a single IP address of your own and full control over configuration; commercial VPN apps offer many servers and locations shared by many users. They are designed for different needs and do not replace each other.

An important fact: your own VPN server does not make you anonymous. The server’s IP address is rented in your name, and you are responsible for traffic leaving it. A private VPN server is the right tool for business security, a static IP and internal network access. If you need to appear in different countries, commercial services fit better.

Should you choose WireGuard or OpenVPN?

For new setups WireGuard is the right choice in most cases, thanks to its simpler configuration, small codebase and high performance. OpenVPN is still valuable for its TCP support, mature enterprise tooling and ability to run over port 443 on restricted networks.

WireGuard’s limitation is that it uses UDP only, so it may fail to connect on some hotel or corporate networks that block UDP. If your team often works on such networks, consider also setting up OpenVPN over TCP as a fallback. IPsec/IKEv2 is preferred on devices where no extra app can be installed, since it works with operating systems’ built-in clients.

A practical rule: if you can install apps on your team’s devices and they mostly connect from home, office or mobile data, start with WireGuard. If corporate policies mean you must work on networks where only TCP 443 is open, choose OpenVPN as the main solution. Both can run on the same server on different ports; the only cost is keeping two configurations up to date.

Why does a VPN server need a KVM-based VPS?

A VPN server needs a KVM-based VPS because VPN software relies on deep operating system kernel features: virtual network interfaces (TUN), kernel modules and packet forwarding. KVM gives every virtual server its own kernel, so the WireGuard kernel module can be loaded, IP forwarding enabled and firewall rules written freely.

On kernel-sharing virtualisation (OpenVZ, LXC) these features are available only as far as the host allows; you may be forced onto slower user-space alternatives to WireGuard, or have to ask the provider for special settings for the TUN device.

Other features of LIONFIN VPS plans that matter for a VPN:

• Full root: needed to enable IP forwarding with sysctl, write NAT rules and manage the VPN service.
• Static IPv4: you use an address that never changes in client configurations and IP allow lists.
• Traffic allowance: all data passing through the VPN counts towards the server’s traffic; compare the traffic value in the package table with your usage.
• Network protection: network-level DDoS filtering with the RouteFence firewall reduces the risk of the VPN gateway becoming unreachable under attack.

How many resources does a VPN server need?

A VPN server is a very light workload; what matters is not memory but the number of concurrent users, the amount of data transferred and the CPU power needed for encryption. The table above gives approximate values; compare them with the current package table.

Points to consider when planning resources:

• Encryption load: every packet is encrypted and decrypted, so high-speed file transfers use CPU. WireGuard is efficient here; OpenVPN, being single-threaded, depends more on the speed of one core.
• Traffic allowance: if your team routes all internet traffic through the VPN (full tunnel), monthly data transfer grows quickly. Sending only company traffic through the tunnel (split tunnel) reduces both data use and latency.
• Bandwidth: the speed users perceive depends as much on their own internet connection as on the server’s capacity.
• Extra services: if internal DNS, monitoring or a web interface also run on the VPN server, add their share.

To monitor usage, the wg show command shows each client’s latest handshake and the amount of data transferred.

How do you set up a WireGuard VPN server?

A WireGuard VPN server is set up by installing the package, generating key pairs, writing the server configuration file, enabling IP forwarding and defining the clients.

1. Install: on Ubuntu, install the packages with apt install wireguard.
2. Keys: generate the server key pair with wg genkey | tee server.key | wg pubkey > server.pub; create a separate pair for each client too.
3. Configuration: in /etc/wireguard/wg0.conf, define the server’s address inside the VPN (for example 10.8.0.1/24), ListenPort = 51820 and a [Peer] block for each client.
4. Forwarding: enable the net.ipv4.ip_forward=1 line in /etc/sysctl.conf and add a NAT (masquerade) rule for the outbound interface.
5. Firewall: open 51820/udp in UFW.
6. Service: start the tunnel and enable it at boot with systemctl enable --now wg-quick@wg0.
7. Client: import the client configuration into the WireGuard app; generating a QR code makes it easy for mobile devices.

If you would rather avoid the command line, you can install open-source tools that provide a web interface for WireGuard with Docker; in that case take care not to expose the interface to the internet. See Docker hosting for running containers on a VPS.

How do you manage VPN access for a team?

Team VPN access is managed by giving each person and each device its own key, limiting which internal resources can be reached and removing a departing employee’s access immediately. Sharing one common configuration file with everyone means you never know who is connected and must change everyone’s configuration when someone leaves.

• One key per person: create a separate key pair for each employee’s laptop and phone, and name configuration files by person and device.
• Fixed internal VPN address: give each client a fixed internal address so firewall rules and logs show who accessed which system.
• Least access: use the AllowedIPs value in the client configuration to limit which networks go through the tunnel, and server-side firewall rules to limit which internal systems can be reached.
• Removing access: delete the departing person’s [Peer] block and reload the service; revoking the key is enough and other users are unaffected.
• Inventory: keep a simple table of which key belongs to whom and when it was created.

This setup ties access to internal systems to individuals and makes it auditable. You can also shrink the attack surface considerably by opening the RDP port of your Windows remote desktop servers only to the VPN network.

How do you keep a VPN server secure?

Because a VPN server is the front door to your company network, it should be one of your most tightly protected servers: only the necessary ports open, SSH protected by keys, software up to date and keys stored safely. A compromised VPN gateway lets an attacker reach internal systems as if they were a legitimate user.

1. Minimal ports: open only the VPN port and SSH in UFW. Once the VPN is up, consider making SSH reachable only from the VPN network.
2. SSH keys: disable password login, use keys and block brute-force attempts with Fail2ban.
3. Updates: apply operating system and VPN software updates regularly; automatic security updates can be enabled on Ubuntu.
4. Key security: the server’s private key must be readable by root only (chmod 600). Never send client configurations as plain text by email.
5. Single-purpose server: not running websites or other public services on the VPN gateway keeps the attack surface small.

At network level, LIONFIN infrastructure filters DDoS traffic with the RouteFence firewall and is monitored 24/7 by our SOC.

What are your legal responsibilities when running a VPN server?

As the person or organisation renting the server, you are responsible for all traffic leaving your own VPN server; using a VPN does not remove that responsibility. The server’s IP address appears in service records in your name, and complaints about activity from that address are directed to you.

• Who you give access to: open the VPN only to people you know and take responsibility for. Turning the server into a public VPN service exposes you to liability for other people’s actions.
• Logging policy: in business use, keeping connection logs helps you understand what happened during a security incident. Where logs contain personal data, observe your data protection obligations (such as the GDPR, or KVKK in Türkiye).
• Abuse: spam, attacks, unauthorised scanning and sharing infringing content breach the service agreement and can lead to suspension.
• Terms of other services: some online services restrict access from VPN or data center IP addresses; this does not mean your VPN server is faulty.

Your own VPN server is a powerful tool for legitimate business security and access needs. Keeping your purpose and your users clearly defined protects you both technically and legally.

How do you back up a VPN configuration?

The data to back up on a VPN server is small but critical: the server configuration file, the server’s private key, client definitions and firewall rules. If these are lost you must distribute new configurations to every client, which can take hours as the team grows.

1. Back up the /etc/wireguard/ folder (or the certificate infrastructure folder if you use OpenVPN) as an encrypted archive.
2. Add the UFW or iptables rules and sysctl settings to the archive.
3. Store the archive off the server in an encrypted location with restricted access; these files are the keys to your network.
4. Keep your person-to-key inventory up to date alongside the backup.

For the whole server, take a VPS snapshot; it is a quick rollback point before an operating system update or a major configuration change. With a backup, moving to a new server is easy too: install with the same keys and update only the IP address in the clients. If you do not want clients to change at all, defining the server address through a domain name makes moving even easier.

What are the most common VPN server problems?

The most common problems are a handshake that never happens, a tunnel that comes up but cannot reach the internet, DNS resolution errors and slowness caused by packet size (MTU).

No handshake

If the client has no “latest handshake” line in the wg show output, the connection is not reaching the server. Check that the UDP port is open in the firewall, that the server IP and port in the client are correct and that the keys are entered correctly on both sides.

Tunnel up but no internet

IP forwarding is off or the NAT rule is missing. Check that sysctl net.ipv4.ip_forward returns 1 and that the masquerade rule points at the correct outbound interface.

Sites do not open but IP addresses work

It is a DNS problem. Define a DNS server in the client configuration.

Some sites are slow or load only partly

Packets may be fragmenting inside the tunnel. Lowering the MTU value slightly in the client configuration usually fixes it.

Cannot connect on a hotel network

The network may be blocking UDP traffic. A fallback OpenVPN configuration running over TCP handles these cases.

What should you look for when renting a VPN server?

The criteria are virtualisation type, a static IP address, traffic allowance, connection capacity, root rights and server location. A VPN is a light workload, so a small plan is usually enough; choosing well means looking at network features more than CPU or memory.

1. KVM: the WireGuard kernel module and TUN device need a virtual server with its own kernel.
2. Static IPv4: an unchanging address is essential for allow lists and client configurations.
3. Traffic: if you route all traffic through the tunnel, monthly data transfer may be higher than you expect; check the traffic value in the package table.
4. Location: our servers are in Türkiye, so they suit teams and systems in Türkiye and the surrounding region, avoiding traffic detouring through a distant country.
5. Network protection: network-level DDoS filtering helps keep the VPN gateway reachable during an attack.
6. Scalability: being able to add resources without reinstalling matters as the team grows.

If you also need Windows desktops for your team behind the VPN, see the RDP server or VDS comparison.