Troubleshooting Firewall Rules

Configuration guides, troubleshooting and practical advice for AZTCOFW.

Articles

16 results

Asymmetric Routing

If reply traffic such as TCP:A, TCP:SA, or TCP:RA is shown as blocked in the logs, the problem could be asymmetric routing. See Troubleshooting Asymmetric Routing for more info.

Check The Firewall Logs

The first step when troubleshooting suspected blocked traffic is to check the firewall logs ( Status > System Logs , on the Firewall tab). By default AZTCO-FW will log all dropped traffic and will not log any passed tra

Check the State Table

Attempt a connection and immediately check the state table at Diagnostics > States and filter on the source or desti- nation to see if a state exists. If a state table entry is present, the firewall has passed the traffi

Enable Rule Logging

Determine which rule is matching the traffic in question. The hit counters in the rule list can help with this to some degree. By enabling logging on pass rules, the firewall logs will show an individual entry specifical

NAT Confusion

When crafting rules for firewalls involving inbound NAT connections, remember to use the private IP address as the Destination. This applies for port forwards as well as 1:1 NAT

New Rules Are Not Applied

If a new rule does not appear to apply, there are a couple possible explanations. First, If the rule is a block rule and there is a state table entry, the open connection will not be cut off. See Check the State Table .

Other Causes

There are other pitfalls in firewall rules, NAT, routing, and network design that can interfere with connectivity. See Troubleshooting Network Connectivity for more suggestions.

Port Forward pass action

When creating a port forward, the pass action will bypass firewall rules and pass the traffic directly through without filtering. Change the setting to create an associated rule and then arrange the block rule above the

Review Rule Ordering

Firewall rules are generally processed as follows: Floating Rules Interface Group rules Interface tab rules If a floating rule with quick checked passed the traffic, then a block rule on an interface would have no chance

Review Rule Parameters

Edit the rule in question and review the parameters for each field. For TCP and UDP traffic, remember the source port is almost never the same as the destination port, and should usually be set to any . If the default de

Rules and Interfaces

Ensure rules are on the correct interface to function as intended. Traffic is filtered only by the ruleset configured on the interface where the traffic is initiated . Traffic coming from a system on the LAN destined for

Ruleset Failing to Load

It is also possible that the rules are not being loaded properly. Typically this would result in a notification in the GUI, however manual tests can be performed to check. From the GUI, visit Status > Filter Reload . Cli

Source and Destination Ports

When crafting rules, bear in mind that typically only a source or a destination port needs to be specified, and rarely both. In the majority of cases, the source port does not matter at all. For example, to allow ssh acc

Troubleshooting with packet captures

Packet captures can be invaluable for troubleshooting and debugging traffic issues. With a packet capture, it is easy to tell if the traffic is reaching the outside interface or leaving an inside interface, among many ot

Unfilterable Traffic

Certain traffic cannot be filtered. Not because the AZTCO-FW software isn’t capable, but because they actually do not touch the firewall at all. A prime example of this is trying to keep one device on the LAN from access

UPnP / NAT-PMP passed traffic

If UPnP/NAT-PMP is enabled and a LAN device opens a port to the world, the traffic may still get in even if it appears it should otherwise be blocked.