CheckPoint denies connection even after Push Approval

Protecting Applications forum VPN
1

Hello all,

we are implementing DUO MFA für CheckPoint 80.40 (we can’t upgrade to the last version right now).

In our test environment everything works good, but in the production environment we faced an issue: even after connection was Approved in DUO App the CheckPorint VPN Client tells us: access denied - wrong credentials.

rad1
rad1766×489 17.6 KB

In DUO Proxy we don’t see any denies:

2023-04-24T15:20:59.251297+0200 [duoauthproxy.lib.log#info] Sending request from CheckPoint_10.10.10.1 to radius_server_auto
2023-04-24T15:20:59.252485+0200 [duoauthproxy.lib.log#info] Received new request id 170 from ('CheckPoint_10.10.10.1', 47357)
2023-04-24T15:20:59.252921+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): login attempt for username 'test.vpn.mfa'
2023-04-24T15:20:59.253716+0200 [duoauthproxy.lib.log#info] Sending request for user 'test.vpn.mfa' to ('NPS_10.20.20.2', 1812) with id 106
2023-04-24T15:20:59.263847+0200 [duoauthproxy.lib.log#info] Got response for id 106 from ('NPS_10.20.20.2', 1812); code 2
2023-04-24T15:20:59.265053+0200 [duoauthproxy.lib.log#info] http POST to https://*****.duosecurity.com:443/rest/v1/preauth
2023-04-24T15:20:59.267428+0200 [duoauthproxy.lib.http._■■■■■■■■■■■■■■■■■■■■#info] Starting factory <_■■■■■■■■■■■■■■■■■■■■: b'https://*****.duosecurity.com:443/rest/v1/preauth'>
2023-04-24T15:20:59.395863+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Got preauth result for: 'auth'
2023-04-24T15:20:59.396312+0200 [duoauthproxy.lib.log#info] User IP not provided. Authorized Networks policies will not work for this authentication.
2023-04-24T15:20:59.396768+0200 [duoauthproxy.lib.log#info] http POST to https://*****.duosecurity.com:443/rest/v1/auth
2023-04-24T15:20:59.398511+0200 [duoauthproxy.lib.http._■■■■■■■■■■■■■■■■■■■■#info] Starting factory <_■■■■■■■■■■■■■■■■■■■■: b'https://*****.duosecurity.com:443/rest/v1/auth'>
2023-04-24T15:20:59.399225+0200 [duoauthproxy.lib.http._■■■■■■■■■■■■■■■■■■■■#info] Stopping factory <_■■■■■■■■■■■■■■■■■■■■: b'https://*****.duosecurity.com:443/rest/v1/preauth'>
2023-04-24T15:21:03.566848+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Duo authentication returned 'allow': 'Success. Logging you in...'
2023-04-24T15:21:03.568360+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Returning response code 2: AccessAccept
2023-04-24T15:21:03.568630+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Sending response
2023-04-24T15:21:03.568928+0200 [duoauthproxy.lib.http._■■■■■■■■■■■■■■■■■■■■#info] Stopping factory <_■■■■■■■■■■■■■■■■■■■■: b'https://*****.duosecurity.com:443/rest/v1/auth'>
2023-04-24T15:21:04.250528+0200 [duoauthproxy.lib.log#info] Sending request from CheckPoint_10.10.10.1 to radius_server_auto
2023-04-24T15:21:04.250895+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Received duplicate request
2023-04-24T15:21:04.251783+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Sending response
2023-04-24T15:21:09.250644+0200 [duoauthproxy.lib.log#info] Sending request from CheckPoint_10.10.10.1 to radius_server_auto
2023-04-24T15:21:09.250987+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Received duplicate request
2023-04-24T15:21:09.252491+0200 [duoauthproxy.lib.log#info] (('CheckPoint_10.10.10.1', 47357), test.vpn.mfa, 170): Sending response

TCP Dump shows that DUO answers:

14:50:29.972117 IP DUO_10.20.20.22.datametrics > CheckPoint_10.10.10.1.57779: RADIUS, Access-Accept (2), id: 0xa4 length: 222
14:50:30.484452 IP CheckPoint_10.10.10.1.57779 > DUO_10.20.20.22.datametrics: RADIUS, Access-Request (1), id: 0xa4 length: 128
14:50:30.485961 IP DUO_10.20.20.22.datametrics > CheckPoint_10.10.10.1.57779: RADIUS, Access-Accept (2), id: 0xa4 length: 222
14:50:35.484615 IP CheckPoint_10.10.10.1.57779 > DUO_10.20.20.22.datametrics: RADIUS, Access-Request (1), id: 0xa4 length: 128
14:50:35.485912 IP DUO_10.20.20.22.datametrics > CheckPoint_10.10.10.1.57779: RADIUS, Access-Accept (2), id: 0xa4 length: 222

We have already tried following, but nothing helped:

Users defined for both LDAP and RADIUS fail to authenticate via RADIUS and their connection is dropp…

One Time Password (OTP) authentication fails with session timeout for Radius (checkpoint.com)

sk112933 is no more available…

very appreciated for any ideas!

2

From that snippet of authproxy.log you posted, the user completes Duo 2FA and the Duo proxy server sends back the RADIUS accept to the Checkpoint device, and then the Checkpoint device sends the same access-request again to the Duo proxy (the log shows the device at 10.10.10.1 sending RADIUS access request ID 170 twice more after Duo returns access to the first instance of request ID 170).

You should concentrate your troubleshooting efforts on the Checkpoint device, to figure out why receiving the RADIUS accept the first time isn’t good enough. Is it hitting a timeout set on the Checkpoint before the accept comes in and therefore retrying, etc.?

3

Hey :smiley:

You are corrent the SK was taken down (unplanned )

Action Plan:

  1. Go to GuiDBEdit > global properties > firewall_properties > set the ike_negotiation_timeout to 600
  2. Go to the SmartConsole > Global Properties > Advanced > Configure (then choose “Accept”) > FireWall-1 > Authentication > RADIUS > radius_retrant_timeout from 5 to 30 (in seconds)
  3. SmartConsole > Global Properties > Advanced > Configure > FireWall 1 > Authentication > RADIUS > radius_user_timeout is set to 600
  4. Install the policy.
  5. In the trac.defaults file on the client make the changes to the following parameters, according to the requirements of the user.
  6. Important:
  7. Set the time in milliseconds
  8. Keep the same value for all three parameters
  9. ccc_timeout INT 300000 GW_USER
  10. ike_connect_timeout INT 300000 GW_USER 0
  11. ccc_idle_timeout INT 300000 GW_USER 0
  12. Save the file, reboot the PC, and see if the issue was resolved.
  13. To implement it to all the users, either:
    1. Create a new customized MSI package with the customize trac.defaults as explained in sk122574.
    1. Modify the $FWDIR/conf/trac_client_1.ttm as explained in sk75221:
  • Backup the $FWDIR/conf/trac_client_1.ttm.
  • Add to the file:
  • :ike_connect_timeout (
  • :gateway (
  • :default (300000)
  • )
  • )
  • :ccc_idle_timeout (
  • :gateway (
  • :default (300000)
  • )
  • )
  • :ccc_timeout (
  • :gateway (
  • :default (300000)
  • )
    • )
    • Install the policy.
    • Note: The End User will receive the new trac.config only after 2 successful connections to the site.
    • Important : Changes made to the trac_client_1.ttm file may not be persistent during the Security Gateway upgrades. Before upgrading, backup your trac_client_1.ttm file .
4

Hello all,

the problem was on the CheckPoint: CheckPoint was sending request from incorrect interface. After fixing this issue (with setting a static route) everything works as expected

Thank you!