Application Control Bug!?

[sdellsperger]

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

[G_W_Albrecht]

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 .

[sdellsperger]

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?

[HristoGrigorov]

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. 

[Pedro_Espindola]

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.

[sdellsperger]

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...

[Pedro_Espindola]

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.

[G_W_Albrecht]

Right - therefore it is called strict...

[sdellsperger]

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?

[Pedro_Espindola]

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.

[sdellsperger]

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...

[Pedro_Espindola]

Ok. Then it has very few implied rules.

[sdellsperger]

Yes, I think there only essential rules for "This GW"-object.

[HristoGrigorov]

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.

[sdellsperger]

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."?

[PhoneBoy]

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

[sdellsperger]

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.

[Emilio_Espinosa]

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.

[PhoneBoy]

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.

[sdellsperger]

Thanks, now it makes sense...

Also a thank you to @Emilio Espinosa

[Tom_Hinoue]

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.