A firewall sits between your network and the internet and decides what traffic is allowed through. When it blocks something it shouldn’t, or a VPN won’t connect, the symptoms often look like “the internet is broken” for one app, one user or one office. This guide explains how firewalls work in plain language, then walks through the most common problems on FortiGate, SonicWall and Cisco firewalls.
Before you change anything: export or back up the current firewall configuration and write down every change you make. A single wrong rule can cut off the whole office, including your own remote access to the firewall.
How a firewall decides what to allow
Most business firewalls check traffic against a list of rules (also called policies) from top to bottom. The first rule that matches wins. If nothing matches, the traffic is dropped by an implicit “deny all” rule at the bottom. Most firewalls are also stateful: once outgoing traffic is allowed, the replies are allowed back in automatically.
→
→
→
Quick first checks
- Is the problem for everyone, one group, or one device? One device usually points to that device, not the firewall.
- Did anything change recently: a firmware update, new rule, new ISP equipment, expired license or certificate?
- Check the firewall’s traffic or event log for the device’s IP address at the time of the failure. A “deny” entry tells you which rule blocked it.
- Check the firewall’s dashboard for high CPU or memory, and that the WAN interface is up with an IP address.
Fortinet (FortiGate) issues
On a FortiGate, the most useful tool is the debug flow, which shows exactly how the firewall handles one connection, including which policy matched and why traffic was dropped. Run it from the CLI and replace the address with the device you are testing.
diagnose debug reset
diagnose debug flow filter addr 192.168.1.50
diagnose debug flow show function-name enable
diagnose debug flow trace start 20
diagnose debug enableReproduce the problem, then stop the debug:
diagnose debug disable
diagnose debug resetLook for lines such as “Denied by forward policy check” (no policy allows it) or “allowed by Policy-…” (the firewall allowed it, so look elsewhere). Also check that security profiles such as web filtering or application control are not blocking the site; those blocks appear in the security logs, not the traffic log.
SonicWall issues
SonicWall firewalls have a built-in Packet Monitor (under Monitor or Investigate, depending on the firmware version). Set a filter for the device’s IP address, start the capture, reproduce the problem and look at whether packets are shown as forwarded or dropped, along with the drop reason.
- Check the Logs page for blocked connections from the device’s IP address.
- If only some websites fail, check Content Filtering, Gateway Anti-Virus or App Control. These services can block traffic even when the access rule allows it.
- Check that security service licenses have not expired. What happens on expiry depends on the service and settings, so confirm in the license page rather than guessing.
Cisco firewall issues
On a Cisco ASA, packet-tracer simulates a packet and tells you, step by step, which rule, NAT and route it hits and whether it would be allowed. It does not need real traffic.
packet-tracer input inside tcp 192.168.1.50 12345 8.8.8.8 443 detailed
show conn address 192.168.1.50
show xlate local 192.168.1.50
show access-list | include hitcntIn the packet-tracer output, the final “Result” and “Action: drop” line tells you which phase blocked the traffic. show conn shows live connections, and show xlate shows NAT translations. Cisco Secure Firewall (Firepower) devices managed by FMC also offer a packet tracer and a capture tool in the management interface.
Firewall rules and NAT
Most firewall problems come down to rule order or NAT. NAT (Network Address Translation) changes private addresses such as 192.168.x.x into your public address on the way out, and maps a public address and port to an inside server on the way in (port forwarding).
| Symptom | Likely cause | What to check |
|---|---|---|
| New rule doesn’t work | A deny rule above it matches first | Move the rule up, or check hit counts on rules above it |
| Inside server not reachable from the internet | Port forward (inbound NAT) missing or rule missing | You usually need both a NAT entry and an allow rule |
| Works by IP address, not by name | DNS is blocked or not working | Allow DNS (UDP/TCP 53) to your DNS servers |
| Outbound internet fails for one subnet | No outbound NAT for that subnet | Check the source NAT / outbound NAT for the new range |
| Port forward works from outside, not inside | Hairpin (loopback) NAT not configured | Use internal DNS for the server, or enable hairpin NAT |
Avoid “allow any to any” as a test on a live business firewall. If you must test, make the rule as narrow as possible (one source, one destination, one port), give it a clear name and remove it afterwards.
VPN connectivity
Site-to-site VPNs (IPsec) connect in two phases. Phase 1 lets the two firewalls authenticate each other. Phase 2 sets up the tunnel for the actual traffic. Both sides must use matching settings.
- Phase 1 fails: check the pre-shared key, the peer public IP addresses, IKE version (v1 or v2), and the encryption, hash and Diffie-Hellman group settings on both ends.
- Phase 1 up, Phase 2 fails: the local and remote networks (proxy IDs / traffic selectors) must mirror each other exactly. A subnet mask mismatch is a common cause.
- Tunnel up, no traffic: check firewall rules allowing traffic between the two networks, routes pointing into the tunnel, and that NAT is not applied to VPN traffic (a “NAT exemption” or “no-NAT” rule).
- Ports: IPsec uses UDP 500 and, when there is NAT in the path, UDP 4500. Make sure your ISP equipment is not blocking them.
diagnose vpn ike gateway list
diagnose vpn tunnel listshow crypto ikev2 sa
show crypto ipsec saFor remote-access (user) VPNs, check that the user’s account is active, the VPN client is up to date, and the user’s home network does not use the same IP range as the office network. An overlap such as both using 192.168.1.0/24 can stop office resources from being reached.
Firewall migration
Replacing a firewall is one of the riskiest network changes for a small business, because everything passes through it. Plan it like this:
- Export and save the old configuration. Keep the old firewall available until the new one is proven.
- Make a checklist of everything that must work: internet access, each port forward, each VPN, guest Wi-Fi, printers, phones, cloud apps and remote access.
- Recreate rules deliberately rather than copying everything. Remove rules nobody can explain, but write down what you removed.
- Schedule a maintenance window outside business hours and tell users in advance.
- Test every item on the checklist after cutover. Your ISP may need to clear the ARP/MAC cache on their equipment if the new firewall uses the same public IP address; restarting the ISP modem often does this.
- Have a written rollback plan: how long you will try before putting the old firewall back.
How to confirm it’s fixed
- The affected device or user can reach the service again, and the firewall log shows the traffic as allowed.
- For a VPN, both phases are up and you can reach a device on the far side, in both directions.
- Re-test after a firewall reboot or a few hours later, so you know the fix survives and isn’t a temporary session.
- Remove any temporary test rules and save the final configuration as a new backup.
Frequently asked questions
Why does a website work at home but not at the office?
The office firewall may be blocking it with web filtering, application control or a rule. Check the firewall’s security or web filter logs for the time you tried to visit the site.
Do I need both a NAT rule and a firewall rule for port forwarding?
On most business firewalls, yes. The NAT entry translates the address and port, and a separate rule allows the traffic. Some firewalls create both together in one wizard.
My VPN connects but I can’t reach anything. What’s wrong?
Usually a missing route, a missing allow rule between the networks, NAT being applied to VPN traffic, or overlapping IP ranges between the two sides.
Is it safe to turn the firewall off to test?
No. It exposes your whole network. Use the firewall’s own tools, such as logs, packet capture or packet tracer, to see what is being blocked instead.
Sources
- Fortinet documentation: FortiOS “Debugging the packet flow”.
- SonicWall support: “How to use Packet Monitor”.
- Cisco ASA command reference: packet-tracer, show conn, show xlate, show crypto.
Submit your issue, we can help
Tell us what's happening. We'll reply by email with troubleshooting steps. There's no charge for written guidance.