Tag: Check Point

Check Point R77.30 new sub interface not forwarding traffic

February 12, 2020 / / 0 Comments

As it seems on Check Point R77.30 Take_351, it is possible that after adding a new VLAN interface a it may fail to route traffic. When looking at the cluster status, everything seems OK. But when you take a look at the routing table you notice that actually the newly added network is missing.

Doing the usual “cpstop & cpstart” does not fix the issue. What actually was needed to get it to forward traffic to the good old “have you tried turning it off and on again”. If it happens on your primary cluster node just fail over to the secondary node and reboot.

Network security policy installation failure fix

April 13, 2018 / / 0 Comments

Some times your network policy installations on Check Point devices might fail.  For me it happened after updating a gateway cluster to the “latest and greatest R77” version. I was unable to push the policy and I was getting the “/opt/CPSFWR77CMP-R77/conf/policy-name.pf”, line 912700: ERROR: target <fw-name> is prohibited” error message.

In order to see what is actually causing the error you will need to log in to the management server via SSH. Go in to “expert mode” and look at what is on the line that the error message is pointing at.

So basically, to fix the issue in my case/work around, I did the following:

  1. Logged in to the security management server in expert mode
  2. Opened up the policy file from the place it was complaining about with the less command. (Hints on how to go to a specific line can be found stackoverflow topic here)
  3. In my case on that specific line I saw a list of DPD(dead peer detection for IPSec VPN) peers which hinted that I should try and disable DPD
  4. Logged in to the management server using smart dashboard, removed permanent tunnel ticks on VPN’s relating to the GW cluster with the issue and tried installing the policy.
  5. Policy successfully installed..

After that I reported the bug to Check Point support and they confirmed the issue..

Enabling DPD on VPN instead of tunnel_test on R77 gateway

March 23, 2018 / / 0 Comments

To keep VPN tunnels alive Check Point uses by default it’s proprietary tunnel_test protocol. In order to get it working with 3rd party vendors it isn’t enough to have the partner device set as an “Interoperable device” and set the tunnel keep alive method on your gateway object as DPD. You also need to set the peer gateway’s tunnel keep alive method as DPD, because by default it is still set to tunnel_test.

To change the keep alive methods you need to do the following as described on Check Point’s website here:

  1. In GuiDBedit, go to Network Objects > network_objects > <gateway> > VPN > tunnel_keepalive_method.
  2. For the Value, select a permanent tunnel mode.
  3. Save.
  4. Install policy on the gateways.

CheckPoint VPN with failed connection not showing up in SmartView Tracker

March 7, 2018 / / 0 Comments

Scenario description

You might have an old existing VPN with some partner which to a gateway that is not under your control. That peer gateway used to be also a CheckPoint device but get’s exchanged for some other 3rd party vendor firewall with out prior notification. When the peer gateway gets changed, the key exchange seems to work, but connection’s fail and nothing seems to be showing up in SmartView tracker although connection logging is on.

Finding out what is happening and trying to fix it

After seeing no traffic in SmartView tracker, you log in to the gateway and might look at tcpdump to see if there is actually any traffic coming from the peer gateway. After seeing there is actual traffic coming you should try a few kernel level debug commands on VPN to get some info on whats happening. For example run “fw ctl zdebug -m VPN all” and you might see something like this in the output:

 [cpu_1];[fw4_0];fw_log_drop_conn: Packet <dir 1, 192.168.200.100:0 -> 172.32.200.100:0 IPP 50>, dropped by do_inbound, Reason: decryption failed

Well this still isn’t saying too much, but at least is giving a hint. Next lets take a look at the secure XL debug, maybe it gives some more info. To get the output prepare the debug first by using the following commands:

[Expert@HostName:0]# fw ctl debug 0
[Expert@HostName:0]# fw ctl debug -buf 32000
[Expert@HostName:0]# sim dbg -m vpn all
[Expert@HostName:0]# sim dbg -m mgr + vpn
Now start the debug:
fw ctl kdebug -T -f > /tmp/debug.txt

Let it run for a bit and close it with ctrl+c. Go through the log file, you might find something like this:

;11Jul2017 13:14:57.017362;[cpu_1];[SIM-xxxx]vpn_ipsec_decrypt: Packet does not match block size (xx xx xx);

;11Jul2017 13:14:57.017362;[cpu_1];[SIM-xxxx]vpn_decrypt: IPSEC decryption failed;

Well this is odd. You contact the peer gateway’s technical contact asking if have they changed anything lately and find out that they changed their firewalls..

Fixing the issue

To remedy the issue create a new gateway object that is of the “Interoperable Device” type and has all the same settings/parameters as the previous the peer gateway object that was with the “Check Point gateway” type. Change the peer GW object in the VPN community to the newly created “Interoperable device” and install policy. And the traffic starts flowing again.

As it seems Check Point is handling VPN tunnels differently between Check Point devices and Interoperable devices.