Firewall Deployment and Policy Basics
A firewall deployment has two risky moments: the cutover, when the whole business depends on a device that has never carried real traffic, and the day you enable inspection and something stops working. Both are manageable if you plan an order of operations that lets you back out.
Before you start
- Your VLAN and addressing plan
- A list of what must be reachable from outside, and by whom
- Internet link details, including any static addressing
- A maintenance window, and the old firewall kept available to revert to
- Console access, so a policy mistake does not mean a site visit
A firewall's management interface must never be reachable from the internet. Restrict it to a management VLAN and specific administrator addresses, change default credentials, and enable multi-factor authentication if supported. Exposed management interfaces on network appliances are among the most reliably exploited things on the internet — they are scanned for constantly, and a firewall taken over is worse than no firewall.
Initial configuration
- Configure on the bench, not in production Build the whole configuration before it carries traffic. Cutover should be plugging in a device that is already correct.
- Update firmware first Firewall firmware carries security fixes. Do it before configuring, since updates can affect settings.
- Set admin credentials, management access, and time Strong unique credentials, management restricted by source, and accurate time — logs are worthless with a wrong clock, and certificates depend on it.
- Configure interfaces and addressing WAN, LAN, and any DMZ or segment interfaces. Match your VLAN plan.
- Set up DNS and DHCP if the firewall provides them In small deployments it often does. In larger ones leave it to your servers.
- Register the device and activate subscriptions Security services need activating before signatures download.
- Configure logging to somewhere off the device Local logs are small and vanish on failure. Send them somewhere you can search later — this is what makes an incident reconstructable.
- Back up the configuration before cutover And after every subsequent change.
Writing policy
The temptation is one permissive outbound rule and a handful of inbound exceptions. It works, and it means you have a router with logging rather than a firewall.
| Principle | In practice |
|---|---|
| Default deny | Everything not explicitly permitted is denied. Almost every firewall does this by default at the end of the rule set — the mistake is putting a broad permit above it. |
| Be specific | Source, destination, and service. "This server group to that database port" rather than "LAN to anywhere". |
| Order matters | Rules evaluate top down and the first match wins. A broad permit near the top silently disables everything specific below it. |
| Segment to segment, not just outbound | The valuable rules are frequently internal — guest cannot reach staff, cameras cannot reach finance, POS is isolated. |
| Name and comment every rule | Why it exists, who asked, and when. In two years nobody will dare remove an unexplained rule, so the set only ever grows. |
| Review periodically | Rules for decommissioned systems accumulate. An annual review keeps the set comprehensible. |
On an existing network nobody has a complete list of what talks to what. Deploying a strict policy on day one breaks things you did not know existed. Start with a working policy that logs, review what actually flows for a couple of weeks, then tighten based on evidence. That sequence is slower and vastly less disruptive than discovering a critical integration during business hours.
Inbound access and remote workers
- Expose as little as possible. Every published service is attack surface. Ask whether it genuinely needs to be reachable from the whole internet.
- Use VPN rather than publishing management protocols. Remote desktop and similar exposed directly are among the most common ransomware entry points. Put them behind a VPN.
- Require multi-factor authentication on VPN. Credentials leak. This is the control that makes leaked credentials survivable, and it is not optional in current conditions.
- Restrict by source where you can. If a partner needs access, permit their addresses rather than everyone's.
- Put published services in a DMZ, so a compromise does not land directly on your internal network.
- Log inbound access and actually look at it occasionally.
It is scanned continuously and it is a well-worn route into small business networks. If staff need remote access, provide it through a VPN with multi-factor authentication. This single decision closes off one of the most common ways organisations of this size get compromised, and it costs nothing beyond configuration time.
Enabling inspection without breaking things
- Enable one feature at a time. Application control, then IPS, then web and DNS filtering. If something breaks you know what caused it.
- Run IPS in monitor mode first where supported, and review what it would have blocked before letting it block.
- Leave TLS inspection until last, and expect an exclusion list for pinned applications — see what a next-generation firewall does.
- Watch throughput as you go. If performance drops sharply, the device may be undersized for the feature set — see firewall sizing.
- Tell people what is changing. A blocked category on day one produces support calls that are much easier if expected.
Cutover
| Step | Notes |
|---|---|
| 1. Confirm the configuration is complete | Interfaces, policy, VPN, logging, and subscriptions active. |
| 2. Take a backup of both firewalls | The new configuration and the old one you may need to revert to. |
| 3. Note the old device's WAN settings | Especially static addressing and any MAC-based provisioning by the ISP. |
| 4. Swap in the new firewall | Some ISP equipment caches the previous device's MAC; a modem power cycle is often required. |
| 5. Verify outbound connectivity | From a client on each VLAN, not just from the firewall itself. |
| 6. Verify inbound services and VPN | Test from outside the network, not from inside. |
| 7. Test the segmentation rules | Actively try to reach what should be blocked. |
| 8. Watch logs for the first day | Denied traffic reveals the things nobody documented. |
For a few weeks after cutover, an unconfigured spare is no help but the old device is a complete, known-working fallback. Do not wipe it until the new deployment has been through a full business cycle including month-end — that is when the integration nobody mentioned turns out to matter.
Official manufacturer and security resources
Configuration syntax and feature names are vendor-specific. Confirm against documentation for your exact model and firmware version.
Planning a firewall cutover?
Tell us what is being replaced, what has to stay reachable, and when your window is. We will help you sequence it so you can back out, and flag the settings most likely to lock you out.
Still stuck? Talk to someone who works on this hardware daily.
Tell us the model, what you have already tried, and what you are seeing. We will tell you whether it is a setting, a consumable, or a part — and we will say so if you do not need to buy anything.
