Replacing a firewall looks like swapping hardware. In practice it is a migration of policy. These are the points where problems recur in the field.
1. Do not carry over policies nobody uses
A long-running firewall accumulates rules whose purpose no one remembers. A replacement is a good opportunity to clear them out.
- Identify policies with no recent hit count
- Consolidate duplicate and conflicting rules
Copying the rule base verbatim carries the existing security gaps across with it.
2. Verify NAT and rule order together
When the vendor changes, the order in which NAT and policy evaluation occur may differ. This is a leading cause of identical rules behaving differently. Externally published services — web, mail, VPN — should be checked individually before cutover.
3. VPN requires both ends to match exactly
When a site-to-site tunnel will not establish, it is usually one of the following:
- IKE version, encryption and hash algorithms, DH group
- Phase 1 / Phase 2 lifetimes
- Network ranges defined on each side
- Whether PFS is enabled
Changing one side alone will not bring the tunnel up, so agree the values with the counterpart administrator before starting.
4. For remote-access VPN, check authentication too
Configuring the appliance but omitting the authentication integration (local accounts, AD/LDAP, OTP) leaves users blocked at the door. Internal access scope and DNS settings after connection also need checking before the service is genuinely usable.
5. Agree the cutover window and rollback plan
- Schedule during low-impact hours
- Secure a configuration backup of the existing appliance
- Agree in advance what constitutes failure, and the procedure to revert
- Verify critical services against a checklist after cutover
Without a rollback plan, the decision to revert gets delayed when something goes wrong — and downtime grows accordingly.
6. Monitor continuously after cutover
Everything can look correct on the day and still reveal, later, that traffic occurring only at certain times — month-end batches, quarter-end closing — is being blocked. Continuing to review deny logs and traffic patterns after cutover surfaces missing policies early.
- Check sources and destinations that appear repeatedly in deny logs
- Verify business traffic that only occurs monthly or quarterly
- Compare traffic patterns before and after cutover
- Record any missing policy found, then apply it
NS&NET deploys firewalls and VPNs from vendors including Fortinet and NexG, and migrates existing appliances. If you are considering a replacement, we can start by reviewing your current configuration.