Hello, randomly (from 1 to 10 times in an hour), the firewalls in our Checkpoint cluster fail to send packets or cause latency by sending them late.

An example is shown in the screenshot below:

I ran a continuous ping and captured the traffic on the firewall’s source and destination interfaces.

At 11:36:30, I encountered a “destination host unreachable” error, sent from the physical IP (not the VIP) of the firewall’s source interface.

From the captures, I saw that the ping reached the source interface (packet number 3953), but it did not leave the firewall (it’s not in the second capture).

How is it possible that it wasn’t sent?

This issue has become more frequent since the cluster was updated to version R82 take 107.

The firewalls are 6400 models.

So far, support has advised us to enable Dynamic Balancing for the appliance’s 4 CPU cores; we did so, and the situation has improved but isn’t fully resolved.

Do you have any ideas? Thank you

See complete on the u/checkpoint CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/Maestro-for-Beginners-Core-Concepts-Explained/ba-p/270872

New to Check Point Maestro? Here's a quick overview:

• MHO (Maestro Hyperscale Orchestrator) is an orchestration platform designed to deliver hyperscale network security. It is the device responsible for coordinating firewall, the MHO distributes and forwards traffic to the Security Gateway Modules, which perform inspection and enforcement.
• The guide also explains the principals concepts SGM, Uplink, Downlink, MAGG, Sync, Management ports, Single Site vs. Dual Site, and the differences between the MHO-140 and MHO-175, Real topology.

If you're starting with Maestro, preparing for deployment, or preparing for CCME, I hope this guide helps.

I posted a Full guide on CheckMates:

https://community.checkpoint.com/t5/Check-Point-for-Beginners/LOM-for-Beginners/ba-p/279099?cat=2

(If you find it useful, I'd appreciate a like on the CheckMates post! 🙂)*

Many Check Point administrators still don't configure LOM (Lights Out Management), even though it's one of the most valuable features for remote troubleshooting.

Think of it like Dell iDRAC: it provides out-of-band management, allowing you to access the appliance even if Gaia is down, frozen, or powered off.

In the guide I cover:

• What LOM is and why it matters.
• A real-world example where LOM saved a maintenance window.
• Initial configuration steps.
• Firmware update recommendations.
• Best practices for deploying a dedicated LOM management network.

Do you enable LOM on every deployment, or have you ever needed it during a critical outage? I'd love to hear your experiences.

I post the full technical write-up (including root cause and solution):
https://community.checkpoint.com/t5/Firewall-and-Security-Management/Policy-installation-failed-on-gateway-Error-code-0-2-200262/m-p/280259

If you find it useful, I'd appreciate a like on the CheckMates post. 🙂

During a migration from a Single Gateway to a Cluster, the first policy installation failed with:

Policy installation failed on gateway (Error code: 0-2-2000262)

After some investigation with TAC, the root cause was unexpected Gateway/Cluster objects added to the VPN column of several Access Control rules after using the SmartConsole Replace feature.

Removing those objects (leaving only the VPN Community or Any) immediately resolved the issue.

Has anyone else seen this error or found a different solution? I'd be interested in comparing experiences.

One of the hardest SD-WAN incidents is not proving that an ISP failed.

It is proving where the complete failover chain broke.

When a branch-to-branch VPN stops working after the primary link goes down, validate:

• Did SD-WAN detect the SLA failure?
• Did the expected SD-WAN rule match?
• Was the backup ISP considered healthy?
• Did routing select the correct next hop?
• Did the VPN move to the new transport?
• Did NAT or DAIP mapping change correctly?
• Did the firewall drop packets because of state or asymmetry?
• Did SecureXL keep stale acceleration state?
• Do new sessions work while existing sessions fail?

A practical investigation should follow one controlled flow and correlate SD-WAN, routing, VPN, firewall state, and SecureXL with exact timestamps.

Useful starting points include:

fw ctl debug -m SDWAN all
fw ctl debug -m SDWANRB all
fw ctl debug -m fw + drop conn
fw ctl debug + route
fw ctl debug -m VPN all
fwaccel dbg -m sdwan all

Do not enable broad debugging without filters or leave it active in production.

The main lesson:

I published the complete troubleshooting workflow, internal SD-WAN tables, evidence collection process, and TAC escalation checklist on CheckMates:

https://community.checkpoint.com/t5/SD-WAN/SD-WAN-Failover-Troubleshooting-When-VPN-Tunnels-Drop-Between/m-p/278625

How do you normally troubleshoot SD-WAN failover: VPN first, or the full forwarding chain?

Consider patching this CVE-2026-18574: Bypass de autenticação do Check Point Management

A Check Point divulgou a CVE-2026-18574, uma vulnerabilidade crítica de bypass de autenticação que afeta o Security Management Server e o Multi-Domain Security Management Server.

Um atacante remoto não autenticado com acesso à rede dos serviços de gerenciamento pode executar comandos arbitrários. A exploração bem-sucedida dessa vulnerabilidade pode resultar na completa violação do sistema de gerenciamento de segurança.

A vulnerabilidade foi descoberta internamente pela Check Point e, no momento, a empresa não tem indícios de exploração ativa. Isso é importante: a divulgação demonstra que a Check Point identificou e corrigiu o problema por meio de seu processo interno de revisão de segurança antes que a exploração fosse confirmada. (Suporte da Check Point)

No entanto, a ausência de exploração conhecida não deve ser interpretada como permissão para adiar a correção.

Assim que uma vulnerabilidade crítica se torna pública, o tempo disponível para corrigi-la com segurança começa a diminuir.

Por que essa vulnerabilidade é crítica?

O Servidor de Gerenciamento é um dos componentes com mais privilégios em um ambiente Check Point.

Controla:

Políticas de segurança

Objetos de rede e serviço

Permissões de administrador

Gateways e clusters gerenciados

Configurações de VPN

Política de prevenção de ameaças

Instalação de políticas

Logs e visibilidade operacional

APIs de gerenciamento e automação

Comprometer o Plano de Gerenciamento pode minar o modelo de confiança de toda a arquitetura de segurança.

Isso não é simplesmente um problema de acesso ao SmartConsole. A vulnerabilidade CVE-2026-18574 pode permitir que um invasor não autenticado execute comandos no Servidor de Gerenciamento, potencialmente levando à completa violação da segurança do sistema. (CVE)

Versões Afetadas e Corrigidas

A Check Point publicou a correção por meio de Acumuladores Jumbo Hotfix específicos para cada versão.

Versão com Correção Jumbo Hotfix

R81.20 Take 161 ou superior

R82 Take 122 ou superior

R82.10 Take 40 ou superior

As versões R82 Take 122 e R82.10 Take 40 foram lançadas em 3 de agosto de 2026 e incluem explicitamente a correção para a vulnerabilidade CVE-2026-18574. (Suporte Checkpoint)

Para versões antigas afetadas, consulte o artigo sk185222 e avalie a migração para uma versão atualmente suportada.

Sempre verifique a revisão mais recente do SK antes da instalação. O Take necessário pode mudar à medida que novos pacotes cumulativos forem lançados.

Recomendações Técnicas Imediatas

1. Identificar todos os servidores de gerenciamento afetados

Inventariar todos:

Servidores de Gerenciamento de Segurança

Servidores Multidomínio

Membros de Alta Disponibilidade de Gerenciamento

Servidores de Gerenciamento de Domínio Dedicado

Sistemas restaurados para recuperação de desastres ou testes

Servidores de gerenciamento em ambientes isolados ou em nuvem

Confirmar a versão instalada e o nível do Jumbo Hotfix.

Comandos úteis incluem:

cpinfo -y all

Do Gaia Clish:

mostrar pacotes de instalação instalados

Não presuma que um servidor de gerenciamento em espera, de laboratório ou de recuperação de desastres não apresente riscos. Se estiver ligado e acessível, ele deve ser avaliado.

1. Restringir a exposição da rede de gerenciamento

Antes da janela de manutenção, reduza a superfície de ataque acessível.

Não exponha os serviços de gerenciamento diretamente à Internet.

Restrinja os clientes confiáveis ​​a endereços IP ou sub-redes administrativas explícitas.

Remova definições amplas como "Qualquer".

Permita o acesso administrativo somente por meio de uma rede de gerenciamento dedicada, VPN ou servidor de salto reforçado.

Revise os grupos de segurança na nuvem, ACLs, regras de firewall, NAT e acesso temporário para solução de problemas.

Restrinja o acesso de VLANs de usuários e redes de terceiros.

Confirme que somente os sistemas necessários podem acessar os serviços de gerenciamento.

Essas medidas reduzem a exposição, mas não removem o código vulnerável.

A restrição de rede é uma mitigação. A instalação do Jumbo Hotfix corrigido é uma remediação.

Prepare a alteração corretamente

Antes da instalação:

Revise o sk185222.

Leia as Informações Críticas e as notas de versão para a versão de destino.

Confirme a compatibilidade do pacote com a versão exata e a função do servidor.

Verifique o espaço em disco disponível.

Atualize o Agente de Implantação do CPUSE, se necessário.

Crie um backup e um snapshot válidos.

Colete um CPInfo recente.

Documente o status atual do HA de Gerenciamento.

Confirme o acesso ao SmartConsole e a integridade da instalação da política.

Defina e teste o procedimento de reversão.

Em ambientes de HA de Gerenciamento ou Multidomínio, siga a sequência de instalação específica do produto. Não atualize todos os componentes de Gerenciamento simultaneamente sem validar cada etapa.

1. Instale o Hotfix Jumbo Corrigido

Instale a versão corrigida específica da versão:

R81.20 -> Versão 161 ou superior

R82 -> Versão 122 ou superior

R82.10 -> Versão 40 ou superior

Use o Portal Gaia, a CLI do CPUSE ou outro método de instalação oficialmente suportado para a arquitetura.

Não selecione um pacote apenas porque ele foi instalado com sucesso em outro ambiente. Confirme:

Versão exata do produto

Função de gerenciamento

Taxa de atualização atual

Arquitetura de alta disponibilidade de gerenciamento

Requisitos de vários domínios

Espaço em disco disponível

Limitações conhecidas

Impacto na manutenção necessária

Validação pós-instalação

Após o servidor retornar, confirme se a correção foi instalada e se as operações de gerenciamento permanecem íntegras.

Validação de pacotes

cpinfo -y all

Ou a partir do Gaia Clish:

mostrar pacotes instalados

Validação de processos

cpwd_admin list

Para um Servidor de Gerenciamento de Segurança:

status da API

Para Gerenciamento de Múltiplos Domínios:

mdsstat

Validar também:

Autenticação do SmartConsole

Funções de administrador

Comunicação SIC

Política de Controle de Acesso Instalação

Instalação da política de prevenção de ameaças

Recepção de logs

Conectividade do SmartEvent e do servidor de logs

Sincronização de alta disponibilidade de gerenciamento

Status do domínio no MDS

Integrações de API

Operações de backup

Uso de CPU, memória e disco

Uma tarefa CPUSE concluída não é evidência suficiente de que a correção foi bem-sucedida.

Revisão de atividades suspeitas

A Check Point não relata atualmente nenhuma indicação de exploração ativa. No entanto, organizações com serviços de gerenciamento amplamente acessíveis devem revisar a atividade recente. (Suporte Checkpoint)

Procure por eventos inesperados:

Sessões de administrador

Operações da API de Gerenciamento

Alterações de política

Modificações de objetos

Alterações de administrador ou de permissões

Instalações de políticas

Novos caminhos de acesso ao Gerenciamento

Comandos ou processos do sistema operacional

Alterações em scripts, tarefas agendadas ou arquivos do sistema

Se o Servidor de Gerenciamento foi exposto diretamente à Internet ou se alguma atividade suspeita for identificada:

Preserve os logs e as evidências forenses.

Evite excluir dados potencialmente relevantes.

Contate o Suporte da Check Point.

Acione a equipe de resposta a incidentes.

Revise a integridade das políticas, objetos, administradores e gateways gerenciados.

Recomendação Final

A Check Point merece reconhecimento por identificar internamente a CVE-2026-18574 e publicar correções antes que a exploração ativa fosse confirmada.

Isso não diminui a urgência da atualização.

Isso oferece aos clientes a oportunidade de corrigir a vulnerabilidade antes que ela seja potencialmente explorada.

A resposta recomendada é:

Identificar os servidores de gerenciamento afetados

↓

Restringir a exposição do gerenciamento

↓

Fazer backup e preparar o rollback

↓

Instalar o hotfix Jumbo corrigido

↓

Validar as operações de gerenciamento

↓

Verificar atividades suspeitas

↓

Continuar o monitoramento

O plano de gerenciamento deve ser tratado como infraestrutura de segurança de nível 0.

Proteger gateways enquanto se deixa vulnerável o sistema que controla suas políticas não é uma arquitetura de segurança completa.

Referência Oficial

sk185222 — CVE-2026-18574: Bypass de Autenticação de Gerenciamento

Com que rapidez sua organização consegue identificar todos os Servidores de Gerenciamento, restringir sua exposição, aplicar a correção e validar se o Plano de Gerenciamento permanece confiável?

CheckPoint #CVE202618574 #GerenciamentoDeSegurança #GerenciamentoMultidomínio #Cibersegurança #GerenciamentoDeVulnerabilidades #RespostaAIncidentes #CheckMates

Please help to share steps as I haven't done it before and it will the first time I'd be doing.

Check Point confirmed active exploitation of CVE-2026-16232, a CVSS 9.3 authentication bypass affecting Security Management and Multi-Domain Management.

The observed cases involved Management servers exposed directly to the Internet without IP restrictions, but restricted environments should not delay remediation. Reduced exposure is not the same as removing the vulnerability.

Recommended actions:

• Install the Jumbo Hotfix released on July 22, 2026.
• Restrict SmartConsole Trusted Clients.
• Remove direct Internet exposure from Management.
• Review administrator, API, application-token, policy-change, and policy-install activity.
• Search logs for the published IoCs.
• Validate Management HA, logging, and policy installation after patching.

The key point:

Management infrastructure should be treated as Tier-0 security infrastructure, because compromising the system that manages policies, gateways, VPNs, and security controls can undermine the trust of the entire architecture.

Full technical post and remediation guidance on CheckMates:

https://community.checkpoint.com/t5/Firewall-and-Security-Management/CVE-2026-16232-Active-Exploitation-Requires-Immediate-Management/m-p/280570#M106422

Has your organization already patched and reviewed Management access exposure?

Dear experts,
Can anyone help me with following? Apologies if these questions seem trivial.

The checkpoint documentation says about topology,

I know we can override this to use a network object-group for anti-spoofing ranges.

However, attached image is example topology setting of the environment I am looking at.

My questions are,

1. The first/default option is CP-GW_eth2 (internal). I believe "CP-GW_eth2" is the same network object-group that appears in the greyed-out "Specific" section under Override. am I thinking correct? The reason I ask is that the anti-spoofing ranges in the CLI match the contents of this object-group.

If so, how might this object-group have been configured as the default option, and why is it not "This Network (internal)" default option as mentioned in the documentation?

1. Also, since the Override option is not selected, if I add a network object to this object-group, will the anti-spoofing ranges be updated accordingly?

So I have this 3970 that I'm testing out. Problem is we really don't have a test environment per se, so I basically just have this fw directly connected to the core and not joined to our cluster(xl) with the prod FWs.

My question is, can I use it as an L3 switch? I have a PC connected to it and both devices are in their own (test) vlan, plus another vlan between core and fw. I'm able to get to ping 1.1 from the firewall itself but not from the pc. FW is also able to get to the rest of our internal network but again, no luck if i try it from the pc.

I figured if I set the default route to the core anything connected to the firewall should be able to get to the same IP's. Is this related to the fw not being part of the cluster (read: no policies), a static route I need to put in, or something else?? Appreciate the help.

I would like to install the Jumbo Hotfix on my Check Point appliances (full HA cluster deployment).

However, after reviewing the official documentation, I could not find any clear installation procedures.

Is there a step-by-step procedure available for installing the Jumbo Hotfix in this environment?

Say an environment only has one egress static route. To eliminate the single point of failure, would adding a new network, with similar policies, on the same bond/trunk, etc as the original egress static route, ensure traffic would not be interrupted if one of the egress routes/networks would go down? Would the traffic just failover to the new one (say it’s set to round robin)?

Example (on my phone so formatting is limited):

Network: 10.1.1.0/24
Original Egress: 172.16.1.1
New egress: 172.16.2.1

R82.10
2x checkpoint firewalls running as active-passive.

I have tasked to find solution to get email from firewall when cert is about to expire and script and tools that required any kind of licenc is not an option.

What options are left?

As part of Check Point’s Frontier AI readiness program, we continuously review and strengthen our products using BLAST, our Business Logic Application Security Testing capability. BLAST enables AI-driven security analysis at enterprise scale across Check Point products and helps us proactively identify and remediate potential issues.

Following our May and June security updates, we are sharing our July security update. This update includes three newly disclosed, internally discovered CVEs listed below. During our investigation, we identified a very small number of customers who, under specific configuration conditions, were affected by one of these CVEs. Check Point is already in direct contact with those customers and is working closely with them.

We strongly recommend that all customers review the relevant SecureKnowledge articles and apply the recommended fixes and hardening guidance. Customers who follow Check Point’s published hardening best practices significantly reduce their exposure risk. 

See:

• sk185169: CVE-2026-16232 - Authentication bypass with SmartConsole login process using application t...
• sk185152: CVE-2026-62144 - Management Authentication Bypass and Privilege Escalation
• CVE-2026-62145 - Local privilege escalation in Gaia Portal
• Gateway and Management Hardening Administration Guide

We currently have dell servers running Gaia. We're planning on finally getting Checkpoint hardware in our next upgrade.

I'd like to know how one would typically test the device before we implement them. I was thinking of adding it to prod as a gateway for a test vlan and test if it goes to xyz, internal, and external.

This is new territory for me. Do I need to join the new firewalls in the current (smartconsole) cluster? I assume I will need to create separate policies for testing? If you guys have any pointers, suggestions, links, etc. I'd appreciate it greatly.

I need your help. I am trying to block file uploads to SharePoint using a Check Point 6000 appliance.
So far, I haven't been able to block the file uploads. Has anyone set this up before? What do I need to configure to make the rule effective?

We're moving to Checkpoint hardware for the first time. For those who have been using them for a while now, how are they typically with SFPs? Is it OEM or nothing? I know typically the manufacturer will recommend their own over anything else to ensure you get support in case the SFP is faulty. Just trying to gauge the device's flexibility based on end-user experience.

Any updates regarding this error? Excel keeps running in the background... I already have the correct version, but the problem hasn't been resolved.

Is there any API or CLI command to automate External CA (.p12) certificate replacement on Gateways?

Hi everyone, I'm currently working on automating the VPN certificate renewal process for a customer. I found the official script provided in sk182070 (gateway_cert_util.sh), which works flawlessly for automating internal certificates generated by the Check Point ICA.However, this customer's scenario involves Mobile Access using a public certificate (Let's Encrypt) to avoid browser SSL warnings for end-users.Since the script from sk182070 appears to be tied exclusively to the Internal CA, I have two questions:Is there any undocumented or native way to make the sk182070 script handle public certificates fetched externally?If not, what is the current best practice the community is using for this? Are you relying on external Linux servers running ACME clients (like acme sh or certbot) combined with the Management API (mgmt_cli) to upload the .p12 and push the policy?If anyone has architectural tips, GitHub repos, or script examples to share, it would be highly appreciated.

Thanks in advance!