A private network (VNet) is an isolated layer 2 LAN that only your servers are on. Included at no extra charge.
Open Network in the sidebar (/client/network/private/).
Why you would want one
By default two of your own servers reach each other over their public addresses, so the traffic leaves the platform and the listening port is exposed to everybody. A private network gives them a second interface that only your servers can reach, which lets the service stop listening publicly at all.
- Database and cache behind the application. PostgreSQL, Redis or Elasticsearch bind to the private address only. No public listener is left to scan, which is a stronger position than a firewall rule that allows one address.
- A router or firewall of your own. A dual-homed pfSense, OPNsense or VyOS VM takes the public address on WAN and the private network on LAN, and becomes the only way in or out for everything behind it.
- Servers with no public address. Deploy private-only and the server has no internet path at all. You reach it from the browser console or from another member of the same network.
- Environments that cannot reach each other. Staging on one network, production on another. Nothing routes between them, so the separation is not a rule you have to keep enforcing.
- Cluster traffic. etcd, Kubernetes node-to-node, database replication and health checks stay on the LAN instead of crossing public addresses.
What a private network does not do
Four limitations matter when you design the network:
- No routing between networks. Two VNets on the same account do not talk to each other unless one of your own servers forwards between them.
- No internet access. No platform NAT, no SNAT. A private-only server reaches the internet only through a router VM you build.
- No IPv6.
- Not encrypted. It is an isolated LAN, not a VPN. Traffic on it is not encrypted, so use TLS between services the way you would on any LAN.
A network also belongs to one location, and only servers in that same location can attach to it. That is usually the answer when a server you own does not appear in the attach list.
The MTU 1450 trap
Because the overlay costs 50 bytes, the private NIC's MTU is 1450 rather than 1500. Set MTU 1450 on the private interface inside the guest as well. If you do not, small packets work and large ones vanish, which presents as SSH connecting and then hanging, or a database transfer stalling at exactly the same point every time.
# Check what the guest thinks
ip -br link show
# Set it now (replace ens19 with your private NIC)
sudo ip link set ens19 mtu 1450
Make it survive a reboot in the guest's own network configuration.
How to create one
1. Create the network
Name it, then choose an RFC1918 CIDR with a prefix between /29 and /24, for
example 10.10.0.0/24. Ranges may overlap with other customers' networks: they
are isolated, so it does not matter. You can change the CIDR later from the
network's page. That does not rewrite addresses already on servers, so every
member and the optional gateway still have to sit inside the new range.
Up to 10 networks per account by default. Ask in a ticket if you need more.
2. Attach servers
Attach from the network's page, or choose the network at deploy and supply the
server's private address (private_network and private_ip from the API). You
pick the address; it must be inside the CIDR and not the network or broadcast
address.
A server may attach to more than one private network, on a NIC each. After
deploy, POST /api/v1/servers/<id>/networks attaches another VNet and
GET /api/v1/servers/<id> lists every membership as private_networks[].
Create and manage VNets at GET/POST /api/v1/networks.
3. Static addressing, or DHCP from your own box
By default the address you chose is written into cloud-init as a static ip= on
the private NIC. Turn that off for members that should get their address from a
DHCP server you run yourself, such as a pfSense or OPNsense VM.
LayerOne runs no DHCP and no DNS on a private network
Nothing hands out addresses unless you run something that does.
4. Set a gateway, if you have a router VM
The gateway is optional. Leave it blank for a plain isolated LAN. Set it to the LAN address of your own router VM and cloud-init writes it as the gateway on member NICs. Deploy and attach that VM first, so the address it should use already exists.
5. Reboot the members you changed
Attaching, detaching, changing the CIDR, changing the gateway and changing the cloud-init setting all need a boot before the guest picks them up. The members table says a reboot is needed while that is outstanding.
6. Set MTU 1450 inside each guest
Not optional, and not done for you. See the MTU trap above for what breaks when this is skipped.
7. Verify it works
From one member, to another:
ping -c 3 10.10.0.20
# Prove the MTU: this must not fragment
ping -M do -s 1422 -c 3 10.10.0.20
1422 is 1450 minus 28 bytes of IP and ICMP header. If that fails and a smaller
size works, the MTU is wrong somewhere.
Detaching and deleting
A network with members attached cannot be deleted, so detach them first. Networks survive the servers on them. A private-only server will not let you detach its last private NIC, because that would leave it with no network at all.
Related
- A private database behind a web server, the first bullet above done end to end
- pfSense, OPNsense and VyOS
- Public and private addressing
- Cloud firewall