This Frequently Asked Questions (FAQ) document provides concise answers and guidance for using the GCC Firewall Module. It is intended to help administrators and users understand key firewall features and resolve common issues related to traffic rules and policies, NAT/port forwarding, content and application control, threat prevention (Anti-Malware and IDS/IPS), SSL inspection, and security logs.
Getting Started & Firewall Overview
On supported Grandstream devices, the firewall is a built-in security function that controls traffic between networks (for example, WAN and internal networks). It allows administrators to define allow/deny rules, apply protections against common threats, use filtering controls where available, and verify activity through security logs and dashboard statistics.
The firewall is supported on the following Grandstream GCC series models:
| Series | Models |
|---|---|
| GCC601x Series | GCC6010, GCC6010W, GCC6011 |
| GCC602x Series | GCC6020, GCC6021 |
When the firewall service is activated for the first time, it includes a free 1-year trial starting from the activation date. After the trial period ends, the firewall service can be renewed using an update plan.
More details: https://cloud.grandstream.com/firewall/plans
The firewall will continue to run using the last installed security engines/signatures and the current configuration (rules, NAT, filtering settings, etc.).
If the service is not renewed, the main impact is that the device will no longer receive firewall security updates (signature updates), which can reduce protection over time as new threats appear.
On supported Grandstream devices (such as the GCC series), go to Firewall → Overview. This page provides a quick snapshot of the firewall’s current status, including the service/license state, authorized/active security services, recent security log activity, protection statistics, and filtered applications. It’s the main page to confirm the firewall is running and to see what’s being detected or blocked.
- DPI Engine: The GCC60xx includes a globally leading commercial-grade Deep Packet Inspection (DPI) engine that delivers high-precision, high-performance application identification with low system overhead. Based on DPI recognition results, the Firewall Module supports application-based traffic statistics, filtering, and QoS management.
- URL Recognition Engine: The Firewall Module also uses a self-developed URL recognition engine that is deeply integrated with DPI technology to accurately identify URL information within network traffic. Combined with a rich URL signature database, it helps provide targeted protection against threats such as phishing, hijacking, cryptojacking, and unauthorized intrusion attempts.
- Anti-Malware: The GCC60xx includes an enterprise-grade Anti-Malware engine designed to detect and block malicious content across supported traffic types. It provides broad threat coverage, timely intelligence updates, and enhanced protection against known and emerging threats.
- IPS/IDS: The intrusion detection and prevention system is built on the Suricata engine and enhanced through further optimization. It uses a combination of open-source community rules and proprietary security rules to detect and prevent malicious network activity.
Policies & Traffic Control
Rules Policy defines the default behavior for a specific interface/zone (for example, WAN or VLAN). It’s the baseline action the firewall should take for traffic on that interface (such as accept/deny/drop), and it can also include general options like logging and masquerading.
Traffic Rules (Local Inbound, Local Outbound, and Forwarding) are the specific rules that you add on top of that baseline. They are used to allow or block particular traffic based on conditions like source/destination, protocol/port, IP family, and groups.
In practice, you can set a strict default policy (for example, drop inbound on WAN), then create Traffic Rules as exceptions to allow only what you need (for example, allow HTTPS management from a trusted IP, or allow a specific published service).
- Accept: The traffic is allowed, and the connection proceeds normally.
- Reject: The traffic is blocked and the device sends a response back to the sender (so the sender immediately knows it was refused).
- Drop: The traffic is blocked silently (no response is sent), so the sender typically sees a timeout.
- Inbound (Local Inbound) rules control traffic entering the device itself from other networks (for example, access to the firewall’s management interface/services).
- Outbound (Local Outbound) rules control traffic originating from the device itself going out to other networks (for example, DNS/NTP/updates generated by the device).
- Forwarding rules control traffic passing through the device between networks (for example, LAN/VLAN users accessing the internet, or inter-VLAN traffic).
Traffic rules are evaluated by priority order. In the Traffic Rules list, the lower the rule number, the higher the priority, so those rules are checked first.
You can change priority by reordering rules (for example, using options like Move to Top, or by adjusting the rule’s position/serial number depending on the UI actions available).
Create a Forwarding Rule that denies traffic between the two networks.
- Go to Firewall → Firewall Policy → Traffic Rules → Forwarding Rules.
- Click Add.
- Set the Source to the first VLAN/network (or its address/subnet/group).
- Set the Destination to the second VLAN/network (or its address/subnet/group).
- Set Action to Drop (or Reject if you want a response).
- Place this rule above any broader “allow” rules so it matches first (lower rule number = higher priority).
- Save/Apply, then test connectivity between the VLANs.
Tip: If you only want to block certain services (not all traffic), specify the protocol/ports instead of “Any.”
- SNAT (Source NAT) changes the source address of traffic leaving your network. It’s most commonly used for outbound internet access (for example, internal clients going out through a WAN IP), often shown as masquerading.
- DNAT (Destination NAT) changes the destination address of traffic coming into your network. It’s most commonly used for publishing internal services to the internet (port forwarding), such as sending WAN traffic on a specific port to an internal server.
Quick rule: SNAT = outbound, DNAT = inbound/port forwarding.
Threat Protection
Grandstream’s firewall includes multiple protection features that work together to detect and block attacks. In the web UI, these protections are mainly found under Security Defense (for example, DoS/spoofing protections), Intrusion Prevention (IDS/IPS and Botnet), Anti-Malware, and SSL Proxy (SSL inspection for encrypted traffic).
SSL inspection (SSL Proxy) is a feature that allows the firewall to inspect encrypted HTTPS traffic. Since HTTPS is encrypted end-to-end, security controls like web filtering, threat detection, and application identification may only see limited information unless the traffic is decrypted for inspection.
When SSL inspection is enabled, the firewall can apply security policies and detection to HTTPS sessions more effectively, then re-encrypt the traffic before sending it to its destination. This is typically used when you need stronger visibility and control over encrypted web traffic.
These features protect against different types of attacks at different layers, so they complement each other instead of replacing each other.
- DoS Defense helps keep the network available by detecting and blocking traffic floods and abnormal packet attacks (for example SYN/UDP/ICMP floods, scans, malformed traffic).
- ARP Protection helps prevent local network spoofing (such as ARP poisoning), which can be used for man-in-the-middle attacks inside the LAN.
- Anti-Malware focuses on detecting and blocking malicious files and payloads transferred through supported protocols (such as web downloads or email-related traffic, depending on configuration).
IDS/IPS is different: it is designed to detect and stop intrusion attempts and exploit behavior, such as:
- Web attacks (injection, brute force attempts, path traversal, file upload exploitation, etc.)
- Known vulnerability exploits and suspicious network patterns
- Indicators of malicious tools or attack techniques
You may see similar terms (like “DoS”) in multiple areas, but they often work differently: a dedicated DoS feature typically focuses on rate/packet-level flood protection, while IDS/IPS focuses on attack signatures and exploit detection.
In short: DoS Defense protects availability, ARP Protection protects LAN trust, Anti-Malware blocks malicious payloads, and IDS/IPS blocks intrusion techniques and exploit attempts.
No. A botnet is not an attack type, it’s an attacker’s “toolset.”
A botnet is a network of infected devices (PCs, IoT, servers, etc.) controlled remotely by an attacker through command-and-control (C2) servers. Those infected devices can be used for many different malicious activities.
A botnet can launch DoS/DDoS attacks, but that’s only one possible use.
Botnets are also commonly used for:
- C2 communication (infected devices “checking in” for instructions)
- malware delivery and updates (downloading additional payloads)
- credential attacks (brute force, credential stuffing)
- data theft and lateral movement inside a network
- spam and phishing distribution
What “Botnet” protection does (in simple terms):
Botnet controls are typically focused on blocking known botnet-related IPs/domains and preventing communication with C2 infrastructure, even when the traffic is low-volume and looks “normal.”
Why DoS Defense and IDS/IPS are still needed:
These protections cover different threat behaviors:
- DoS Defense targets flooding and abnormal traffic patterns (rate-based attacks, scans, malformed packets), regardless of who is sending them.
- IDS/IPS detects and blocks attack techniques and exploits (web attacks, brute-force behavior, protocol anomalies, malicious payload patterns), even when the attacker is not a known botnet.
Bottom line: Botnet protection helps stop infected devices from communicating with the botnet infrastructure. DoS Defense and IDS/IPS help stop the attacks and exploit behaviors that those devices (or any attacker) might generate. They’re complementary, not duplicates.
In many environments, enabling more protections improves security, but the best approach is enable smartly, not blindly. Consider these practical points:
- Performance impact: deeper inspection features (especially IDS/IPS at aggressive levels and Anti-malware deep scanning) may increase CPU usage and latency.
- False positives: stricter policies can block legitimate traffic.
- SSL inspection requirements: HTTPS inspection typically requires deploying a trusted certificate to client devices and may need exceptions for apps that use certificate pinning.
Recommended approach (safe and realistic):
- Enable core protections (DoS/ARP, basic IDS/IPS, Anti-malware) with balanced settings.
- Start in Monitor/Notify where available, then switch to Block after reviewing logs and confirming normal traffic isn’t affected.
- Add exceptions for trusted services/apps if needed.
- Only enable SSL inspection if you actually need to enforce security controls on HTTPS traffic.
These levels control how aggressively IDS/IPS detects and blocks threats. Higher levels usually enable more categories/signatures and stricter detection, which can increase protection but also increase the chance of false positives.
- Low: Basic coverage, lowest impact, lowest chance of false positives.
- Medium: Balanced protection and compatibility. Often, a good default for most networks.
- High: Stronger coverage for exposed networks and higher-risk environments.
- Extremely High: Most aggressive. Best used carefully and ideally tested first (Monitor/Notify) to avoid blocking legitimate traffic.
- Custom: Lets you manually select which detection categories to enable (best when you know your environment and want precision).
Simple guidance:
- Start with Medium for general use.
- Use High for networks with more public exposure or higher risk.
- Use Extremely High only if you can monitor and tune exceptions.
Inspection depth controls how deeply the firewall analyzes traffic for malware.
- Low: Light inspection, minimal impact, lower detection depth.
- Medium: Good balance for most networks.
- High: Deeper analysis, better detection, more processing overhead.
If your environment handles lots of downloads or email traffic, a higher depth can improve detection. If performance is a priority, start with Medium and increase only if needed.
When you enable IDS/IPS, it becomes active automatically on all WAN interfaces.
You do not need to select or enable it separately for WAN1, WAN2, or any additional WAN ports.
It also applies to traffic in both directions:
- Inbound (WAN → LAN)
- Outbound (LAN → WAN)
Filtering & Access Control
The firewall provides multiple filtering layers to control what users can access and what traffic is allowed through the network. Depending on the feature you enable, you can apply controls based on:
- Web Filtering: Blocks or allows access to websites using URL categories and reputation, with options for exceptions (allowlist/blocklist).
- DNS Filtering: Blocks domains at the DNS request level, which can stop access even before a connection is established.
- Application Filtering: Identifies and controls apps/services (not just ports), allowing you to block or restrict specific application categories or behaviors.
- File Filtering (where supported): Controls downloads by file type to reduce risk from unwanted or dangerous file transfers.
- Geo-IP Filtering: Allows or blocks traffic based on the country/region of the source or destination IP address.
These controls can typically be applied as policies so different networks (for example, VLANs or user groups) can have different access rules, while logs help verify what was blocked and why.
No. Application Filtering relies on an application signature database (maintained and updated as a library), so you can’t manually create or upload a “custom app” entry from the UI. The built-in list is designed to cover the most common and widely recognized applications, and it expands over time through signature updates.
If the exact app you need isn’t listed, you can still control it using other filtering options, depending on what you’re trying to block/allow:
- Web/URL Filtering: Block/allow domains, URLs, and patterns (including wildcards) for web-based services.
- DNS Filtering: Block/allow domains at the DNS level (useful when the app depends on specific domains).
- Traffic Rules: Control by IP, port, protocol, and source/destination networks for apps with predictable network behavior.
- Geo-IP Filtering / IP Exceptions: Add location-based rules or whitelist trusted destinations when needed.
Tip: if the app is mostly HTTPS, some controls may be more effective when SSL inspection (SSL Proxy) is enabled, because it helps the firewall see and classify encrypted traffic for policy enforcement.
Application Filtering and URL Filtering rely on signature and categorization databases (not static rules). Since applications and websites constantly change how they operate and how they are identified on the network, these databases must be updated regularly to keep filtering accurately.
Application Signature Library (Application Filtering)
Applications and cloud services frequently change things like domains, IP ranges, protocols, and delivery infrastructure (CDNs). Signature updates ensure the firewall can continue to correctly identify applications, so your allow/block policies keep matching the right traffic.
URL Signature Library (Web/URL Filtering)
Websites change domains, create new subdomains, move hosting, and may be re-categorized over time. URL signature updates keep URL categorization and reputation data current, so category-based policies (for example, blocking risky or unwanted content) remain effective.
What happens if signatures are not updated
Filtering usually continues to run, but accuracy can degrade over time, which may lead to:
- Applicationsare being detected as Unknown or placed in the wrong category
- Some new or updated applications are not being recognized correctly
- Website categories/reputation becoming outdated, causing missed blocks or false positives
In short, signature updates keep Application and URL Filtering reliable as the internet evolves.
Application Filtering supports category-based rules and custom app exceptions, so you can build a general policy and then fine-tune it when needed.
Where to configure it: Go to: Firewall → Content Control → Application Filtering
How it works
- Category selection applies a broad rule (allow/block an entire category).
- Custom Filter rules let you allow or block specific apps as exceptions.
- Custom Filter rules take precedence over category rules, so exceptions will override the general category policy.
Common scenarios
Scenario 1: Block a full category, but allow one app from it
Use this when you want strict control and only want to permit a specific approved app.
- Block the category (general rule).
- Add a Custom Filter rule to Allow the required app.
Scenario 2: Allow a full category, but block one app inside it
Use this when most apps in the category are acceptable, but you want to restrict one.
- Allow the category (general rule).
- Add a Custom Filter rule to Block the specific app.
This approach gives you the best of both worlds: simple category policies with precise per-app exceptions when needed.
Content Control → IP Exception allows you to exclude specific internal clients (by IP address, subnet, IP range, or address group) from one or more Content Control filtering features.
When an IP Exception is configured, the selected clients will bypass the Content Control policies you choose, such as:
- DNS Filtering
- Web/URL Filtering
- Application Filtering
- File Filtering
This is commonly used to exempt trusted devices (for example, an administrator PC, monitoring system, or a dedicated server) from content restrictions while keeping filtering enabled for other users.
Important: IP Exception under Content Control does not affect other firewall security modules (for example, DoS Defense, ARP Protection, Anti-malware, IDS/IPS, or SSL Proxy). Those features are configured separately and may have their own exceptions/settings.
Updates, Logs & Maintenance
“Signatures Update” keeps the firewall’s detection databases current so it can recognize the latest threats and services. These libraries are used by different modules (such as Anti-malware, IDS/IPS, Web/URL Filtering, and Application Filtering). Keeping them updated improves detection accuracy, reduces missed threats, and ensures filtering and classification stay reliable.
Each library powers a different security/control feature, so they’re updated independently:
- Virus Signature Library: used by Anti-malware scanning to detect malicious files and payloads.
- IPS Signature Library: used by IDS/IPS to detect and block known attack patterns (exploits, scans, brute force, etc.).
- URL Signature Library: used by Web/URL Filtering to categorize and block malicious or unwanted sites.
- Application Signature Library: used by Application Filtering to recognize apps/services (even when they don’t use obvious ports).
Keeping them separate allows the firewall to update the parts you actually use, without forcing one “mega update” for everything.
Yes. In Firewall → Signatures Update, open the Scheduled Update dropdown for the library you want, then choose Create Schedule to build a custom timetable.
You’re not limited to “daily/weekly” labels. A custom schedule lets you choose specific days and time windows.
Best practice: schedule updates during low-usage hours to reduce any chance of performance impact.
Yes. The firewall can display a custom block/notification page to end users when their request is denied by security or content controls (for example: a blocked website/category, detected malware, or blocked download/file).
You can typically customize things like:
- Company branding (logo / name)
- User-facing message (reason for the block, acceptable-use reminder, etc.)
- Basic layout/text to make it clear this is an intentional security policy, not a “broken internet” moment
Where to configure it: Firewall → Blocked Web Page
Good practice: Keep the message short and helpful. Mention what was blocked (site/category/file), and include what the user should do next (contact IT, open a ticket, request an exception).
The Security Log is the firewall’s event history for security-related activity. It records detections and enforcement actions from the firewall policy and security features (such as DoS/Spoofing, Anti-malware, IDS/IPS, Botnet, and DNS/Web/File filtering). This log helps you verify what happened, which device was involved, and what action the firewall took.
Where to find it: Firewall → Security Log
What a log entry typically includes:
- Timestamp (when the event occurred)
- Source IP (the client/device that triggered the event)
- Source Interface (which WAN/VLAN/interface the traffic came from)
- Module/Category (e.g., Firewall Policy, DoS & Spoofing, IDS/IPS, Web Filtering)
- Event/Attack Type (what was detected or matched)
- Action (e.g., Block/Drop/Allow/Monitor, depending on the feature and mode)
- Details (extra context such as signature/rule information)
How to use it for troubleshooting:
- Set the time range to the period of the issue.
- Filter by the module/category to narrow results (for example, IDS/IPS vs. Web Filtering).
- Identify the affected device using the Source IP and confirm the path via Source Interface.
- Review the Action and Details to understand why traffic was blocked or flagged.
- Use Export to share logs for auditing or support investigations.
Monitor = Detect + Log (no enforcement)
- The firewall identifies the event (DoS pattern, ARP spoof attempt, botnet match, IDS/IPS signature, etc.)
- It records it in Security Logs
- It does NOT stop the traffic/session
So the traffic still passes. You just get visibility.
Use Monitor when:
- You’re enabling a feature for the first time and want to measure impact
- You want to check if the detections are real or false positives
- You need evidence before enforcing blocks
Real-world example: You suspect scanning/attacks, but you are not sure if your environment will trigger false positives. You enable Monitor for a day, review logs, and then decide what to block.
Block = Detect + Enforce
- The firewall identifies the event
- It blocks/drops the traffic or prevents the connection (depending on the module)
- It logs the event so you can see what was stopped
So the traffic does NOT pass. You get protection, not just information.
Use Block when:
- You already validated that the feature behaves correctly
- You want actual protection on WAN-facing traffic
- You’re seeing real attacks and want them stopped now
Real-world example: Your logs show repeated brute force/port scans/floods. You switch from Monitor to Block, so the firewall actively drops the traffic instead of just reporting it.