Hey folks, we've been piloting Barracuda CloudGen Firewall in our hybrid AWS environment and hit a snag with the Application Control feature. It's been great for locking down modern web traffic, but it's completely breaking a legacy line-of-business application that our finance team relies on.
The app is a thick client that connects to an on-premise server over what looks like a mix of custom TCP ports and some HTTPS for reporting. Application Control is classifying it as "Unknown" and blocking it, even with a fairly permissive policy. We've tried creating a custom application signature based on the server IP and port range, but it's still getting tripped up, seemingly by the TLS inspection.
Has anyone else navigated this? I'm trying to avoid just creating a blanket "Allow All" rule for that server's subnet, as it defeats the purpose. Specifically:
- Are there best practices for handling legacy/niche applications in CloudGen's Application Control?
- Is there a way to properly define a custom application that bypasses deep packet inspection for specific traffic?
- Could this be a certificate pinning issue on the legacy app's side when TLS inspection is active?
Our current workaround rule looks like this, but it's not ideal:
```json
{
"rule_name": "Allow_Legacy_Finance_App",
"source": "finance_vlan",
"destination": "on_prem_server_ip",
"service": "TCP_8000-8010,HTTPS",
"application": "Unknown",
"action": "Allow",
"inspection": "Basic"
}
```
Would love to hear if you've found a more elegant solution that maintains security posture without breaking the old stuff.
--titan
Plan happy, apply safely.
Ah, the classic bait-and-switch. You buy the box for granular app control, then have to disable its core features to make your actual business software work.
Creating a custom signature based on IP and port should work, but if it's still failing, that's your proof the DPI engine is interfering. The TLS inspection is almost certainly the culprit, either failing to decrypt the legacy traffic properly or the client rejecting the firewall's MITM certificate.
You've already found the real answer, you just don't like it. Your workaround *is* the solution Barracuda expects you to use: create a bypass. The "best practice" they won't advertise is to carve out an exception rule that excludes this traffic from Application Control and TLS inspection entirely, based on source/destination IP. It's an allow-all rule for that specific app flow, which is what you need.
Have you calculated the annual cost of this firewall versus the man-hours you're now spending trying to make a 20-year-old app compliant with it?
Read the contract
Your suspicion about certificate pinning is the critical angle to investigate. Legacy thick clients often have hard-coded certificates or expect a specific TLS handshake that breaks under MITM inspection.
The custom signature based on IP and port likely failed because you built it within the Application Control module, which still subjects the traffic to the DPI engine. You need a rule *above* the Application Control policy in the rulebase that explicitly disables both Application Control and SSL Interception for that specific traffic flow. Think of it as a dedicated fast lane that bypasses the inspection checkpoint entirely.
Have you checked if the application's vendor documentation mentions any specific cipher suites or certificate authorities? That could confirm the pinning theory and justify the bypass rule to your security team.