Hey everyone,
I wanted to share our recent experience and see if anyone else has run into something similar. We just concluded a fairly extensive Proof of Concept (POC) with Netskope, and unfortunately, we had to call it off. The core issue? It consistently failed to inspect and apply policy to traffic from our legacy, custom-built TCP-based application.
We were really excited about the prospect of a cloud-native SWG and CASB solution. Our main goals were data loss prevention for SaaS apps and securing access to internal web apps. For standard web traffic (HTTPS, HTTP) and known SaaS platforms, it worked as advertised. The steering configuration via the client or GRE tunnels was smooth.
The deal-breaker emerged with our custom engineering application. It’s a thick-client app that communicates over a proprietary TCP protocol on a non-standard port (not HTTP/S in any way). We needed to simply allow or block access based on user group, and ideally get some basic logging. We assumed a "non-web app" policy with a custom port definition would handle it.
Here’s a simplified version of what we tried to configure:
```
Application: Custom_TCP_App
Category: Custom
Risk Level: Defined by us
TCP Port: 9015
```
We set a policy rule to `Block` this "Custom_TCP_App" for a test user group, while allowing it for others.
**The Gotcha:** The traffic was never correctly identified as `Custom_TCP_App`. In the Netskope Skope IT logs, we either saw it categorized as `UNKNOWN` or, oddly, sometimes as generic `TCP-Based-Application`. The block rule never fired, and the traffic flowed unrestricted, regardless of the user. It seemed like the platform needed deeper protocol decoding or specific signatures to truly "see" this as a distinct application, which it clearly didn't have for our in-house tool.
We worked with their support, and the ultimate takeaway was that their application identification engine is heavily geared towards *known* web and SaaS protocols. For custom, non-web TCP streams, the detection falls back to very basic port/protocol matching, which isn't reliable for policy enforcement if you need app-level granularity.
**Key takeaways from our POC failure:**
* **Netskope's strength is in the web & SaaS layer.** For that, it's fantastic.
* **Custom TCP application support is a significant gap** if you need more than simple port-based allow/deny. You might be able to create a coarse port-based rule, but you lose the "application" context for user-based policies.
* **The "Non-Web App" policy type** feels a bit misleading. It seems to work better for things like SSH or RDP where the protocol is known, not for truly proprietary streams.
* **POC Critical Step:** If you have legacy or custom in-house applications, **test those workflows first and most rigorously**. Don't assume basic TCP filtering will work as you expect.
Has anyone else hit this wall? Did you find a workaround, or did you have to look at a complementary solution (like a traditional firewall or a more network-layer focused cloud service) for these specific non-web traffic flows?
Would love to compare notes. This was a real lesson for our team in scrutinizing the "application" definition in a CASB/SWG world.
-- Ian
Integration Ian
Oh man, this is the classic gap with a lot of cloud SWG platforms. They're fantastic at layer 7, but the moment you step outside HTTP/HTTPS or a handful of sanctioned SaaS app protocols, the inspection engine just... checks out.
We hit a similar wall a few years back with a different vendor and a legacy telnet-based system. The config you tried looks right - defining a custom app on a non-standard port - but the policy evaluation often still expects some form of HTTP-ish traffic to parse for context. If it's raw TCP, there's no URL, no host header, no user-agent. The user identity binding from your client steers the session, but then the policy has nothing to latch onto. It either defaults to block or, worse, lets it through without any logging.
Did you ever check the session details in the logs for one of these connection attempts? In our case, it would show the user and IP but list the "application" as "UNKNOWN" or "GENERIC-TCP," making our granular policies useless.
Makes you wonder if a hybrid approach is needed for these legacy beasts: keep them on-prem with a traditional NGFW for access control, and use the cloud SWG for everything else. Kinda defeats the "single pane of glass" dream, though.
pipeline all the things
That's not surprising. Their documentation heavily implies deep packet inspection for generic TCP is limited to a few known protocols. You defined a custom app, but if the traffic isn't HTTP-based, there's no application-layer context for the policy engine to use. User identity gets attached, but the allow/block decision often can't use any other condition.
We had the same realization. For these legacy TCP apps, you're effectively just getting a routed connection with user attribution. No real inspection. You need to verify if their "Application: Custom_TCP_App" policy even logs session details, or if it just shows up as "Unknown TCP."
This is a critical pre-sales question. Always ask for a list of non-web protocols they can actually inspect, not just steer. Most can't do anything with raw TCP beyond port-based blocking, which defeats the purpose of a POC.
SLA is not a suggestion.