Networking is the foundation of everything your VPS does. Every HTTP request, database connection, DNS lookup, and SSH session depends on a correctly configured network stack. Ubuntu 24.04 uses Netplan as its network configuration layer, UFW for firewall management, and systemd-resolved for DNS — and understanding all three is essential for running production services.
This guide covers the full spectrum of VPS networking: configuring static IPs and DNS with Netplan, adding secondary IP addresses, writing advanced UFW firewall rules, troubleshooting with professional-grade tools, configuring IPv6, and testing network performance. Whether you're debugging a connectivity issue or hardening your server's network posture, every command and concept you need is here.
Prerequisites
Before starting, you need:
- An Ubuntu 24.04 VPS. A Cloud VPS from MassiveGRID comes with networking pre-configured, but understanding these concepts lets you customize, troubleshoot, and secure your setup.
- Root or sudo access. If you haven't set up your server yet, follow our Ubuntu VPS setup guide first.
- SSH access to your server. Be careful when modifying network configuration remotely — a mistake can lock you out. Always have console access available as a backup.
Important: When modifying network configuration on a remote server, always test changes with
netplan trybefore applying them permanently. This command applies the configuration temporarily and reverts it after 120 seconds if you don't confirm — saving you from lockouts.
MassiveGRID Ubuntu VPS Includes
Ubuntu 24.04 LTS pre-installed · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · Independent CPU/RAM/storage scaling · 12 Tbps DDoS protection · 4 global datacenter locations · 100% uptime SLA · 24/7 human support rated 9.5/10
→ Deploy a self-managed VPS — from $1.99/mo
→ Need dedicated resources? — from $19.80/mo
→ Want fully managed hosting? — we handle everything
Understanding Netplan on Ubuntu 24.04
Netplan is Ubuntu's network configuration abstraction layer. You write YAML configuration files, and Netplan translates them into either systemd-networkd or NetworkManager directives. On server installations (including VPS), the backend is systemd-networkd.
Netplan configuration files live in:
/etc/netplan/— the main configuration directory- Files are processed in alphabetical order; later files override earlier ones
- The file format is YAML (indentation matters — use spaces, never tabs)
View the current Netplan configuration:
ls /etc/netplan/
cat /etc/netplan/*.yaml
A typical VPS Netplan configuration looks like this:
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 203.0.113.10/24
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
Check the current network state as Netplan sees it:
sudo netplan status
Static IP and DNS Configuration
Most VPS providers pre-configure your IP address. However, understanding the configuration is essential for troubleshooting and for adding secondary IPs.
Viewing Current Network Configuration
Check your current IP addresses and interfaces:
ip addr show
Check the default route (gateway):
ip route show default
Check current DNS servers:
resolvectl status
Modifying the Static IP Configuration
If you need to change your IP configuration (for example, after a provider migration), edit the Netplan file:
sudo nano /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 203.0.113.10/24
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses:
- 1.1.1.1
- 1.0.0.1
search:
- example.com
Always use netplan try when modifying network configuration remotely:
sudo netplan try
This applies the configuration and waits for you to press Enter within 120 seconds. If you lose connectivity (meaning the configuration broke something), it automatically reverts. Once you confirm it works:
sudo netplan apply
Changing DNS Servers
Ubuntu 24.04 uses systemd-resolved for DNS resolution. The DNS servers are configured in Netplan, but you can also configure fallback DNS directly:
sudo nano /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4
DNSOverTLS=opportunistic
Restart the resolver:
sudo systemctl restart systemd-resolved
Verify DNS resolution:
resolvectl query example.com
dig example.com
Setting Up Additional IP Addresses
Many VPS providers allow you to add secondary IP addresses for hosting multiple SSL sites, running multiple services on the same port, or separating traffic.
Adding a Secondary IP via Netplan
Edit your Netplan configuration:
sudo nano /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 203.0.113.10/24
- 203.0.113.11/24
- 203.0.113.12/24
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses:
- 1.1.1.1
- 1.0.0.1
Apply the configuration:
sudo netplan try
# If connectivity works, confirm:
sudo netplan apply
Verify the new addresses:
ip addr show eth0
You should see all three addresses listed on the eth0 interface.
Temporary IP Address (Non-Persistent)
To add an IP address that won't survive a reboot (useful for testing):
sudo ip addr add 203.0.113.15/24 dev eth0
Remove it:
sudo ip addr del 203.0.113.15/24 dev eth0
UFW Advanced Rules
UFW (Uncomplicated Firewall) is Ubuntu's frontend for iptables. If you followed our security hardening guide, you already have basic UFW rules in place. Here we cover advanced patterns.
Rate Limiting
UFW's built-in rate limiting blocks an IP that makes more than 6 connection attempts within 30 seconds:
sudo ufw limit ssh/tcp comment 'Rate limit SSH'
This replaces a simple allow rule and is highly effective against brute-force attacks. Apply it to any service facing the internet:
sudo ufw limit 443/tcp comment 'Rate limit HTTPS'
Port Ranges
Allow a range of ports (useful for passive FTP, game servers, or custom services):
sudo ufw allow 8000:8100/tcp comment 'Application port range'
sudo ufw allow 60000:61000/udp comment 'Mosh port range'
IP Whitelisting
Allow specific IPs to access services that should not be public:
# Allow only office IP to access SSH
sudo ufw allow from 198.51.100.50 to any port 22 proto tcp comment 'SSH from office'
# Allow only app server to access database
sudo ufw allow from 10.0.1.50 to any port 3306 proto tcp comment 'MariaDB from app server'
# Allow a subnet to access a monitoring port
sudo ufw allow from 10.0.1.0/24 to any port 9090 proto tcp comment 'Prometheus from internal network'
Denying Specific IPs
Block a specific IP address or subnet:
sudo ufw deny from 192.0.2.100 comment 'Block abusive IP'
sudo ufw deny from 192.0.2.0/24 comment 'Block abusive subnet'
For more effective IP blocking with automatic detection, see our Fail2Ban advanced configuration guide.
Inserting Rules at Specific Positions
UFW processes rules in order. To insert a rule before others:
# Insert a deny rule at position 1 (processed first)
sudo ufw insert 1 deny from 192.0.2.100 comment 'Emergency block'
Viewing and Managing Rules
# Show rules with numbers
sudo ufw status numbered
# Delete rule by number
sudo ufw delete 5
# Delete rule by specification
sudo ufw delete allow 8080/tcp
# Reset all rules (careful!)
# sudo ufw reset
Application Profiles
UFW supports application profiles that group common ports:
# List available profiles
sudo ufw app list
# Allow an application profile
sudo ufw allow 'Nginx Full'
sudo ufw allow 'OpenSSH'
# View profile details
sudo ufw app info 'Nginx Full'
Logging
Enable UFW logging to track blocked connections:
sudo ufw logging on
sudo ufw logging medium
View firewall logs:
sudo tail -50 /var/log/ufw.log
Log levels: off, low, medium, high, full. For production, medium provides good visibility without excessive noise.
Network Troubleshooting Tools
When something isn't connecting, you need the right diagnostic tools. Here's a comprehensive toolkit.
ip — Interface and Route Management
The ip command replaces the older ifconfig and route commands:
# Show all interfaces and addresses
ip addr show
# Show only IPv4 addresses
ip -4 addr show
# Show routing table
ip route show
# Show the route for a specific destination
ip route get 8.8.8.8
# Show link statistics (packet counts, errors)
ip -s link show eth0
# Show neighbor (ARP) table
ip neigh show
ss — Socket Statistics
The ss command replaces netstat and is significantly faster:
# Show all listening TCP ports
ss -tlnp
# Show all listening UDP ports
ss -ulnp
# Show established connections
ss -tnp
# Show connections to a specific port
ss -tnp sport = :443
# Show socket memory usage
ss -m
# Count connections by state
ss -s
The flags: -t (TCP), -u (UDP), -l (listening), -n (numeric, no DNS lookup), -p (show process).
dig — DNS Queries
Install dig if not present:
sudo apt install -y dnsutils
# Query A record
dig example.com
# Query specific record type
dig example.com MX
dig example.com AAAA
dig example.com TXT
# Query a specific DNS server
dig @1.1.1.1 example.com
# Short output (just the answer)
dig +short example.com
# Trace the full DNS resolution path
dig +trace example.com
# Reverse DNS lookup
dig -x 203.0.113.10
traceroute and mtr — Path Analysis
Install the tools:
sudo apt install -y traceroute mtr-tiny
traceroute shows the path packets take to a destination:
traceroute example.com
# Use TCP instead of ICMP (works when ICMP is blocked)
sudo traceroute -T -p 443 example.com
mtr combines traceroute and ping into a real-time display:
# Real-time path analysis
mtr example.com
# Generate a report (10 packets)
mtr -r -c 10 example.com
# Use TCP
mtr -T -P 443 example.com
Look for packet loss at specific hops. If loss appears at one hop but not subsequent hops, it's likely rate limiting on that router (not a real problem). Loss that persists through all remaining hops indicates a genuine issue at that point in the path.
tcpdump — Packet Capture
For deep network analysis, capture packets directly:
# Capture all traffic on eth0
sudo tcpdump -i eth0
# Capture only traffic to/from a specific host
sudo tcpdump -i eth0 host 203.0.113.50
# Capture only port 80 traffic
sudo tcpdump -i eth0 port 80
# Capture and save to file for analysis in Wireshark
sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 1000
# Capture DNS traffic
sudo tcpdump -i eth0 port 53
# Show packet contents in ASCII
sudo tcpdump -i eth0 -A port 80 -c 20
Important: On a production server, always limit captures with -c (packet count) or a host/port filter. Unrestricted captures can fill your disk quickly.
curl and wget — HTTP Testing
Test HTTP connectivity and response headers:
# Test a URL with verbose output
curl -v https://example.com
# Show only response headers
curl -I https://example.com
# Test with specific IP (bypass DNS)
curl -H "Host: example.com" http://203.0.113.10/
# Measure connection timing
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com
# Test from a specific source IP (if you have multiple IPs)
curl --interface 203.0.113.11 https://example.com
DNS Resolution Configuration and Troubleshooting
DNS issues are the most common cause of "it's not working" complaints. Here's how to diagnose and fix them.
How DNS Resolution Works on Ubuntu 24.04
Ubuntu uses systemd-resolved as a local DNS stub resolver. The resolution chain is:
Application → /etc/resolv.conf → systemd-resolved (127.0.0.53) → upstream DNS servers
Check the current resolver configuration:
resolvectl status
This shows which DNS servers are being used per interface, along with the DNSSEC and DNS-over-TLS status.
Common DNS Issues
Problem: DNS resolution fails entirely
# Check if systemd-resolved is running
sudo systemctl status systemd-resolved
# Test with a direct query to a public DNS
dig @1.1.1.1 example.com
# If direct query works but normal resolution doesn't,
# check /etc/resolv.conf
ls -la /etc/resolv.conf
cat /etc/resolv.conf
The /etc/resolv.conf file should be a symlink to /run/systemd/resolve/stub-resolv.conf. If it's not, recreate it:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
Problem: DNS resolution is slow
# Time a DNS query
time dig example.com
# Check if DNS-over-TLS is adding latency
resolvectl status | grep DNSOverTLS
# Try switching to faster DNS servers in Netplan
# Edit /etc/netplan/*.yaml and change nameservers to:
# 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google)
Problem: Stale DNS cache
# Flush the systemd-resolved cache
sudo resolvectl flush-caches
# Verify cache was cleared
resolvectl statistics
IPv6 Configuration on VPS
If your VPS provider assigns an IPv6 address, configuring it ensures your server is accessible on the modern internet.
Check IPv6 Status
# Check if IPv6 is enabled in the kernel
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
# 0 = enabled, 1 = disabled
# Show IPv6 addresses
ip -6 addr show
Configure IPv6 via Netplan
sudo nano /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 203.0.113.10/24
- 2001:db8::10/64
routes:
- to: default
via: 203.0.113.1
- to: "::/0"
via: "2001:db8::1"
nameservers:
addresses:
- 1.1.1.1
- 2606:4700:4700::1111
sudo netplan try
sudo netplan apply
Test IPv6 connectivity:
ping -6 ipv6.google.com
curl -6 https://ipv6.google.com
UFW with IPv6
Ensure IPv6 is enabled in UFW:
sudo nano /etc/default/ufw
Confirm this line exists:
IPV6=yes
UFW automatically creates both IPv4 and IPv6 rules when you add a rule. Verify:
sudo ufw status verbose
You should see entries like 22/tcp ALLOW IN Anywhere and 22/tcp (v6) ALLOW IN Anywhere (v6).
Disabling IPv6 (If Not Needed)
If your provider doesn't offer IPv6 or you want to disable it to reduce attack surface:
sudo nano /etc/sysctl.d/99-disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
sudo sysctl --system
Verify:
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
# Should show 1
Network Performance Testing with iperf3
To measure actual network throughput between your VPS and another machine, use iperf3.
Install on both the server and client:
sudo apt install -y iperf3
Basic Throughput Test
On the server side, start iperf3 in server mode:
iperf3 -s
On the client side, connect to the server:
iperf3 -c server-ip-address
This runs a 10-second TCP test and reports bandwidth, retransmits, and congestion window size.
Advanced Tests
# Test with multiple parallel streams
iperf3 -c server-ip -P 4
# Test UDP performance
iperf3 -c server-ip -u -b 1G
# Test for a longer duration (60 seconds)
iperf3 -c server-ip -t 60
# Test in reverse direction (server sends to client)
iperf3 -c server-ip -R
# Test with specific window size
iperf3 -c server-ip -w 256K
Interpreting Results
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec 0 3.12 MBytes
- - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec 0 sender
[ 5] 0.00-10.04 sec 1.10 GBytes 940 Mbits/sec receiver
Key metrics: Bitrate is your throughput. Retr (retransmits) should be low — high retransmits indicate network congestion or packet loss. Cwnd (congestion window) shows TCP's current sending window size.
Remember to close the iperf3 port in UFW after testing:
sudo ufw allow from client-ip to any port 5201 proto tcp comment 'iperf3 test'
# After testing:
sudo ufw delete allow from client-ip to any port 5201 proto tcp
Common Networking Issues and Solutions
Issue: SSH Connection Drops After a Period of Inactivity
Configure SSH keep-alives on the server side:
sudo nano /etc/ssh/sshd_config
ClientAliveInterval 60
ClientAliveCountMax 3
sudo systemctl reload sshd
This sends a keep-alive packet every 60 seconds and disconnects after 3 missed responses.
Issue: "Network is Unreachable" After Configuration Change
If you lose network access after a Netplan change, you need console access (VNC/IPMI through your VPS provider's panel). Then:
# Check if the interface is up
ip link show eth0
# Bring it up if down
sudo ip link set eth0 up
# Check for configuration errors
sudo netplan --debug apply
# If all else fails, restore the backup
sudo cp /etc/netplan/01-netcfg.yaml.bak /etc/netplan/01-netcfg.yaml
sudo netplan apply
Tip: Always back up your Netplan configuration before modifying it:
sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak
Issue: High Number of TIME_WAIT Connections
If ss -s shows thousands of TIME_WAIT connections:
sudo nano /etc/sysctl.d/99-network-tuning.conf
# Allow reuse of TIME_WAIT sockets
net.ipv4.tcp_tw_reuse = 1
# Increase local port range
net.ipv4.ip_local_port_range = 1024 65535
# Decrease FIN timeout
net.ipv4.tcp_fin_timeout = 15
sudo sysctl --system
Issue: "Too Many Open Files" Under High Connection Load
# Check current limits
ulimit -n
# Increase for the current session
ulimit -n 65535
# Make permanent
sudo nano /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535
Also increase the system-wide limit:
sudo nano /etc/sysctl.d/99-network-tuning.conf
fs.file-max = 2097152
sudo sysctl --system
Issue: Slow Network Performance
Tune the TCP stack for better throughput:
sudo nano /etc/sysctl.d/99-network-tuning.conf
# Increase TCP buffer sizes
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Increase connection backlog
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
# Enable TCP BBR congestion control (better than cubic for most VPS)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
sudo sysctl --system
Verify BBR is active:
sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr
TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) is Google's congestion control algorithm that significantly improves throughput on lossy networks. It's particularly effective for VPS servers communicating across the internet.
For maximum network performance, especially for latency-sensitive applications, consider a Dedicated VPS (VDS) which provides dedicated bandwidth allocation without shared-tenant contention.
Network Configuration Reference
Here's a summary of all the key files and commands covered:
| Purpose | File / Command |
|---|---|
| Network configuration | /etc/netplan/*.yaml |
| Apply network changes | sudo netplan apply |
| Safe apply with rollback | sudo netplan try |
| DNS resolver config | /etc/systemd/resolved.conf |
| DNS status | resolvectl status |
| Firewall rules | sudo ufw status numbered |
| Sysctl tuning | /etc/sysctl.d/99-network-tuning.conf |
| File descriptor limits | /etc/security/limits.conf |
| UFW logs | /var/log/ufw.log |
| Show interfaces | ip addr show |
| Show routes | ip route show |
| Show listening ports | ss -tlnp |
| DNS lookup | dig example.com |
| Path analysis | mtr example.com |
| Packet capture | sudo tcpdump -i eth0 |
| Throughput test | iperf3 -c server-ip |
Prefer Managed Networking?
If you'd rather not manage firewall rules, network tuning, DNS configuration, and troubleshooting yourself, consider MassiveGRID's Managed Dedicated Cloud Servers. The managed service handles network configuration, firewall management, DDoS mitigation, and 24/7 monitoring — so your infrastructure stays connected and secure without the operational overhead. Every managed server runs on a Proxmox HA cluster with automatic failover and 12 Tbps DDoS protection built into the network edge.
What's Next
- Ubuntu VPS initial setup guide — foundational server configuration
- Security hardening guide — comprehensive server hardening beyond firewall rules
- Fail2Ban advanced configuration — automatic IP banning for brute-force protection
- WireGuard VPN setup — encrypted tunnels between servers and remote access
- VPS monitoring setup — track network metrics, bandwidth usage, and connection states
- Optimize VPS performance — system-level tuning including kernel parameters and I/O scheduling