How can we help?
You are here:
Print

Application Control & Protocol Blocking

 

Objective

Validate that the zWAN Gateway Router enforces protocol-level blocking and application-aware controls for common services across the LAN—specifically SSH, FTP, and RDP—using Flow Classification rules (Protocol Matching, optional DPI where available) and that enforcement is observable in firewall logs. Flow Classification supports IP/port/protocol, TCP flags, time schedules, and DPI filters; firewall policies can be time-based.

Prerequisites

  • Admin access to zWAN Director (or local UI) managing the device.
  • Two Windows clients on the z40 LAN (wired LAN00 or Wi-Fi LAN05).
  • Optionally one Linux client (for quick servers/clients).
  • Firewall / Flow Classification enabled on the device.
  • Ability to view firewall logs (Director provides system/firewall log dashboards).

Tip: Rule order matters (top-down); “ACCEPT / DROP / REJECT” semantics follow the stateful firewall behavior described in your docs.


Test 1 — Block SSH (TCP/22) between LAN devices (Protocol Matching)

1) Baseline

  • Windows target: enable OpenSSH Server via Settings → Optional Features → Add a feature → OpenSSH Server → Install. In Services, start sshd and set Startup type = Automatic.
  • From another Windows client, confirm you can connect:
    ssh [TargetUser]@[TargetDeviceIP] (first run will prompt to trust host key).

2) Create rule

  • Director: Security → Firewall → Rules → NEW RULE (Flow Classification).
  • General: Comment: “Block SSH LAN”, Apply To: Routed and Bridged Packets, Action: DROP, Status: Enabled.
  • Packet Matching: Input = LAN00 or LAN05, Output = same LAN interface.
  • Protocol Matching: Protocol = TCP, Destination Port = 22.

3) Validate

  • Retry: ssh [TargetUser]@[TargetDeviceIP] → should fail immediately (no banner).
  • Confirm other traffic (e.g., ping) still works.

4) Logs

Director: Edge Controllers → [Device] → System → Logs → FIREWALL. Filter on dst_port:22 or the two LAN IPs. You should see dropped entries with rule comment.


Test 2 — RDP allow-list + blanket block (Protocol Matching + rule order)

Goal: Only Device A may RDP to Device B; everyone else is blocked.

1) Baseline RDP

  • On Device B, enable Remote Desktop (Windows Settings → System → Remote Desktop).
  • From Device A, confirm RDP works (mstsc.exe, connect to Device B IP).

2) “Allow” rule (narrow scope)

  • General: Comment “Allow RDP A→B”, Action ACCEPT, Status Enabled.
  • Packet Matching: Input = LAN interface of Device A, Source Address = Device A IP, Destination Address = Device B IP, Output = same LAN interface.
  • Protocol Matching: TCP, Destination Port = 3389.

3) “Block” rule (catch-all)

  • General: Comment “Block RDP LAN”, Action DROP, Status Enabled.
  • Packet Matching: Input = LAN interface, Output = same LAN interface.
  • Protocol Matching: TCP, Destination Port = 3389.

Ensure the Allow rule sits above the Block rule in sequence.

4) Validate

  • From Device A → B: RDP connects (allowed).
  • From any other LAN device → B: RDP fails (blocked).

5) Logs

In FIREWALL logs, you should see accepted entries for A→B (3389) and dropped entries for others (3389).


Test 3 — Block FTP (TCP/21) except to a specific internal server

(Uses a tiny, free cross-platform FTP server via Python; no heavy installs.)

0) Quick FTP server (Windows or Linux)

pip install pyftpdlib
python -m pyftpdlib --port 21 --user testuser --password testpass --write

Note the FTP server host IP (Device B for example).

1) Baseline FTP

  • From Device A, verify you can connect:
    • Windows: ftp [ServerIP] (enter testuser / testpass), run ls and bye.
    • Linux: ftp [ServerIP] or lftp [ServerIP].

2) Allow-then-Block rules

  • Allow (A→FTP server only): General = “Allow FTP A→Server”, Action ACCEPT; Packet Matching = Source = Device A IP, Destination = FTP Server IP; Protocol Matching = TCP 21.
  • Block (all LAN FTP otherwise): General = “Block FTP LAN”, Action DROP; Packet Matching = Input/Output = LAN interface; Protocol Matching = TCP 21. Ensure Allow is above Block.

3) Validate

  • From Device A, FTP still works.
  • From any other LAN device, FTP is blocked.

4) Logs

In FIREWALL logs, filter by dst_port:21.


Optional Test 4 — After-hours block for RDP (Time Matching)

If you want a schedule (e.g., block RDP weeknights 6 PM–8 AM & all weekend):
Edit the “Block RDP LAN” rule → Time Matching tab: add your schedule window(s).
Save and validate by testing during a blocked window (or temporarily set a near-term window for a live check).

Rationale: Flow Classification supports time-based rule evaluation and can combine it with other filters (IP/port/app).


Validation Criteria

  • SSH, FTP, and RDP enforcement matches rule intent (allowed vs blocked).
  • Firewall logs show corresponding ACCEPT/DROP entries with correct IPs/ports and timestamps.
  • Rule order produces the expected allow-list behavior.

Notes & Tips

  • Keep tests on LAN (same interface) to avoid WAN policies affecting results.
  • Flow Classification can also match TCP flags, connection state, and invoke DPI where available.
  • If your DPI catalog includes SSH/FTP/RDP, you can replace protocol/port match with a DPI selection.
Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.
Table of Contents
Top