-
zWAN
-
-
-
-
- Firewall & Layer 7 Application Filtering
- VPN Site-to-Site Tunnel Setup & Connectivity (z40 to Cloud vGR)
- Intrusion Prevention System (IPS) / Intrusion Detection System (IDS) Testing
- DNS Filtering
- DDoS Protection & Logging
- MAC Address Filtering & Geo-fencing
- Application Control & Protocol Blocking
- Authentication & Access Control (zID)
-
- WAN Link Failover & Load Balancing (ACI Mode)
- Dynamic Path Selection & Application-Aware Routing
- SaaS & Internet Breakout Validation
- QoS for Microsoft Teams (Datacenter vGR + Branch z40)
- Tunnel Failover (z40 ↔ vGR) — WAN00 (wired) primary, WAN03 (4G) & WAN04 (5G) backups
- IP Routing & Static Route Steering (z40 Branch)
- VLAN & Layer-2 Bridging
-
-
-
-
-
-
- Articles coming soon
-
-
-
- Articles coming soon
-
- Articles coming soon
-
-
-
-
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
-
-
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
-
-
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
- Articles coming soon
-
-
-
- Articles coming soon
-
- IPsec Tunnel not Establishing
- SSL-VPN Tunnel not Establishing
- Mobile Network Issues
- Management Tunnel does not Establish
- DNS not Resolving from Local Network Appliance
- DNS Resolution Issues in Tunnel Configuration
- DHCP Server not Leasing IP to LAN PC
- Debugging EC Events - Unknown Status Issue
- Trusted-MAC Geofencing Issues
- DNS Issues from DC LAN PC
- Troubleshooting LAN Connectivity to Internet via WAN, Remote Branch LAN, or Local Branch LAN
- NetBalancer gateways displaying Faulty/Inactive
- Packet Drop Issues
-
-
zTC
-
-
-
-
-
- Citrix HDX + USB Headset (Call-Center Baseline)
- VMware Horizon + Smart Card / CAC Login
- Microsoft AVD/RDP + Teams Optimized Video
- Multi-Monitor & 4K Performance
- USB Device Management - Block Storage
- Printing to Local USB & Network Printers
- Barcode Scanner (HID) with Line-of-Business App
- Kiosk / Assigned-Access Auto-Launch
- Wi-Fi Roaming & Link Change Mid-Session
- Power Management and Session State
- OS/Firmware Update & Rollback
-
-
StorTrends
-
zAccess
-
zGuardian
Application Control & Protocol Blocking
0 out Of 5 Stars
| 5 Stars | 0% | |
| 4 Stars | 0% | |
| 3 Stars | 0% | |
| 2 Stars | 0% | |
| 1 Stars | 0% |
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
sshdand 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), runlsandbye. - Linux:
ftp [ServerIP]orlftp [ServerIP].
- Windows:
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.
0 out Of 5 Stars
| 5 Stars | 0% | |
| 4 Stars | 0% | |
| 3 Stars | 0% | |
| 2 Stars | 0% | |
| 1 Stars | 0% |