In the familiar EdgeOS example, WAN_LOCAL handles traffic destined for the router, while WAN_IN handles traffic arriving from WAN and forwarded onward. The names themselves have no magic: inspect the actual interface and direction where each ruleset is attached. A carefully written ruleset that is not attached to the relevant path cannot affect that traffic.
Read the existing rules and counters #
Operational mode; substitute your real ruleset names:
Read the existing rules and counters
EdgeOS · EdgeOS operational CLI / shell for tcpdump
Replace these example values: WAN_IN.
show firewall name WAN_IN statisticsReplace these example values: WAN_LOCAL.
show firewall name WAN_LOCAL statisticsshow nat statisticsshow configuration commands | no-moreTreat configuration output as sensitive. Locate the relevant interface attachment, rule order, match conditions and NAT rule in the output instead of publishing an entire router configuration for a single question.
Compare before and after one test #
Record the counter values, generate one new connection from a known client, then collect them again. Use the same destination and protocol on each attempt. A long-running browser connection may continue to use existing state, so it is a poor substitute for a deliberately fresh test.
| Evidence | Useful next check |
|---|---|
| Expected policy counter stays unchanged | Interface attachment, direction, earlier match or wrong traffic path |
| A drop rule increments | Which specific condition matched this test? |
| Expected allow rule increments | Where does the packet go next, and does a reply return? |
| A NAT rule records activity | Is the observed translated address/port the one the server expects? |
| NAT activity without success | Firewall, server listener and return routing still need checking |
Counters are not a complete packet trace. Their meaning depends on the table and connection processing, and background traffic can increment them during your test. Do not convert a counter increase directly into a claim that the whole application session succeeded.
For a port forward, write the outside destination, translated inside destination, server port and expected return gateway on one line. Capture on both relevant sides if the counter comparison cannot explain the loss. For router-hosted services, inspect the local path instead of changing a forwarding rule.
Keep troubleshooting read-only until you can name the failing step. Flushing connections or disabling the entire WAN firewall may create an apparent improvement while erasing the evidence and exposing unrelated services. A useful fix changes the relevant match, attachment or return path and then repeats the same controlled test.
Sources
Documentation reviewed: 8 October 2026