Every server Unmetered traffic, DDoS protection and IPMI included. No setup fees, no contract. Unmetered traffic on every server See pricing

FlexDedi
Custom quote Log in Deploy a server

Documentation

Connect servers over a private VLAN

Link your FlexDedi servers in one location over a free private VLAN, with a Netplan example, MTU checks, firewall rules and uses such as database replication.

  • 5 min read
  • Updated
  • FlexDedi Engineering

About this page

Applies to
Every FlexDedi dedicated server
Updated
November 2, 2026
On this page
  1. What the private network is
  2. 1. Create the VLAN interface with Netplan
  3. 2. Check the MTU
  4. 3. Firewall the private interface
  5. Use cases
  6. Database replication
  7. Proxmox VE cluster
  8. Backups

Servers in the same location can talk over a private network: a VLAN reserved for your servers, free of charge, with internal traffic not billed. Use it for replication, cluster traffic and backups that should never touch public addresses.

What the private network is

  • A VLAN for your servers only. It is a layer 2 network, separate from your public interface and its addresses.
  • Free. The private network costs nothing, and internal traffic is not billed.
  • Same location only. Servers in Frankfurt and Amsterdam cannot share a VLAN. To link locations, run an encrypted tunnel such as WireGuard over the public network, where traffic is unmetered anyway.
  • Your addressing. You assign private IPv4 addresses yourself, from a range such as 10.20.0.0/24. Pick one that does not overlap your VPN, office or container networks: Docker uses 172.17.0.0/16 by default.

For each server you need two details: the VLAN ID of your private network and the physical interface that carries it. If you do not have them, ask our support engineers. More background is on the private networking page.

A small address plan avoids mistakes later:

ServerRolePrivate address
db1PostgreSQL primary10.20.0.11
db2PostgreSQL replica10.20.0.12
backup1Backup target10.20.0.30

1. Create the VLAN interface with Netplan

On Ubuntu 24.04, put the private network in its own file so your public configuration stays untouched. Save this as /etc/netplan/60-private.yaml:

yaml
network:
  version: 2
  vlans:
    vlan100:
      id: 100
      link: enp1s0f0
      addresses:
        - 10.20.0.11/24

Replace 100 with your VLAN ID and enp1s0f0 with the parent interface, which must already be defined in your main Netplan file. Add no gateway: the route to 10.20.0.0/24 is created automatically, and your default route stays on the public interface.

If your private network arrives untagged on a second port instead, skip the vlans section and put the address on that port under ethernets.

Apply the configuration with an automatic rollback, check the interface, then reach a neighbor:

bash
chmod 600 /etc/netplan/60-private.yaml
netplan try
ip -br addr show vlan100
ping -c 3 10.20.0.12

2. Check the MTU

Every host on a VLAN must use the same MTU, 1500 bytes by default. Confirm that full-size packets pass without fragmentation:

bash
ping -M do -s 1472 -c 3 10.20.0.12

The 1472-byte payload plus 28 bytes of IP and ICMP headers makes exactly 1500. If small pings work but this one fails, a device on the path uses a smaller MTU.

Jumbo frames (MTU 9000) reduce per-packet overhead for bulk transfers, but only help if the whole path supports them. Ask our support engineers before raising the MTU, then set it on every server and test with -s 8972. If you link locations with WireGuard, keep its default MTU of 1420, which leaves room for the tunnel headers.

3. Firewall the private interface

Private does not mean trusted: a compromised server on the VLAN can reach every other one. With ufw, keep the default deny policy and open only the ports each server needs, from the private range only:

bash
ufw allow in on vlan100 from 10.20.0.0/24 to any port 5432 proto tcp
ufw allow in on vlan100 from 10.20.0.0/24 to any port 22 proto tcp

Also bind internal services to the private address so they never listen on the public interface:

  • PostgreSQL: listen_addresses = 'localhost,10.20.0.11'
  • MySQL and MariaDB: bind-address = 10.20.0.11
  • Redis: bind 127.0.0.1 10.20.0.11

Run ss -tlnp afterwards to see which address each service listens on.

Use cases

Database replication

Streaming replication keeps a standby copy of a PostgreSQL database in sync over the VLAN. On the primary, allow the replication user from the replica's private address in pg_hba.conf:

text
host  replication  replicator  10.20.0.12/32  scram-sha-256

On the replica, stop PostgreSQL, empty its data directory, then clone the primary. The -R option writes the standby configuration for you:

bash
sudo -u postgres pg_basebackup -h 10.20.0.11 -U replicator -D /var/lib/postgresql/16/main -R -X stream -P

More sizing advice for database servers is on the databases solution page.

Proxmox VE cluster

Corosync, the Proxmox cluster engine, needs low and stable latency, which servers in the same location provide. Proxmox VE uses /etc/network/interfaces rather than Netplan, so define the VLAN there and apply it with ifreload -a:

text
auto enp1s0f0.100
iface enp1s0f0.100 inet static
    address 10.20.0.21/24

Then create the cluster on the first node and join the others, pinning cluster traffic to the private addresses:

bash
pvecm create prod --link0 10.20.0.21          # on the first node
pvecm add 10.20.0.21 --link0 10.20.0.22       # on each additional node

To install and set up Proxmox VE itself, see our Proxmox guide.

Backups

Send nightly backups to a second server in the same location, such as a Storage 264 in Ashburn, Los Angeles, Amsterdam or Frankfurt:

bash
rsync -aHAX --numeric-ids --delete /srv/ backup@10.20.0.30:/backups/db1/srv/

Keep one more copy in another location as well. A backup in the same location does not protect you from an event that affects the whole site.