Skip to content
+1 (813) 212-3723 [email protected]

Private networks

Isolated LANs for your account. Pick an RFC1918 CIDR, attach servers, and use MTU 1450.

5 min read

A private network is an isolated layer 2 LAN that only your servers are on. Included at no extra charge.

Open Networking → Private networks in the portal (/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 private networks 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 (private_network from the API). No private IP is requested or allocated by LayerOne.

A server may attach to more than one private network, on a NIC each. After deploy, POST /api/v1/servers/<id>/networks with {"network": 12} attaches another private network; private_networks[] lists each attachment. New attachments have a null address; any old recorded address is historical, not a live DHCP lease.

3. Configure addresses in your guest or DHCP server

Set static addresses inside the guest, or run your own DHCP service on this private network, such as pfSense or OPNsense. LayerOne does not write private IPs or gateways into Cloud-Init. Existing guest settings are not automatically rewritten.

LayerOne runs no DHCP and no DNS on a private network

Nothing hands out addresses unless you run something that does. Enable DHCP on the guest interface if it should request a lease.

4. Optional gateway reference

The gateway field records your router VM's LAN address for reference only. Configure guest routes inside the OS or through your DHCP service. Leave it blank if you do not need that reference.

5. Enable the interface in the guest

The NIC is attached by the platform. Your guest OS must bring it up and configure its address and routes; some operating systems require a reboot to detect a new NIC. Changing the network's CIDR or gateway reference does not configure the guest.

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.

Still stuck

Ask AI or open a ticket.

Ask AI in the portal answers from these docs. For anything it cannot settle, open a ticket and an engineer replies by email.

Open the portal Contact