Block an IP Address on Your Router or Firewall: Step-by-Step

Block an IP Address on Your Router or Firewall: Step-by-Step

Blocking a misbehaving IP is one of the fastest ways to stop abusive traffic, brute-force attempts, or noisy scanners from touching your network. Done right, it buys you breathing room while you investigate root cause. Done wrong, it can cut off legitimate users or, worse, lock you out of your own gear.

We’ll walk through where to place the block (router, firewall, or host), how to add rules safely, and how to test without creating new problems. You’ll see concrete examples for common platforms and a checklist to avoid self-inflicted outages.

Before you start, collect the exact IP to block, the ports or services affected, and whether the traffic targets a specific server or your router itself. If your environment uses IPv6, plan to cover both families.

How IP Blocking Works

Blocking at the network edge drops or rejects packets from a source address before they reach hosts. A drop silently discards traffic; a reject returns an error (like ICMP unreachable or TCP RST), which can speed client failures but may reveal that a filter exists. For noisy attackers, drop is usually fine. For misconfigured trusted systems, reject can reduce timeouts and help them fail fast.

Choose the Right Place to Block

If multiple devices sit between the internet and your application, you can block at the router, a dedicated firewall, a load balancer, or the host. Prefer the earliest point that sees the traffic, so you save downstream CPU and log noise. For shared environments (multi-tenant), coordinate with change control and document the scope.

Router WAN Input vs Forward

Rules on the WAN input chain protect the router itself (SSH, web admin, VPN). Rules on the forward chain protect devices behind the router. If an attacker targets a server behind NAT, put the block on the WAN forward or equivalent. If they target the router’s management plane, block on WAN input.

Host Firewalls

When only one server is affected, host firewalls (Windows Defender Firewall, iptables/nftables, UFW, pf on BSD/macOS) are often fastest to deploy and easiest to roll back. They don’t help other hosts, so consider edge enforcement later.

Step-by-Step: Typical Home/SMB Router UI

Every vendor labels things slightly differently, but the flow is similar. 1) Log in to the router admin page with an account that has firewall permissions. 2) Find Firewall or Security → Rules/ACL. 3) Add a new rule with Action = Drop or Deny. 4) Direction/Chain = WAN In (for protecting the router) or WAN Forward (for protecting internal hosts). 5) Source = the offending IP (e.g., 203.0.113.45). 6) Destination = Any, or the specific internal IP/port under attack. 7) Place the rule above any permit rules that would otherwise allow it. 8) Save and apply changes. 9) Test from an external network and monitor logs.

Step-by-Step: Linux Server

Linux offers several paths; pick the one your system already uses so changes persist correctly.

iptables Example (Legacy)

Run: sudo iptables -A INPUT -s 203.0.113.45 -j DROP; to block inbound from a single IP on all ports. For a specific service, target the port: sudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.45 -j DROP. Remember that iptables rules aren’t persistent by default; save them with sudo iptables-save | sudo tee /etc/iptables/rules.v4 (or use netfilter-persistent/your distro’s method) and schedule a maintenance window before applying on remote systems to avoid lockout.

nftables Example (Modern)

Create a table/chain if needed: sudo nft add table inet filter; sudo nft add chain inet filter input { type filter hook input priority 0; }. Add the rule: sudo nft add rule inet filter input ip saddr 203.0.113.45 drop. Persist by writing to /etc/nftables.conf and enabling the nftables service so rules load on boot.

UFW Example (Ubuntu Frontend)

Block a source across all ports: sudo ufw deny from 203.0.113.45. For a single port: sudo ufw deny from 203.0.113.45 to any port 22 proto tcp. Check ordering with sudo ufw status numbered and delete with sudo ufw delete <num> if you made a mistake.

Step-by-Step: Windows Defender Firewall

Open Windows Defender Firewall with Advanced Security → Inbound Rules → New Rule → Custom. Set Scope → Remote IP address = 203.0.113.45, Program = Any (or specific), Protocol/Ports as needed, Action = Block, and apply to the right profiles (Domain/Private/Public). For command line, use: netsh advfirewall firewall add rule name="Block 203.0.113.45 inbound" dir=in action=block remoteip=203.0.113.45 and similarly for outbound with dir=out if required.

pfSense, OPNsense, UniFi, and MikroTik Quick Recipes

pfSense/OPNsense: Create an Alias (Firewall → Aliases) for one or more bad IPs. Then Firewall → Rules → WAN: Add a Block rule with Source = that alias, Destination = Any or your server, Action = Block, and move it above permits. Apply changes and verify on the Live View logs.

UniFi Network

Go to Settings → Firewall & Security → Firewall Rules → WAN In. Create a rule with Action = Drop, Source = 203.0.113.45, Destination = Any (or the DNAT’d host/port). If you use “Internet Threat Management,” ensure custom rules still hit before automatic policies.

MikroTik RouterOS

Add to an address list: /ip firewall address-list add list=blocked address=203.0.113.45; then filter: /ip firewall filter add chain=input src-address-list=blocked action=drop; and if protecting downstream hosts, also chain=forward. Move rules near the top so they’re evaluated early.

Cloud Nuances

Security Groups in common clouds are stateful allow lists, not block lists; to block specific sources, use Network ACLs (stateless) or the managed WAF/LB rules in front of your service. In a pinch, host firewalls still work, but you’ll pay with extra instance CPU.

Safety Tips to Avoid Lockouts

Keep an allow list for your management IPs and put it above any broad denies. When working over SSH/RDP/VPN, add a second out-of-band path (console, KVM, serial) before you test. Favor time-boxed changes: on Linux, use at to run a rollback script in 5–10 minutes, then cancel the job once you confirm success. In Windows, create a matching “Allow from admin IP” rule and keep a saved policy export.

Logging and Observability

Don’t add logging to every dropped packet on busy WAN interfaces; you’ll flood disk. Instead, log the first match via a higher-priority rule with counters, then drop silently below. On iptables, insert a rate-limited LOG target; on nftables, use log prefix "deny" limit rate 5/second; then drop in the next rule.

Verification and Troubleshooting

Test from a network that isn’t on your allow list. For TCP services, attempt a connection with curl or nc and confirm it fails quickly (reject) or times out (drop). Watch counters on the rule to ensure matches increment. If the block “does nothing,” confirm you placed it on the correct interface/chain and above any permits that would short-circuit evaluation.

Validate the Right IP and DNS Pitfalls

Attack tools often rotate IPs. Consider blocking a range only when you have evidence the noise is tightly clustered (same provider/prefix). Verify that the destination hostname actually resolves to the server you think it does; content delivery, proxies, or DNS changes can mislead you.

IPv6 and NAT Considerations

IPv6 addresses won’t be covered by IPv4 rules. If the source has IPv6, add a matching v6 drop (for nftables, ip6 saddr; for Windows, add a second rule with the IPv6 address). NAT doesn’t apply to IPv6 the same way, so check both the router and host policies.

Port-Specific Blocks vs Full Blocks

Blocking just the targeted service (like TCP/22 for SSH) can reduce collateral damage and ease troubleshooting. Use a full IP block when the source probes many ports or attempts lateral movement.

When Blocking Isn’t Enough

If the source is part of a larger botnet, pair IP blocking with rate limiting (syn cookies, connection limits), credential hygiene (MFA, keys), geofencing (with care), and application-layer defenses (reverse proxy/WAF). Blocks should complement—not replace—patching and sane exposure (no admin interfaces on the public internet).

Maintenance: Document and Review

Every temporary block should have a ticket, owner, reason, and review date. Expire rules that no longer fire, and promote long-lived patterns to a central policy (aliases, address lists, objects) instead of sprinkling ad-hoc entries across devices. That’s how you keep rulesets understandable and safe months later.

Blocking an IP on a Router or Firewall (FAQ)

Check your current public address from a trusted network first, for example with What Is My IP Address, and add it to an allow list before applying any deny rules.

Yes if the source has IPv6—confirm with an IPv6 Test and create matching rules for v4 and v6 so you don’t leave a parallel path open.

Firewalls filter on IPs, so resolve the hostname with Domain to IP or run a DNS Lookup and use the returned addresses in your rule or alias.

Check the PTR/owner trail with a Reverse DNS Lookup and review logs over time; if many unrelated clients share it, prefer rate limits over a blanket block.

Only when abuse spans adjacent addresses from one provider; validate the prefix and impact with a Subnet Calculator and document the scope before deploying.

If you drop new packets, new connections will fail; established stateful sessions might continue until they time out unless you also clear connection tracking or restart the service.

Most platforms evaluate rules top-down; ensure the deny sits above permits, applies to the correct chain (WAN in vs forward), and is bound to the right interface.

Schedule an automatic rollback (at/cron or a saved firewall policy), keep an out-of-band console ready, and test from a second network so you can confirm and cancel the rollback.