FreeBSD Colocation Handoff for Remote Recovery

What this FreeBSD colocation handoff covers

If your server is moving into colocation, the job is not done when the rack unit powers on. The real problems show up later, when you lose local access, need remote recovery, and discover the console, network, or disk layout was never tested end to end. This FreeBSD colocation handoff walks you through preparing the server for a data-centre handoff, checking remote access, confirming storage and network state, and keeping a rollback path ready if the move exposes a fault.

This workflow is written for Hostperl customers who own hardware in a rack, rely on remote hands, or need a clean cutover after a migration. If you are still choosing where to place the server, review dedicated server hosting and the operational expectations in colocation migrations planning clean data center move. For remote isolation and emergency access, the recovery pattern in Dedicated Server IPMI Setup for Safe Remote Recovery pairs well with the checks below.

Before you touch the server in the rack

Use a staging window, not a production traffic peak. You need a working SSH path, a console fallback, and enough access to change network settings without cutting yourself off completely. Keep the old root session open until the new login works from a second terminal.

For this tutorial, the example server IP is 203.0.113.10. Replace it with the public IP assigned to your colocated server. The hostname example is server.example.com, and the administrator account name is deploy.

On your local computer:

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with your real server IP. If your provider uses a non-root default account, use that account name with the same IP.

Confirm the FreeBSD release and current state

On the VPS as root:

freebsd-version

This confirms the FreeBSD release you are running. Capture the current network and service state before you change anything.

hostname
ifconfig -a
netstat -rn
service -e

Expected output: your hostname, interface names such as em0 or vtnet0, a valid default route, and a list of enabled services. If the default route is missing, fix connectivity before proceeding.

Create a non-root admin and keep root available for now

Colocation handoff goes more smoothly when you separate day-to-day access from break-glass access. FreeBSD uses the wheel group for administrative privilege. Create the account, add it to wheel, and prepare SSH keys before you lock down root access.

On the VPS as root:

adduser

Follow the prompts and create the user deploy. Give it a strong password for now, then add it to wheel:

pw groupmod wheel -m deploy

Create the SSH directory and install your public key. Run this from the root session only after you have the key file available locally.

mkdir -p /home/deploy/.ssh
fetch -o /home/deploy/.ssh/authorized_keys https://example.com/deploy-authorized-keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Replace the fetch URL with your real key source or paste the key manually with ee or vi. The permissions matter. SSH will ignore overly open key files.

Test the new login from a second terminal before you remove any root options.

On your local computer:

ssh deploy@203.0.113.10

Then verify sudo-like access with su - inside the FreeBSD shell:

su -
whoami
id

You should see root after the password prompt, then the account details for deploy after you switch back. Keep the original root SSH session open until this step succeeds.

Check networking for FreeBSD colocation handoff

Colocation failures often come from a simple mismatch: the wrong gateway, the wrong interface name, or the wrong address on the provider side. Verify that the NIC, route, and DNS records match the data-centre handoff sheet before you rely on remote support.

Review the active address and gateway:

ifconfig em0
route -n get default

If your interface is not em0, substitute the actual interface from ifconfig -a. You should see the public IPv4 address and the correct next hop.

For a basic reachability test, use:

ping -c 4 203.0.113.1
ping -c 4 1.1.1.1

Replace 203.0.113.1 with your provider gateway if different. If the gateway replies but the internet does not, the issue is usually upstream routing or ACLs, not the server itself.

Set persistent hostname, time, and boot services

A colocated server should survive a reboot without manual repair. On FreeBSD, that means the hostname, NTP, SSH, and firewall settings must live in /etc/rc.conf.

On the VPS as root:

ee /etc/rc.conf

Add or adjust these lines. Replace the hostname with your real FQDN if you have one.

hostname="server.example.com"
sshd_enable="YES"
ntpd_enable="YES"
pf_enable="YES"
cloned_interfaces=""
ifconfig_em0="inet 203.0.113.10 netmask 255.255.255.0"
defaultrouter="203.0.113.1"

Save and exit, then validate the file contents:

cat /etc/rc.conf

If your network uses DHCP, do not hardcode the address. Use the provider’s documented method instead. For static colo setups, the address block above should match the handoff sheet.

Build a cautious PF firewall for remote management

FreeBSD’s pf fits colo servers well because it is predictable and easy to recover from through console access. Start with a minimal ruleset that allows SSH and basic outbound traffic, then tighten it after you confirm your management path works.

On the VPS as root:

ee /etc/pf.conf

Use this starter ruleset:

ext_if = "em0"
set block-policy drop
set skip on lo
scrub in all
block all
pass out all keep state
pass in on $ext_if proto tcp to ($ext_if) port 22 keep state

Test the syntax before you enable it:

pfctl -nf /etc/pf.conf

You want no output. That means the ruleset parses correctly.

Now load and enable it:

service pf start
service pf status
pfctl -sr

Expected result: PF is running and the SSH pass rule appears in the loaded rules. If you already have a remote console path, you can later add a second rule for your management subnet before you remove any temporary access.

Protect storage and confirm boot safety

Colocation is where disk assumptions become expensive. If the machine uses ZFS, confirm the pool imports cleanly and that boot services are not waiting on missing devices. If it uses UFS, check /etc/fstab and make sure every device label is stable.

Check the storage view:

gpart show
zpool status
mount

If the machine has a ZFS pool, zpool status should report ONLINE for all devices. If it does not, stop and inspect cabling or remote-hands work before rebooting.

For a ZFS boot environment check, list datasets and snapshots:

zfs list
zfs snapshot -r zroot@pre-colo-handoff

That snapshot gives you a rollback point if the colocation move exposes a config mistake. If you are not using ZFS, take a filesystem-level backup before making further changes.

Validate remote recovery before you depend on the rack

A colo handoff only works if you can still reach the server when the network is wrong. That is why console access matters as much as SSH. If your hardware exposes IPMI, Redfish, or a provider serial console, test it now. If you do not have that yet, stop and request it before the move is considered complete.

For a FreeBSD-side connectivity check, confirm SSH is listening on the expected address:

sockstat -4 -l | grep sshd
service sshd status

Expected clue: sshd should be bound to port 22. If the service is up but unreachable, the firewall or upstream ACL is the likely cause.

From your local computer, test the login again:

ssh deploy@203.0.113.10

If this succeeds after PF is enabled, the basic colo handoff path is working.

Harden SSH after the second login works

Only after the non-root login succeeds and the firewall is active should you reduce root exposure. Keep the console path available in case you make a mistake.

On the VPS as the non-root sudo-equivalent user:

su -
ee /etc/ssh/sshd_config

Set these options:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Check the configuration syntax before restarting SSH:

sshd -t

No output means the config parses cleanly. Then restart the daemon:

service sshd restart

Open a fresh terminal and confirm that key-based login still works:

ssh deploy@203.0.113.10

Also verify that root login is now blocked:

ssh root@203.0.113.10

That attempt should be denied. If it still succeeds, reopen /etc/ssh/sshd_config and confirm the service was restarted, not just reloaded in your terminal.

Document the FreeBSD colocation handoff for remote hands and future incidents

Support teams work faster when the handoff notes are precise. Record the interface name, the management IP, the console path, the firewall state, and the rollback point. In colo operations, that is usually the difference between a ten-minute fix and a late-night chain of guesswork.

• Hostname: server.example.com
• Public IP: 203.0.113.10
• Primary interface: em0 or the actual interface you confirmed
• Firewall: PF enabled with SSH allowed
• Recovery point: zroot@pre-colo-handoff or equivalent backup
• Console access: IPMI, Redfish, or provider serial console

If you maintain multiple customer servers, this is where a disciplined colocation handoff saves support time. Hostperl customers who run remote-managed infrastructure often pair this kind of handoff with dedicated server hosting plans or a colo deployment that includes remote recovery procedures similar to the ones in Dedicated Server IPMI Setup for Safe Remote Recovery.

Troubleshooting the most common colo handoff failures

1. SSH works before PF, then stops after PF starts.
Diagnose it with:

pfctl -sr
sockstat -4 -l | grep sshd

If the SSH rule is missing, edit /etc/pf.conf, add the allow rule again, and reload with pfctl -f /etc/pf.conf. If SSH is bound only to localhost, fix sshd_config and restart the service.

2. The server boots, but the route is missing.
Check:

route -n get default
cat /etc/rc.conf | grep defaultrouter

If the default router is absent, add the correct gateway to /etc/rc.conf and reboot only after a console path is confirmed.

3. ZFS will not import cleanly after the move.
Inspect:

zpool import
zpool status

If disks are missing, do not force an import unless you have confirmed the hardware path. Use remote hands or the provider console to verify cabling, controller state, and drive presence.

4. You locked yourself out of SSH.
Use the console, then restore access by temporarily re-enabling key access or relaxing the firewall. Only after you regain entry should you re-apply the hardening changes one at a time.

Rollback and recovery

If the handoff exposes a fault, reverse the last change first. PF rules can be disabled from the console with service pf stop. SSH hardening can be backed out by restoring the previous /etc/ssh/sshd_config and running sshd -t before restart. ZFS gives you a snapshot rollback point, while UFS deployments should fall back to the last known-good backup and the console access path.

After recovery, repeat the same verification steps: network, SSH, firewall, storage, and reboot persistence. Do not assume the issue is fixed until the server survives a restart and you can log in from a second terminal again.

Final verification checklist

Run these checks from the server and from your local computer before you close the change window.

On the VPS as root:

service sshd status
service pf status
sockstat -4 -l | grep sshd
freebsd-version
zpool status

On your local computer:

ssh deploy@203.0.113.10
ssh root@203.0.113.10
ping -c 4 203.0.113.10

Expected result: the non-root login succeeds, root login is blocked, the server responds to ping if ICMP is allowed, PF is active, and storage reports healthy. If all of that is true, your FreeBSD colocation handoff is ready for real production use.

FAQ

Can I use this handoff process before the server is physically racked?
Yes. Prepare the SSH account, firewall, and recovery notes first, then apply the network settings once the hardware is in place.

Do I need ZFS for a colo server?
No, but you do need a tested rollback path. ZFS snapshots are convenient; backups and recovery media are mandatory either way.

What if my provider uses Redfish instead of IPMI?
That is fine. The goal is the same: a console path that works when SSH or routing does not.

Should I disable root login immediately?
Only after the non-root account works from a second terminal and you have tested console access. The safe sequence matters more than the setting itself.