Application Control Bug!? - Check Point CheckMates
Application Control Bug!?
Hi guys,
Yesterday, we had some problems with application control, which I didn't understand.
We use a central configured(SMP) 730 appliance with version R77.20.81 (990172541).
We also use the firewall blade in strict mode and the application control is activated too:
So we configured something like that:
Outgoing access to the Internet
| Source | Destination | Application | Service | Action |
|---|---|---|---|---|
| LAN networks | Internet | ANY | 80, 443 | Accept |
| LAN networks | Internet | ANY | 50, 123 | Accept |
Incoming, Internal and VPN traffic
| Source | Destination | Application | Service | Action |
|---|---|---|---|---|
| VPN Domains | VPN Domains | ANY | Any(encrypted) | Accept |
Additional we have the auto generated rules in the outgoing access tab(application control):
The undesired applications contains following elements:
So we tested the connection between to branches, which are connected via S2S VPN(which is working correctly).
The most protocols worked fine, but we had some problems with smp and rdp.
So i checked the log and found that:
There I could see that the application control blocks internal(vpn) traffic on the outgoing interface.
How we can see above, there aren't application block rules configured in the "Incoming, Internal and VPN traffic" section. Nevertheless the traffic over port 3389 between the internal networks 192.168.14.x and 192.168.10.y was blocked.
So I had to configure an outgoing rule for internal networks, which allows the communication between the defined vpn networks:
As soon as I activated this rule, the communication via the rdp and smb protocol was working properly.
Has someone the same problem?
Is this a application control bug?
Thanks a lot.
Best Regards
Severin Dellsperger
Tags:
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
20 Replies
MVP Silver
2019-02-1402:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would assume that this is the result of using a Strict Policy - you always have more work when enabling it as some things will not work without manual configuration. Here we see the reason why Default Policy is the suggested setting .
CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1402:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah, I understand what you mean, but theoretically it should work without this additional rule. It also doesn't make sense to put a rule with a internal network as destination to the outgoing section, no matter if the blade is used in strict or default mode, does it?
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
MVP Gold
2019-02-1402:25 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think APP control considers everything that is not a local network to be 'Internet' (including peer VPN domains). That's why traffic is blocked, it matches auto generated rules. 'Incoming, Internal and VPN' is for firewall blade only.
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Employee
2019-02-1404:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This Outgoing and Incoming separation sometimes causes some confusion.
The text "Incoming, Internal and VPN traffic" means "Incoming Internet and Incoming VPN Traffic"
Outgoing actually means "To the internet and applications to remote peers".
So you always need at least 2 rules for VPN if you want two-way traffic and it is not possible to just put both domains in one group and use as src and dst. Strict mode is weird, but I don't think that is a bug.
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1404:23 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Pedro_Espindola
Im not sure if this is correct:
I can see traffic from local network to a vpn peer, which takes the Incoming/Internal interface.
For example:
If it would be like you said, there should be a external rule, but we can see the inbound interface...
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Employee
2019-02-1404:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see. Well, what I told you is what I found out from my experience, but you are right, the behavior does not match what the logs say.
You will also notice that outgoing traffic never generates firewall logs. So the way firewall and application layers work seem to be much more complicated than this simple "Outoing and Incoming" separation makes us believe.
Anyway, I think you will always need to allow the traffic in the outgoing rules in strict mode.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
MVP Silver
2019-02-1404:42 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Pedro_Espindola
Right - therefore it is called strict...
CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1405:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Pedro_Espindola
Thanks for the info, nevertheless I'm very unhappy with this concept.
For me this all makes no sense.
Just saying "don't use strict mode, cause it's not recommended" doesn't sound like a solution for me.
Is there a official statement or documentation from checkpoint, where I can read this definitions?
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Employee
2019-02-1405:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Recommending Standard mode does not mean "Don't use Strict mode". I use it sometimes and works fine, but it is a lot of work.
Plus, in Standard mode you also need VPN rules in the outgoing rule set. The difference is that you already have the automatic "accept all" cleanup rule, but the concept remains the same.
That is not even the reason why Strict mode is not recommended. The reason is that there are no IMPLIED rules, so you get drops in the most unexpected traffic, such as communication between cluster members. And configuring dozens of rules in WebUI is a pain and visually horrible, not at all organized like in SmartConsole.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1406:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Pedro_Espindola
Yes you are right, but unfortunately it really seems nobody is using this firewalls in the strict mode, because its (too) much of work.
We never use VPN rules in the outgoing ruleset and it works always fine. We just have some problems with the application control...
I don't agree with you: If you wouldn't have implied rules in strict mode, the gateway coulnd't get updates online or wouldn't have problems with vpn connections, which isn't the fact...
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Employee
2019-02-1505:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok. Then it has very few implied rules.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1505:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In response to Pedro_Espindola
Yes, I think there only essential rules for "This GW"-object.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
MVP Gold
2019-02-1406:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree for one thing... This way of separating traffic is misleading and confusing. And I have not seen so far good technical documentation about it.
Note that when you put "encrypt" for a rule you are only telling the gateway that it should first try to encrypt/decrypt packet and then process it. Once that happens it is then processed by the firewall and handed over to other blades for inspection. And those other blades do not necessarily follow the same way to determine packet direction. Like for example application control determines what is Internet based on automatic topology calculation. It is not aware that this was VPN traffic before that.For it 192.168.14.0/24 is just another Internet network because it does not have it configured as a local one.
There is nothing wrong with using Strict policy. But the way to configure it can definitely be better.
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1407:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it's very confusing...
Thanks for your answer. Like you described it makes absolutely sense, the application control gets the packet after the firwall blade and checks if it's outgoing traffic and then blocks/allows the packets.
What do you mean with "There is nothing wrong with using Strict policy. But the way to configure it can definitely be better."?
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Admin
2019-02-1407:58 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Strict policy generally means that any traffic you want to allow through the gateway must have an explicit rule.
With VPN in particular, there are two actions for a given packet:
- For outgoing traffic:
- Access Policy enforcement based on the unencrypted traffic
- Whether to encrypt the traffic, which is based on the VPN configuration
- For incoming traffic
- Whether to decrypt the traffic, which is based on the VPN configuration
- Access Policy Enforcement based on the unencrypted traffic
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1512:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your answer.
I understand that I have to define explicit rules for any traffic in strict mode, but I don't understand the basic concept.
You said, we have to put and outgoing and a incoming rule for the unecrypted traffic(which makes sense in strict mode).
But in which section do I have to put my rules?
If we don't use the application control, we just use incoming and outgoing rules in the "Incoming, Internal and VPN traffic" section and it's working correctly. As soon we activate the application control, we have to add rules in the "Outgoing access to the Internet" to allow the outgoing (vpn) traffic.
We would like to activate application control only for outgoing Internet traffic and not for vpn traffic, is there any possibility to implement this?
I also don't understand the traffic flow.
How exactly does it work with the different firewall blades, is the following sequence correct?
Outgoing:
1.) Firewall blade(unecrypted traffic)
2.) Application control(unecrypted traffic)
3.) VPN blade(encrypts the traffic)
Incoming:
1.) VPN blade(decrypts the traffic)
2.) Firewall blade(unecrypred traffic)
3.) Application control(unecrypred traffic)
Maybe we can discuss this with a little example:
I've got two networks connected via Site-to-Site VPN tunnel.
network local: 192.168.1.0/24 network remote: 10.0.0.0/24
I like to allow any traffic between the local and the remote traffic.
In addition packets which are destinated to the Internet should be checked by the application control.
Where and how do I have to put my rules that have following behaviour work propely:
This has to work:
- SSH session from 192.168.1.10 to 10.0.0.10
- RDP session from 192.168.1.20 to 10.0.0.20
This mustn't work:
- RDP session from 192.168.1.10 to 88.88.88.88
- client connection to www.virus-downloader.ru
I hope you understand, what we want to achieve.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1510:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is just as you say. Outgoing rules include Application Control Blae and as such, it will analyze the traffic between your internal networks, including VPNs as well as your Outgoing traffic. If you don't want to analyze such traffic at all, add a rule bypassing traffic from a group of your internal networks to the same group.
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Admin
2019-02-1512:30 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Basically, VPN outbound traffic is still outbound traffic.
If you want to allow all traffic from your subnet to the remote subnet, there needs to be an explicit rule stating that.
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Contributor
2019-02-1804:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, now it makes sense...
Also a thank you to @ Emilio Espinosa
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Advisor
2020-03-1606:40 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'd like to share that I was working on a similar case with TAC... and got feedback that the behavior was changed from R77.20.87 Build 990172998 to not inspect APPI for outgoing connections over S2S-VPN; where it did in former builds.
From R77.20.87 Build 990173004, we have a new option in Advanced Settings: [Application Control and URL Filtering - Inspect VPN traffic] which is now disabled by default.
Its worth upgrading to the latest R77.20.87 GA if you're using strict firewall policy.
0
Kudos
Click here to give kudos to this post.
1
2
3
4
5
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Post Reply
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
sx8n20394 |
7 |
israelfds95 |
7 |
jorgeluiznim |
5 |
velo |
1 |
BikeMan |
1 |
emmap |
1 |
CEEJAY |
1 |
Max_Leorne |
1 |
Chris_Atkinson |
1 |
Trending Discussions
Reach My Device – A Native Option for Secure Remote Access to Quantum Spark Appliances
Downgrading a Quantum Spark Appliance: From 'Upgrade Not Supported' to a Working Boot Loader Recover
L2TP Remote Access VPN - Can't Connect on SMB 2550 R82.00.10
Upcoming Events
Sort by:
Tue 28 Jul 2026 @ 11:00 AM (EDT)
Under the Hood - Check Point and Illumio – Modern Network Defense Against AI-Based Threats
Wed 29 Jul 2026 @ 12:00 PM (SGT)
The AI Security Report 2026: A Turning Point for Enterprise Defense - SGT
Wed 29 Jul 2026 @ 02:00 PM (IDT)
The AI Security Report 2026: A Turning Point for Enterprise Defense - AMER
Wed 29 Jul 2026 @ 03:00 PM (CEST)
The AI Security Report 2026: A Turning Point for Enterprise Defense EMEA
Wed 29 Jul 2026 @ 11:00 AM (EDT)
TechTalk: On-Premise SD-WAN Management
Thu 30 Jul 2026 @ 11:30 AM (CDT)
CheckMates Live DFW: Agentic AI Security Deep Dive & Hands-On
Tue 28 Jul 2026 @ 11:00 AM (EDT)
Wed 29 Jul 2026 @ 12:00 PM (SGT)
Wed 29 Jul 2026 @ 02:00 PM (IDT)
Wed 29 Jul 2026 @ 03:00 PM (CEST)
Wed 29 Jul 2026 @ 11:00 AM (EDT)
TechTalk: On-Premise SD-WAN Management
Thu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI Gateway
Tue 11 Aug 2026 @ 11:30 AM (EDT)
New York City: Agentic AI Security Deep Dive & Hands-On
Thu 13 Aug 2026 @ 11:30 AM (EDT)
Waltham, MA: Agentic AI Security Deep Dive & Hands-On
Thu 20 Aug 2026 @ 08:30 AM (COT)
Medellin: Workspace Evolution: Hybrid Mesh Management - Visibilidad, Automatización e IA
Thu 20 Aug 2026 @ 06:00 PM (COT)
Medellin: Workspace Intelligence: IA Generativa en Acción para Equipos de Seguridad
Thu 27 Aug 2026 @ 09:00 AM (CEST)
Check Point Hands-On SASE and Cloud Workshop - Zurich
Wed 21 Oct 2026 @ 09:00 AM (BST)
AI Security Workshop - Glasgow
About CheckMates
Learn Check Point
Advanced Learning
Resources
Non-English Discussions
YOU DESERVE THE BEST SECURITY
We’re Social. Follow Us CheckMates on LinkedIn Check Point on YouTube CheckMates on Facebook CheckMates on Instagram
©1994-2026 Check Point Software Technologies Ltd. All rights reserved. Copyright Privacy Policy About Us UserCenter
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.