Unofficial, customer-managed guide: BinaryLane does not currently support moving a public IPv4 address directly from one server to another. This guide describes one workaround: retain the existing server as a small proxy and forward traffic to its replacement. It is not an IP migration, and you are responsible for reviewing, operating, and securing the configuration.

Use this only where an existing public IPv4 address cannot yet be changed because it is referenced by DNS records, allowlists, customers, or other remote systems. Where possible, update those references to use the new server directly instead.

You need:

• root or sudo access to the current server that holds the IP address;
• root or sudo access to the destination server;
• the public IPv4 address on the current/proxy server and the destination server; and
• a plan for management access to the proxy after forwarding is enabled.

This example is for Ubuntu and IPv4. It assumes SSH runs on TCP port 22 and therefore keeps that port on the proxy. Change the rule before applying it if you use another SSH port.

If the old server has only this purpose after the move, consider resizing it to a small plan and retaining it as a thin proxy. The proxy needs little CPU or memory, but it must remain online and have enough transfer allowance for all forwarded traffic.

If the old server has multiple IP addresses and still hosts other services, target only the additional IP address that needs to remain reachable.

The proxy receives traffic at the existing public IP address, rewrites its destination to the new server, and rewrites replies so they return through the proxy.

Client -> existing/proxy IP -> destination server
Client <- existing/proxy IP <- destination server

The rules below use nftables destination NAT (DNAT) and source NAT (masquerade).

Run these commands on the server that currently has the IP address you want to retain.

Set the existing/proxy and destination addresses:

PROXY_IP="203.0.113.10"
DESTINATION_IP="198.51.100.20"

Replace the example addresses with your own values.

Install nftables, enable IPv4 forwarding, and start the nftables service:

sudo apt update
sudo apt install -y nftables
 
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-ip-proxy.conf
sudo sysctl --system
sudo systemctl enable --now nftables

Create rules that forward TCP traffic other than SSH, plus UDP traffic, to the destination server:

sudo tee /etc/nftables.conf >/dev/null <<EOF
#!/usr/sbin/nft -f
 
flush ruleset
 
table ip proxy {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
 
    ip daddr $PROXY_IP tcp dport != 22 dnat to $DESTINATION_IP
    ip daddr $PROXY_IP udp dnat to $DESTINATION_IP
  }
 
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
 
    ip daddr $DESTINATION_IP masquerade
  }
}
EOF
 
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

If you do not use SSH on TCP port 22, change the exclusion before applying the rules. Otherwise, you may forward your management access to the destination server.

Forwarding only the services you need is usually easier to review and maintain. For example, to forward HTTP and HTTPS only:

sudo tee /etc/nftables.conf >/dev/null <<EOF
#!/usr/sbin/nft -f
 
flush ruleset
 
table ip proxy {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
 
    ip daddr $PROXY_IP tcp dport { 80, 443 } dnat to $DESTINATION_IP
  }
 
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
 
    ip daddr $DESTINATION_IP tcp dport { 80, 443 } masquerade
  }
}
EOF
 
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

First verify that a service responds directly on the destination server:

curl -I http://DESTINATION_IP/

Then test through the retained IP:

curl -I http://PROXY_IP/

If the proxy is working, the request to the proxy IP should return a response from the service on the destination server. You can also inspect established TCP connections on the destination server:

sudo ss -tn state established

• The destination normally sees the proxy's IP address, not the original client address. If the application needs the client IP, use an application-level proxy such as Nginx or HAProxy, or PROXY protocol where the destination supports it.
• The proxy must stay online. Cancelling, powering off, or misconfiguring it stops traffic to the retained IP from reaching the destination.
• Traffic traverses both servers, which can add latency and consumes transfer on the proxy.
• Firewalls on both servers must allow the intended traffic. If you use the BinaryLane External Firewall, ensure its rules match this traffic path.
• IPv6 needs separate planning and IPv6-specific rules; this guide does not configure it.

When you no longer need the retained IP, remove the forwarding rules and disable IPv4 forwarding:

sudo nft flush ruleset
sudo tee /etc/nftables.conf >/dev/null <<EOF
#!/usr/sbin/nft -f
 
flush ruleset
EOF
 
sudo rm -f /etc/sysctl.d/99-ip-proxy.conf
sudo sysctl -w net.ipv4.ip_forward=0

You can then cancel, resize, or repurpose the proxy server.

BinaryLane Support may assist with general platform and public API questions. Proxy setup, firewall and NAT policy design, operating-system maintenance, and troubleshooting within this configuration are customer-managed work.