Skip to content
Notifications
Clear all

Walkthrough: Configuring the firewall policies for our remote sales team laptops.

2 Posts
2 Users
0 Reactions
0 Views
(@ashp99)
Estimable Member
Joined: 7 days ago
Posts: 71
Topic starter   [#13654]

Just finished rolling out new firewall rules for our 50-person remote sales team. Goal was to lock things down without breaking their daily workflow (Salesforce, Zoom, Outreach, etc.). The default policies were too permissive for devices that are often on public Wi-Fi.

Here’s the core of our setup:

* **Rule Order is Key:** Started with a clean-up. Deny rules for known-bad IPs/ports first, then specific application allows, and a final "deny all" at the bottom.
* **Application-Based, Not Just Ports:** Leveraged Intercept X's application control. Made rules for "Zoom" and "Microsoft Teams" instead of just opening a range of UDP ports. Much cleaner.
* **Split Tunnel VPN Exception:** Our team uses a global VPN. We created an allow rule *only* for the VPN client's traffic to our gateway, then the firewall processes all other traffic locally. This keeps browsing traffic off the corp VPN.
* **Logging for the Win:** Enabled logging on the final deny rule for a week. Reviewed logs to see what legitimate traffic we missed—turned out a few needed a legacy CRM web port.

The dashboard for firewall events is actually pretty useful to spot anomalies. Took some tweaking, but the team hasn't filed a single "blocked" ticket in two weeks. Success!

Anyone else set up similar policies? Curious how you handled personal use (like social media) on company devices.

--ash


data over opinions


   
Quote
(@hiroshim)
Reputable Member
Joined: 1 week ago
Posts: 188
 

Your application based approach is the correct move for modern SaaS tooling. I would caution, however, that relying solely on application signatures can fail during updates or when new sub processes are spawned. Have you established a baseline performance metric for latency-sensitive apps like Zoom under these new rules? I've seen scenarios where deep packet inspection for application identification adds 8-12ms of latency on commodity laptops, which is enough to trigger poor call quality warnings.

The split tunnel configuration is prudent for cost and performance, but it introduces a blind spot for device posture assessment on the non VPN traffic. How are you handling the potential for a compromised laptop to bypass your corporate DNS or threat filtering on the direct internet path? A layered approach would require a DNS filtering service like Cisco Umbrella or a similar agent based solution for that traffic.

Your logging exercise is the most valuable step. Extend that beyond a week into a continuous sampling process, perhaps 1% of all denies, to catch newly deployed internal tools or API changes from your vendors. The operational data from those logs is also useful for capacity planning on your VPN concentrators.



   
ReplyQuote