Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
MonoAEK21
Explorer

Problem with Capsule on 3900 R82.10 Take 24

I have a cluster of 2 3900's R82.10 initially Take 22.

I want to upgrade both to R82.10 Take 24.

When I did the first one and failover to it to handle traffic, (clusterXL is healthy no pnotes or any other problem, and sessions are correctly synchronized between members), Capsule VPN does not work in IPSec Mode only in SSL mode.

Office mode is not offered by the Firewall but from a DHCP server. When trying to connect via Capsule in SSL it connects immediately and works fine. However in IPSec mode it says "Failed to allocate IP address". Pool is fine, i get correct authentication log followed by a "drop" log with the public IP of the capsule as source indicating the same problem.

ipassignment.conf files are identical (non-changed at both Firewalls). 

The only useful thing I could get from my troubleshooting is that when z-debug with the IP of the DHCP server, whenever I try to connect via Capsule with IPSec it shows this immediately:

@;2378783.1152;[vs_0];[tid_0];[fw4_0];fw_log_drop_ex: Packet proto=17 <DHCPSERVERIP>:67 -> <FWINTERFACEIP>:68 dropped by fw_post_vm_chain_handler Reason: Handler 'dhcp_reply_code' drop;

(addresses hidden by me).

Is there any limitation on how these Firewalls in this firmware handle dhcp requests/replies?

To note, when failovering back to the non-upgraded one everything works correctly.

 

Thank you!

0 Kudos
10 Replies
PhoneBoy
Admin
Admin

That error may be a red herring.
However, it sounds like a TAC case is in order.

0 Kudos
Alex_Nikitin
Participant

Good afternoon! I’m seeing similar behavior. Could you tell me if a solution was found?

0 Kudos
Chris_Atkinson
MVP Diamond CHKP MVP Diamond CHKP
MVP Diamond CHKP

Are you running JHF44 currently?

DHCP symptoms were previously seen per sk183675 (before JHF T22), is this an EXL cluster sk1000233?

 

CCSM R77/R80/ELITE
0 Kudos
Jan_Kleinhans
Advisor

We also seem to have this issue on checkpoint 19200 vsx cluster and Checkpoint mobile on iOS and Android.

 

0 Kudos
Alex_Nikitin
Participant

Good afternoon!
We are using JHF Take 40. It is not an EXL cluster; it is a standalone OpenServer setup.
0 Kudos
Jean-Francois_G
Contributor

Hi everyone,

 

We are experiencing a very similar issue with Capsule VPN on our Check Point Quantum 9400 ElasticXL cluster running R82.10 JHF Take 50.

 

The issue was already present on JHF Take 44, and upgrading to Take 50 did not resolve it.

 

Our issue mainly affects Capsule VPN on iOS and Android which fails with the error "Failed to allocate an IP address".

 

We use a Windows DHCP server to assign Office Mode IP addresses.

 

During troubleshooting, we confirmed that:

 

- VPN authentication completes successfully.

- The gateway sends a DHCP Discover to our Windows DHCP server.

- The DHCP server responds immediately with a DHCP Offer.

- However, no DHCP Request follows, and Capsule VPN eventually fails to connect.

 

We have an open TAC case (6-0004733237), and Check Point Support is investigating the issue.

 

Has anyone managed to resolve this issue, either through a specific hotfix, configuration change, or workaround?

 

Since upgrading from Take 44 to Take 50 did not help in our environment, we would be particularly interested in hearing whether anyone has received a working solution from Check Point.

 

Thanks in advance for any feedback!

0 Kudos
Jan_Kleinhans
Advisor

Hello Jean,

our problem is exactly the same. But if you switch to SSL-VPN, the connnection works. The engineers don't have a solution at the moment. Maybe our TAC number can help. 6-0004734468

I will inform you if we get a solution.

Best regards,

Jan

 

Jean-Francois_G
Contributor

Thank you all for your help!

I just tested switching Check Point Capsule VPN from IPsec to SSL VPN, and I can confirm that the connection now works successfully without error 901 ("Failed to allocate an IP address").

I've also shared this information with Check Point Support through my open TAC case.

Thanks again!

0 Kudos
Alex_Nikitin
Participant

Good afternoon!
We are in the same situation as you. We have an open case with technical support. For the time being, we have switched our users to an SSL connection. I will let you know if a solution is found.

Alex_Nikitin
Participant

TAC number 6-0004712614

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events