The Toolbox: OPNsense, Nmap, and the Suricata IDS/IPS
Where do you look, once the model is assembled, before writing the first firewall rule? OPNsense's admin interface settles into a handful of stable menus across the whole course, and the lab adds two or three tools whose names will come up often.
Interfaces handles addressing for each zone, Firewall > Rules the rules per interface, Firewall > NAT address translation, Firewall > Aliases naming groups of addresses or ports, and Status > System Logs > Firewall reading, line by line, what has just been allowed or blocked.
| OPNsense menu | Used for |
|---|---|
| Interfaces | addressing for each zone (WAN, LAN, DMZ) |
| Firewall > Rules | filtering rules, per interface |
| Firewall > NAT | address translation (outbound, redirect) |
| Firewall > Aliases | naming a group of addresses or ports |
| Status > System Logs > Firewall | line-by-line log of filtered traffic |
The lab also uses tools installed on the attacker machine to test the firewall policy from the outside, the way a visitor or an intruder would. Nmap probes ports to tell whether they are open, closed, or filtered (the previous module details the logic behind that). Hping3 crafts packets by hand, useful for testing one specific rule without depending on a real service. Suricata, for its part, runs on the defense side: it is an IDS/IPS, an intrusion detection and prevention system that inspects the content of traffic already allowed by the firewall and can alert on, or even block, a known attack pattern.
UTM: Several Functions, One Box
OPNsense is not limited to network filtering: fully enabled, it brings together under one box a firewall, a web proxy able to inspect and block pages, a traffic antivirus, and the already-mentioned Suricata IDS/IPS. This combination goes by a generic name: UTM, for unified threat management. The next module comes back to this in detail; for now, remember that these functions coexist on the same machine, without excluding one another.
One technical trap comes up often on first contact with these tools: on OPNsense, a rule change shown as saved is not necessarily active. An orange Apply changes banner appears after every rule modification; until it has been clicked, the old rule keeps applying. That is the most common cause of a test that seems to prove a rule does not work, when it was simply never activated.
What to remember
- Five OPNsense menus come up throughout the course: Interfaces, Firewall > Rules, Firewall > NAT, Firewall > Aliases, and the Status > Logs > Firewall log.
- Nmap probes ports, hping3 crafts packets by hand: two attack-side tools used in the lab to test the firewall.
- Suricata (IDS/IPS) inspects the content of traffic already allowed; it complements rule-based filtering, it does not replace it.
- OPNsense as UTM brings together a firewall, web proxy, antivirus, and IDS/IPS on a single box.
Exam trap: a rule that was edited and saved stays inactive until the Apply changes banner has been clicked. Faced with a test that fails for no apparent reason, check for that missed click as the first hypothesis, before suspecting the rule itself.
*Checked on September 27, 2026 against the OPNsense documentation (Firewall > Rules, NAT, Aliases; IDS/IPS Suricata).*
Questions and discussion
No messages yet. Have a question about this lesson? Ask it here.
Sign in to join the discussion. Sign in