topic Re: CheckPoint appliances behind other CheckPoint firewall in Firewall and Security Management

CheckPoint appliances behind other CheckPoint firewall

Ilya_Avetisyan — Sun, 02 Dec 2018 17:49:32 GMT

Hello everybody

Faced with strange issue. In our company we use 2 CheckPoint appliances (a cluster) as gateway to Internet. Now we purchased 2 more gateways (they also joined to a cluster) to protect our servers network segment. So, these gateways are behind our Internet gateway. To allow them to get updates, check licenses, etc., I added rules to Internet gateways and everything is working. The gateways for servers able to see Internet but when I install policy for them they stop to see anything. If I unload policy (fw unloadlocal) they start to see the Internet again. I tried to enable proxy server on 'internet' gateway in hope that these servers gateways will contact with Internet through that proxy but no luck...

Still googling to solve the problem but no ideas at all.

Re: CheckPoint appliances behind other CheckPoint firewall

Kaspars_Zibarts — Sun, 02 Dec 2018 19:14:53 GMT

Sounds like your drop rule is doing it. Have you checked logs for dropped traffic originating from server gateways? Or adding specific rule to permit this traffic?

Re: CheckPoint appliances behind other CheckPoint firewall

Ilya_Avetisyan — Mon, 03 Dec 2018 05:55:44 GMT

Hi Kasparas,

Thank you for fast reply. There are 2 permit rules were created - one installed on 'internet' gateway to allow access to Internet for 'servers' gateway and one 'allow all to all' which is installed onto 'servers' gateway. When I check logs I see that 'internet' gateway allows all for 'servers' gateway.

Re: CheckPoint appliances behind other CheckPoint firewall

Kaspars_Zibarts — Mon, 03 Dec 2018 06:32:26 GMT

But do you see a log for unsuccessful case for "server" firewall? Have you tried packet capture to see if traffic actually leaves "server" firewall when it does not work?

Re: CheckPoint appliances behind other CheckPoint firewall

Ilya_Avetisyan — Mon, 03 Dec 2018 06:45:31 GMT

Here the log. Traffic from 'server' gateway is allowed but it can not reach requested destination.

Here what I see if I perform 'fw unloadlocal' command at 'server' gateway

As you may see traffic is always allowed. The problem is in 'server' gateways themselves.

I did not try to capture the packets yet.

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Mon, 03 Dec 2018 07:46:17 GMT

Please make sure those "internal GWs" are NAT-ed properly. They should be either using NAT Hide on the external GW with other elements of the internal networks or be statically NAT-ed on the external GW with automatic NAT.

Also, make sure they are defined with main IPs that are mentioned in your NAT rules.

Finally, putting traces with fw monitor would help to see where the internet packets are going, after policy installation

Re: CheckPoint appliances behind other CheckPoint firewall

Ilya_Avetisyan — Mon, 03 Dec 2018 08:04:14 GMT

Finally solved it...

These 2 gateways were joined into 'active-active' cluster with 'multcast' load sharing. I changed it to 'unicast' and set 'use virtual mac' option and everything started to work.

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Mon, 03 Dec 2018 08:14:32 GMT

Why oh why Russian guys always want LS clustering??? It creates more issues than resolves

Re: CheckPoint appliances behind other CheckPoint firewall

Ilya_Avetisyan — Mon, 03 Dec 2018 08:30:04 GMT

Do we? 🙂 Is LS bad feature?

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Mon, 03 Dec 2018 08:41:41 GMT

Yes you do. I rarely see LS in production in Europe while it is all over Russia for some reason. LS is not "bad" per se, but it needs to be used with caution and understanding of all implications. It is definitely should not be the default clustering mode for physical gateways, and it does not really boost performance of a two GW cluster on a level that would "compensate" all inconveniences and limitations.

Mind all above is my private opinion, and it is off-topic here 🙂

Re: CheckPoint appliances behind other CheckPoint firewall

AlekseiShelepov — Mon, 03 Dec 2018 08:54:42 GMT

We love challenges and something interesting to fix!

But usually it's just difficult to explain to managers or engineers of customers why active-active is not recommended, why it causes more issues than adds performance. Because "if vendor makes it available in configuration, then why it is not recommended"? Active-active adds some more performance, so for them it is seen as a good thing. And if customer really wants it, integrators will implement it in that way.

Can Check Point provide an official statement that active-active is not recommended (although supported) for a cluster with two gateways?

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Mon, 03 Dec 2018 11:18:48 GMT

Here is the misconception: Active-active adds some more performance, so for them it is seen as a good thing.

LS in Multicast mode does add some throughput in sterile conditions without any significant load, but it also introduces some other limitations and caveats, such as SDF, Flash&ACK Sync requirements, loss of SecureXL acceleration, etc.

Unicast mode with two members means 70% of traffic being forwarded to the second member, so once more, increased performance here is questionable.

There is actually a document describing the limitations of LS mode: ClusterXL Load Sharing mode limitations and important notes

In addition, you can always refer to ClusterXL ATRG to the relevant chapters.

As for the official recommendations, you may have mentioned Check Point is very cautious about calling supported features as "non recommended" in any general sense. Each functionality can be required and productive in specific scenarios. For example, using unicast LS mode might help to cope with outdated switches and routers that cannot handle multicast traffic and gratuitous ARPs.

In my personal experience, however, the usual justification of using LS mode specifically in your region is usually "why the second box does not pass any traffic if we paid for it". It is not a proper engineering argument, in my book.

Re: CheckPoint appliances behind other CheckPoint firewall

HeikoAnkenbrand — Mon, 03 Dec 2018 21:45:18 GMT

I agree with Valeri here.

Unicast mode with two members means 70% of traffic being forwarded to the second member, so once more, increased performance here is questionable.

I already had the following problem with LS Unicast mode:

In unicast mode I already had problems with sync interface. For example, if the firewall has 10x1GBit network interface, it must transmit the flash and ACK trafic over the sync interface. This can overload the sync interface in special cases. Here RX-DRP errors occurred. Then the cluster didn't work properly anymore and I had many side effects.

I wouldn't use LS Unicast mode and it doesn't look likes any better with LS Multicast mode.

Regards

Heiko

Re: CheckPoint appliances behind other CheckPoint firewall

AlekseiShelepov — Mon, 03 Dec 2018 22:09:45 GMT

"why the second box does not pass any traffic if we paid for it".

Exactly. And don't forget "if the vendor put a checkbox for this setting, then it must work well".

So, as you noticed, all technical explanations go away. And that's the answer to your question about why it is popular in Russia.

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Tue, 04 Dec 2018 07:55:36 GMT

...which is personally find not compelling enough...

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Tue, 04 Dec 2018 07:57:51 GMT

>>> it must transmit the trafic over the sync interface

This is incorrect. Forwarding is done on the interface that receives a packet. You sync issue most probably is caused by excessive Flash&Ack.

Re: CheckPoint appliances behind other CheckPoint firewall

HeikoAnkenbrand — Tue, 04 Dec 2018 08:19:00 GMT

I have been mispronouncing here. Your statement is correct.

Re: CheckPoint appliances behind other CheckPoint firewall

_Val_ — Tue, 04 Dec 2018 09:34:03 GMT

no prob.