NexusSec.Replacing a firewall looks like a hardware job: unplug one box, plug in another. In practice the firewall is often doing a dozen jobs nobody wrote down, from handing out IP addresses to holding a VPN tunnel to a supplier that was set up years ago. A swap goes badly when one of those turns up on Monday morning.
Before: find everything the old firewall does
- The full configuration, exported and stored off the device, with screenshots of anything the export leaves out.
- Rules and NAT, including every port forward for a service reachable from the internet.
- VPN tunnels: site-to-site peers, their addresses, encryption settings and keys or certificates; remote-access users, groups and the client they use.
- DHCP and DNS, if the firewall serves them: scopes, reservations, forwarders and local records.
- Routing: static routes, dynamic routing, and any second internet link with its failover behaviour.
- Certificates for the admin interface, VPN and TLS inspection, with their expiry dates.
- Integrations: directory or RADIUS authentication, syslog, monitoring and email alerts.
- Licences and subscriptions on the old device that the new one needs equivalents for.
Clean up instead of copying
Vendors offer tools that convert one firewall's configuration into another's, and they save time. They also faithfully convert every rule nobody has used in years. Before converting, check rule hit counts on the old firewall: rules with no hits for months, duplicates, and rules hidden beneath broader ones can usually go. A replacement is the cheapest moment to fix the structure of the policy, because everything is being tested anyway. Zones first is the structure we move clients to.
Talk to the other end of every tunnel
A site-to-site VPN needs both ends to agree. If your public IP address or encryption settings change, the partner, branch or cloud provider at the other end must change their side at the same time. Contact them a week ahead, agree the settings in writing, and schedule their change in the same window. This is the item most easily forgotten.
The cutover plan
- Pick a window when a failure costs least, and tell the business.
- Pre-stage the new firewall: configured, licensed and on current firmware before the window, and tested on the bench where possible.
- Write the test list from the inventory: browsing, email, every published service tested from outside, every VPN tunnel, remote-access VPN for a test user, printing across zones, the ERP, and phones if VoIP crosses the firewall.
- If public IP addresses change, lower DNS TTLs a few days ahead, then update DNS records, partner allow-lists and anything else that filters by your address.
- Define the rollback: which cables go back, who decides, and the time by which the decision is made if tests are failing.
After: the first week
- Keep the old firewall racked and ready to reconnect for at least a week.
- Watch the deny logs for traffic the old firewall allowed and the new one does not, and decide case by case whether it should be allowed.
- Confirm the licences are active and the security services are updating.
- Update the network diagram and documentation, and store a backup of the new configuration off the device.
- Book a rule review for three months later, once the business has run through a full month-end on the new firewall.
If the replacement was triggered by a renewal quote, read before you sign the firewall renewal first. Our firewall migration service is this checklist carried out for you.
