How to Configure a Private Network Between Bare Metal Servers

Table of Contents

• Step 1: Verify Your Bare Metal Server Prerequisites
• Step 2: Plan Your Private Network Architecture
  • Layer 2 vs Layer 3: Which Fits Your Setup?
• Step 3: Bare Metal Server VLAN Configuration
• Step 4: Private IP Address Configuration for Servers
• Step 5: Linux Network Interface Configuration

Last Updated: October 16, 2026

Step 1: Verify Your Bare Metal Server Prerequisites

Before you configure a private network between bare metal servers, confirm what your provider actually gives you. A bare metal network links two or more dedicated servers so they trade data without touching the public internet. At ServerPronto, we see this question constantly from agencies running databases, apps, and AI workloads across multiple machines.

Here is what you need in place first:

• Two or more servers in the same data center, ideally the same rack
• A second network interface on each server for private traffic
• Your private IP block and subnet details from your provider
• Root access so you can edit network configuration files
• A maintenance window, because interface changes can drop connectivity

The second interface matters most. Many providers hand you one public port and nothing else. Ask for a private interface before you deploy, not after. Adding one later usually means a rebuild.

Step 2: Plan Your Private Network Architecture

Good architecture decisions here save hours of rework later. Map your layout on paper before you touch a single config file.

Start with three questions:

1. How many servers will join the private network now, and in a year?
2. Do the servers sit in the same rack, the same data center, or multiple locations?
3. Does your traffic need encryption, or is the private link already isolated?

Same-rack servers usually share a switch, so a simple Layer 2 setup works. Servers in different racks or buildings need Layer 3 routing or an encrypted tunnel. Pick your private IP range from RFC 1918 space, which the IETF’s address allocation standards define for exactly this purpose.

Layer 2 vs Layer 3: Which Fits Your Setup?

Layer 2 connects servers on the same physical segment, like one VLAN on one switch. It is fast and simple, but it does not cross routers.

Layer 3 routes traffic between subnets. It works across racks and locations, and it scales further.

If your servers share a rack, start with Layer 2. If they live in multiple locations, go Layer 3 from day one.

Build & Price ?

Step 3: Bare Metal Server VLAN Configuration

VLAN configuration on bare metal usually happens on the provider side, not inside your operating system. A VLAN tags traffic so your servers stay isolated from other customers on the same physical switch.

Here is the typical flow:

1. Log into your provider’s control panel.
2. Create a VLAN and assign a VLAN ID.
3. Attach each server’s private interface to that VLAN.
4. Save and wait for the change to apply.

Once the VLAN is live, your servers can see each other on the private segment. They cannot see anyone else’s traffic. That isolation is the whole point.

A common mistake is skipping the VLAN and plugging both servers into the same flat network. It works, until another customer’s misconfigured machine floods the segment. Tag your traffic.

Step 4: Private IP Address Configuration for Servers

Private IP address configuration for servers follows one rule: every machine on the bare metal network needs a unique address in the same subnet.

A typical plan looks like this:

• Server A: 10.0.0.1
• Server B: 10.0.0.2
• Server C: 10.0.0.3
• Subnet mask: 255.255.255.0
• Gateway: 10.0.0.254 (only needed for Layer 3)

Write this table down before you start. Assigning the same address twice causes an IP conflict, and the second server simply will not connect.

Step 5: Linux Network Interface Configuration

Linux network interface configuration is where most of the real work happens. The steps differ by distribution, so know which one you run.

On modern Ubuntu and Debian systems, edit the Netplan file:

network:
  version: 2
  ethernets:
    ens224:
      addresses:
        - 10.0.0.2/24
Then apply it:

```bash
sudo netplan apply
On RHEL, Rocky, and AlmaLinux, create a file in `/etc/sysconfig/network-scripts/`:

```bash
DEVICE=ens224
BOOTPROTO=none
IPADDR=10.0.0.2
PREFIX=24
ONBOOT=yes
Then restart the interface:

```bash
sudo nmcli connection reload
sudo nmcli connection up ens224
The [official Netplan documentation](https://netplan.io/faq) covers the YAML syntax in full if you need edge cases.

## Step 6: Security and Access Control for Private Traffic

A private network is isolated, but isolated is not the same as secure. Treat private traffic with the same care as public traffic.

Build these controls in from the start:

- **Firewall rules** that allow only the ports you actually use
- **SSH keys** instead of passwords between servers
- **Encrypted tunnels** like WireGuard for traffic crossing untrusted links
- **Access logs** so you can trace who connected to what

For firewall rules, allow only what each service needs. A database server might accept port 5432 from one app server and nothing else. Everything else gets dropped.

If your servers sit in different locations, wrap the private link in a WireGuard tunnel. It encrypts the traffic end to end, and it is far simpler than most VPN setups. The [WireGuard project documentation](https://www.wireguard.com/quickstart/) walks through the key exchange.

## Step 7: How to Troubleshoot Server Network Connectivity

When a private link fails, work from the bottom up. Start with the physical layer, then move to addressing, then routing.

Run these checks in order:

1. **Interface up?** Run `ip link show` and confirm the private interface shows `UP`.
2. **Address assigned?** Run `ip addr show` and check the IP is on the right interface.
3. **Can you reach the neighbor?** Run `ping 10.0.0.1` from the other server.
4. **Route correct?** Run `ip route` and confirm the subnet routes through the private interface.
5. **Firewall blocking?** Temporarily check your rules with `sudo iptables -L -n`.
6. **VLAN tagged?** Confirm the VLAN ID matches on both ends.

If ping works but your app does not, the problem is almost always a firewall rule or a service bound to the wrong interface.

### Common Mistakes to Avoid

Most private network failures trace back to a short list of errors:

- Assigning duplicate IP addresses across servers
- Forgetting to bring the second interface up on boot
- Mixing VLAN IDs between servers
- Leaving the default route pointed at the private interface
- Testing only with ping and never checking the actual service port


<div style="margin:1.5rem 0; padding:16px 20px; background-color:#f0fdf4; border-left:4px solid #bbf7d0; border-radius:0 8px 8px 0;">
<strong style="display:block; margin-bottom:4px; color:#111827; font-size:14px;"> Key Takeaway</strong>
<span style="color:#374151; font-size:15px; line-height:1.6;">Ping proves the link exists. It does not prove your application can talk across it. Always test the real port your service uses before you call the job done.</span>
</div>

## Conclusion

Getting a private network between bare metal servers right comes down to planning your addressing, tagging your VLANs, and testing beyond a simple ping. When you run databases, apps, and [AI workloads](/spu/2026/09/dedicated-gpu-cost-machine-learning-2026/) across multiple machines, the private link is the backbone that keeps everything fast and isolated.

That is where ServerPronto fits. We provide bare metal, GPU, and private cloud environments with full root access, a private interface ready for your VLAN, and 2-hour provisioning so your servers are live the same day. Our 24/7 on-site technicians handle the hardware, and our month-to-month billing means no contracts and no surprise fees.

Build & Price your configuration and get your private network running without the guesswork.


<section style="margin:3rem 0 2rem 0;" itemscope itemtype="https://schema.org/FAQPage"><h2 style="font-weight:700; margin:0 0 4px 0;">Frequently Asked Questions</h2><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">How do you connect two bare metal servers on a private network?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Connect both servers to the same switch or VLAN, assign each a private IP address from the same subnet, and configure the network interfaces on each machine. For example, set server A to 10.0.0.1/24 and server B to 10.0.0.2/24 on a dedicated private interface. Then verify connectivity with ping and confirm firewall rules allow traffic on the ports your applications use. This keeps inter-server traffic off the public internet entirely.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">Can bare metal servers communicate over a private network without internet access?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Yes. A private network between bare metal servers operates independently of public internet routing. As long as both servers connect to the same switch, VLAN, or private subnet, they can exchange traffic using private IP addresses. This is common in data centers where internal replication, database clustering, and backup traffic stay on isolated network segments. You still need internet access separately if the servers must reach external services or receive updates.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">How do you troubleshoot server network connectivity between bare metal servers?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Start with ping to confirm basic reachability, then check the route table with ip route to verify the correct gateway and subnet. Use ip addr to confirm the private IP is assigned to the right interface. If ping works but applications fail, test specific ports with tools like nc or ss. Check firewall rules on both servers with iptables -L or nft list ruleset. Also verify VLAN tagging matches on both ends of the link.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">How do you secure traffic between servers on a private network?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Even on a private network, encrypt sensitive traffic with WireGuard or another VPN tunnel between servers. Restrict firewall rules so only required ports and source IPs can communicate. Use separate VLANs to isolate workloads, such as keeping database replication traffic apart from web tier traffic. For remote access, require SSH key authentication and disable password logins. Monitoring tools should alert on unexpected traffic patterns or failed connection attempts.</p></div></div></section>