Firewall replacement and migration
Most of a firewall replacement is what’s on the old one: rules nobody remembers adding, NAT written in one vendor’s logic, and tunnels to sites the client doesn’t control. We review all of it, rebuild it properly on the new firewall, and cut over in an agreed window.
| # | Rule | From | To | Service | Hits | Review note | |
|---|---|---|---|---|---|---|---|
| 1 | Outbound-All | LAN | WAN | any | LAN to WAN, any service | 1,284,330 | RewriteBusy, and far too broad. Replace with the services the logs show are really used. |
| 2 | RDP-Temp | WAN | 10.0.1.20 | TCP 3389 | WAN to 10.0.1.20, TCP 3389 | 4,112 | RaiseRemote desktop open to the internet. Raised with you before cutover rather than carried across as is. |
| 3 | Old-SQL-2014 | LAN | 10.0.1.14 | any | LAN to 10.0.1.14, any service | 0 | RetireThe server it was written for is gone. |
| 4 | Outbound-Web | LAN | WAN | HTTP, HTTPS | LAN to WAN, HTTP and HTTPS | 0 | MergeSits below rule 1, so it can never match. Its intent belongs in the rewrite. |
| 5 | Payroll-SFTP | 10.0.1.30 | 203.0.113.8 | TCP 22 | 10.0.1.30 to 203.0.113.8, TCP 22 | 0 | Check firstZero hits, but the counters reset at the last reboot and payroll runs fortnightly. Read the logs before calling it unused. |
| 6 | Scan-to-Email | 10.0.2.40 | WAN | TCP 587 | 10.0.2.40 to WAN, TCP 587 | 2,301 | KeepNeeded. Narrow the destination to the mail service and name the rule for the copier. |
What vendor conversion tools miss
Most vendors offer a tool that reads another vendor’s configuration and writes their own. It’s a useful start, but the output loads cleanly, carries every old mistake across, and adds new ones where the two platforms handle traffic differently.
-
Where NAT sits in the rule
For a published server, a Palo Alto Networks policy names the public address and the inside zone. A Cisco ASA access list names the server’s real inside address. A FortiGate policy names a virtual IP object. Copy one into another line by line and you get a rule that is valid, loads without complaint, and doesn’t match the traffic it was written for.
-
What gets through without a rule
An ASA lets traffic flow from a higher security level to a lower one without any access list. Most other platforms deny whatever isn’t explicitly allowed. Export the ASA’s rules and you’ve missed all the traffic it never needed a rule for.
-
Applications or ports
Some platforms allow an application by identity rather than by port. Moving off one means working out which ports each of those rules needs. Moving onto one is the chance to replace “TCP 443 to anywhere” with the applications that use it.
-
Tunnels have two ends
Each site-to-site VPN has to agree with the far end on encryption, identities and the networks each side offers. One platform builds a tunnel per pair of subnets, another builds one tunnel and routes across it. Get the networks wrong and the tunnel shows as up while passing nothing. The far end is often a supplier’s or head office’s firewall that nobody on your side can change.
We work between these vendors in either direction, and between an old and new model from the same vendor when the old one has reached end of life.
- Fortinet
- Palo Alto Networks
- Cisco
- Meraki
- SonicWall
- WatchGuard
- Sophos
- Check Point
- Juniper
- Huawei
The jobs that aren’t in the rule base
Firewalls pick up work over the years. None of it shows up in a rule review, and each piece missed is a phone call the morning after cutover. We find these on the old firewall and set each one up on the new one.
Handing out addresses
DHCP scopes, reservations for printers and phones, and the options the phones use to find their system.
Name resolution
DNS forwarders, local records, and the dynamic DNS name remote staff connect to.
Routes to elsewhere
Static routes to a voice network, a second site, or subnets behind a core switch.
Extra public addresses
Addresses from the ISP’s block that the firewall answers for on behalf of servers behind it.
Phone calls
SIP handling, often called SIP ALG, which is on by default on some platforms and off on others. A common cause of one-way audio after a firewall change.
Certificates
The certificate on the VPN portal, and any inspection certificate the client’s devices have been told to trust.
Remote access
VPN users and groups, the directory or MFA sign-in behind them, and the client software already on staff laptops.
Logging and monitoring
Syslog, SNMP and alert destinations that your monitoring depends on.
The ISP’s equipment
Upstream modems that hold the old firewall’s MAC address and ignore the new one until they’re restarted or the lease is released.
The cutover window
-
Built and checked before it goes near the network
The new firewall is fully configured ahead of time and checked against the old configuration. Anything that depends on someone else, such as a supplier’s side of a VPN, is agreed in advance. So is the way back: the old firewall is left exactly as it was, so reversing the change means moving cables, at a point decided beforehand.
-
The swap
Someone on site moves the cables. We work remotely: bring the interfaces up, get the ISP equipment talking to the new firewall, and watch each tunnel negotiate.
-
Tested service by service
A rule can be correct and the service still broken, so the tests are the things the client uses, run from where they use them.
-
Written up as it stands
The as-built documentation is taken from the running configuration after cutover, rather than the plan, so it matches what’s running.
After the swap
The kind of checks a cutover plan lists, set for each client.
- Mail arrives from outside and goes out
- Calls ring in and out, with audio both ways
- Each site-to-site tunnel passes traffic, not just shows as up
- Remote staff connect and reach what they need
- Published services answer from the internet
- Business applications reach their cloud services
- Your monitoring sees the new firewall
What the client ends up with
-
A rebuilt rule base
Rules, NAT, VPNs and interfaces built natively on the new firewall. Unused, duplicate and overly broad rules are dealt with rather than carried across, and each rule is named for what it’s for.
-
A cutover plan
The order of work, what happens on site, the service tests and the point at which you’d go back. Agreed with you before the window.
-
As-built documentation
Interfaces, rules, NAT, VPNs and the jobs listed above, as they stand on the new firewall. Written for your team, who look after it next.
Hand us the firewall, keep the client
Delivered remotely as a white-label project, under your brand or as your named partner. We quote and invoice you at a fixed price for the agreed scope, and the ongoing service stays with you.