Keep your server's IP address from being blocked
On some networks, a VPN server's IP address is blocked within hours of its first use. A few changes make your server much harder to block. Start with a second IP address for the server's outgoing traffic: it also tells you how the network is finding your server.
How a network finds a VPN server
A network can recognize the connection itself: the shape of its traffic, or how the server answers a probe. Cloak Mode leaves little there to match against. Your server allows it already, and each user turns it on in their app.
Or it can look at where the traffic goes. Some countries may use reputation systems for this: when many people reach local banks, government services and other local sites from the same foreign IP address, that address can be classified as a VPN or a proxy and added to a blocklist.
Or someone simply tells it. An access key is not encrypted, and anyone who has one can read the server's address from it, so share your keys with as few people as you can.
Use one IP to connect and another to go out
Give the server two public IP addresses, each with one job:
- The connection IP is the address your users' apps connect to. It is the one in their access keys.
- The outgoing IP is the address the server's traffic to websites leaves from. It is the only one websites see.
Websites can only report the address they see, so if an address gets flagged that way, it is the outgoing IP, and your users keep connecting to the other one. You can even replace a flagged outgoing IP without sending anyone a new key, because no key contains it.
VpnHood! SERVER has no setting for the outgoing IP. It reaches websites like any other program on the machine, so the operating system decides which address that traffic leaves from. You set the outgoing IP in the operating system, and the connection IP in VpnHood.
Add a second IP address
Order an additional IPv4 address from your hosting provider, and add it to the machine as the provider's documentation describes. Outside Docker, you can leave that part to the server: it adds an address it is set to listen on by itself.
Keep the machine's main address as the outgoing IP, and make the new one the connection IP. The operating system already sends its traffic from the main address, so there is less to change, and if your users can no longer reach the main address, it can still do this job.
Set the outgoing IP
This command shows the address the machine sends its traffic from: the one after src.
ip route get 1.1.1.1The output, with 198.51.100.20 as the outgoing IP
1.1.1.1 via 198.51.100.1 dev eth0 src 198.51.100.20 uid 0
cacheIf it shows the new address rather than the main one, the machine is set up the other way round. The simplest fix is to swap the roles: use the address it shows as the outgoing IP, and the other one as the connection IP.
In Docker, the server shares the host's network, so the host's settings apply.
On a cloud where the machine itself has only private addresses, such as AWS, Google Cloud, Azure or Oracle Cloud, each public IP is mapped to one of them. Use the private addresses on the machine and wherever the server listens, and the public connection IP wherever an address goes into the keys.
Make the server use the connection IP
Tell VpnHood! SERVER to listen on the connection IP only, and to put only that address in the access keys. The outgoing IP then does not answer as a VPN server, even to someone who probes it.
Set both yourself: left alone, the server learns its address from its outgoing traffic, on a managed server and a standalone one alike, so it would find the outgoing IP. Set your server's IP addresses shows how.
Keys you gave out before carry the old address. Keep the server listening on it for a few days, so apps pick up the new key by themselves, then remove it: until you do, the outgoing IP still answers as a VPN server.
Check the result
Connect from a device and look up your IP address on any site that shows it. You should see the outgoing IP.
If the connection IP stays reachable from then on, the network was finding your server by where its traffic goes. If it is still blocked within hours, the network is recognizing the connection itself: ask your users to turn on Cloak Mode, and give the server a domain name.
Connect through a domain name
Out of the box, the server presents a self-signed certificate with a made-up name. Give it a domain name you own, with a certificate from a certificate authority such as Let's Encrypt, and a connection to it looks like a visit to an ordinary website.
A domain also helps if the connection IP is blocked anyway. The keys then carry the domain, and apps look it up when they connect, so you can move the server to a new address, point the domain at it, and every key keeps working.
Connect through a domain name shows how, on a managed server and on a standalone one.
Put the server behind a reverse proxy
Where your setup allows it, you can also put the server behind a reverse proxy or a CDN such as Cloudflare, so your users connect to the proxy rather than to your server's IP address. Whether it is available, and how well it works, depends on the country and the network.
Keep your users' local sites off the server
Ask your users to turn on Exclude My Country in their app. Sites in their own country, such as banks and government services, then connect directly instead of through your server, so the pattern that gets a foreign address flagged never forms.
