How to Enable IPv6 on Your VPS Without Breaking SSH

Your VPS provider handed you an IPv6 address along with the usual IPv4 one, and now you're wondering whether you actually need to do anything with it. Short answer: yes, if you want it to work reliably - and if you get the firewall or SSH config wrong along the way, you can lock yourself out of a server you can only reach over IPv4 anymore. Here's how to turn it on properly.

Why bother with IPv6 at all

A growing slice of mobile networks and some ISPs (particularly in India and parts of Asia) are IPv6-only or IPv6-preferred at the network edge, falling back to IPv4 through carrier-grade NAT. If your VPS only answers on IPv4, those visitors still get through, but through an extra NAT hop that adds latency and occasionally breaks things like WebSockets or certain API integrations. Mail servers also increasingly expect a working AAAA + PTR pair for reputation checks. None of this is urgent, but it's cheap to set up correctly once and forget about.

Check what you actually have first

Most providers (DigitalOcean, Vultr, Linode-style KVM VPS, and Getwebup's own VPS plans) now assign a /64 IPv6 block per server by default, but it isn't always enabled on the interface out of the box. Check your provider's dashboard for the server's IPv6 address and gateway before touching config files - you'll need both.

From the VPS itself, confirm whether an address is already bound:

ip -6 addr show

If you see nothing beyond a fe80:: link-local address, IPv6 isn't configured on the interface yet even if the provider has allocated one to your account.

Step 1: Turn on IPv6 at the provider level

This step happens outside the server. In your VPS control panel, enable IPv6 for the instance if it isn't already, and note down three things:

• The IPv6 address assigned to your server
• The prefix length (almost always /64)
• The gateway address, if the provider uses static routing instead of SLAAC

Some providers auto-configure this via SLAAC and you won't need a gateway at all - the interface just picks it up. Others (DigitalOcean is a common example) require you to set a static IPv6 address and gateway manually in netplan.

Step 2: Configure the interface with netplan

On Ubuntu (the default OS for most Getwebup VPS images), network config lives under /etc/netplan/. Find your file:

ls /etc/netplan/

Open it and add the IPv6 address alongside your existing IPv4 block:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.10/24
        - 2001:db8:abcd:1234::2/64
      routes:
        - to: default
          via: 2001:db8:abcd:1234::1
      nameservers:
        addresses: [8.8.8.8, 2001:4860:4860::8888]

Replace the interface name, addresses, and gateway with the values your provider gave you. Apply it with:

sudo netplan try

Use netplan try instead of netplan apply the first time - it auto-reverts after 120 seconds if you get disconnected, which is exactly the safety net you want when editing network config over SSH. If nothing broke, confirm the change and run netplan apply to make it permanent.

On AlmaLinux/CentOS-style servers, the equivalent lives in /etc/sysconfig/network-scripts/ifcfg-eth0 with IPV6INIT=yes, IPV6ADDR=2001:db8:abcd:1234::2/64, and IPV6_DEFAULTGW set to your gateway.

Step 3: Open the firewall for IPv6 too

This is the step people forget, because IPv4 and IPv6 firewalls are separate rule sets even when the tool looks unified. If you're on UFW, good news - UFW manages both automatically as long as IPv6 is enabled in its own config:

sudo nano /etc/default/ufw
# confirm this line reads:
IPV6=yes

Then reload:

sudo ufw reload
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp

Any rule you add after this applies to both stacks. If you're managing raw iptables instead, remember every rule needs a matching ip6tables equivalent - they don't share state:

sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

If you're running CSF/ConfigServer Firewall on a cPanel VPS, check /etc/csf/csf.conf for IPV6=1 and make sure csf.ipv6allow or the standard port list includes 22 and 443 - CSF maintains a parallel IPv6 ruleset that's easy to leave half-configured.

Step 4: Don't let SSH lock you out

Before you close your current SSH session, open a second terminal and test the new address without disconnecting the first:

ssh -6 user@2001:db8:abcd:1234::2

If that connects, you're safe. If it hangs or refuses, your original IPv4 session is still open - fix the firewall or netplan config there rather than panicking. A common mistake is assuming sshd_config needs an IPv6-specific ListenAddress line; by default OpenSSH already listens on 0.0.0.0 and ::, so unless someone previously restricted ListenAddress to a single IPv4 address, SSH itself doesn't need touching - the firewall almost always is the actual blocker.

Step 5: Verify it end to end

Once the interface and firewall are sorted, confirm the full path works, not just the VPS side:

curl -6 -I https://yourdomain.com
ping6 2001:4860:4860::8888

Then add or confirm the AAAA record for your domain in cPanel's Zone Editor (or wherever your DNS is hosted) pointing to the new IPv6 address, and check it resolves:

dig AAAA yourdomain.com +short

Give it a few minutes for DNS to propagate, then test from a phone on mobile data if you can - that's the network most likely to actually route over IPv6 first.

Common pitfalls

For that last one, check your Nginx server block uses listen [::]:443 ssl; alongside listen 443 ssl;, or Apache's vhost has no explicit IP bound in the <VirtualHost> tag.

Prevention: keep both stacks in sync

Whenever you add a new firewall rule, SSL vhost, or DNS record going forward, make it a habit to add the IPv6 equivalent in the same change instead of as an afterthought. It takes ten extra seconds and avoids the slow drift where IPv4 is fully configured, IPv6 is half-configured, and nobody notices until a support ticket comes in about the site being unreachable on someone's phone.