This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Create a Post
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Are you a member of CheckMates?

×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
Exonix
Advisor
‎2023-04-24 06:43 AM
Jump to solution

CheckPoint denies connection even after Push Approval

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 everythig 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.png

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._DuoHTTPClientFactory#info] Starting factory <_DuoHTTPClientFactory: 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._DuoHTTPClientFactory#info] Starting factory <_DuoHTTPClientFactory: b'https://*****.duosecurity.com:443/rest/v1/auth'>
2023-04-24T15:20:59.399225+0200 [duoauthproxy.lib.http._DuoHTTPClientFactory#info] Stopping factory <_DuoHTTPClientFactory: 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._DuoHTTPClientFactory#info] Stopping factory <_DuoHTTPClientFactory: 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 Radius answeres:

 

 

 

14:50:29.972117 IP DUO_10.10.10.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.10.10.22.datametrics: RADIUS, Access-Request (1), id: 0xa4 length: 128
14:50:30.485961 IP DUO_10.10.10.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.10.10.22.datametrics: RADIUS, Access-Request (1), id: 0xa4 length: 128
14:50:35.485912 IP DUO_10.10.10.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 avaliable...

 

very appreciated for any ideas!

0 Kudos
1 Solution

Accepted Solutions
Exonix
Advisor
‎2023-05-16 10:23 AM
Jump to solution

after adding a static route via an interface similar to mngt IP it started working: src IP must match to NAS-IP:

raduis4.png

View solution in original post

0 Kudos
41 Replies
Exonix
Advisor
‎2023-04-24 08:17 AM
Jump to solution

additional Info: CP FW has several Interfaces.

10.10.10.1 interface there the Duo Server is connected to.

172.16.16.1 interface we use for FW management...

I've collected a tcpdump and found follwing:

rad2.png

why in AVP we see mangt-IP? this IP isn't configured in DUO and it will never answer to this IP

0 Kudos
the_rock
Legend
Legend
‎2023-04-24 09:51 AM
In response to Exonix
Jump to solution

Can you try zdebug ONLY for port 1812 and see if anything comes up?

fw ctl zdebug + drop | grep "1812"

Andy

0 Kudos
Exonix
Advisor
‎2023-04-25 01:13 AM
In response to the_rock
Jump to solution

neither fw ctl zdebug + drop | grep "1812" nor fw ctl zdebug + drop | grep "1645" dropps anything

0 Kudos
_Val_
Admin
Admin
‎2023-04-25 01:18 AM
In response to Exonix
Jump to solution

Try doing the same with grepping by the Radius server IP address. Also, check that the communication is actually getting back to the FW from your server. To do so, run fw monitor -e "host(Radius IP);"

Exonix
Advisor
‎2023-04-25 01:38 AM
In response to _Val_
Jump to solution

I don't see anything!

[Expert@fw-outside:0]# fw monitor -e "host(10.10.10.22);"
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs
************************************************************** NOTE **************************************************************
*** Using "-e" filter will not monitor accelerated traffic. To monitor and filter accelerated traffic please use the "-F" filter ***
************************************************************************************************************************************
FW monitor will record only ip & transport layers in a packet
For capturing the whole packet please do -w
PPAK 0: Get before set operation succeeded of fwmonitor_ppak_all_position
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
PPAK 0: Get before set operation succeeded of fwmonitormaxpacket
PPAK 0: Get before set operation succeeded of fwmonitormask
PPAK 0: Get before set operation succeeded of fwmonitorallocbufs
PPAK 0: Get before set operation succeeded of printuuid
^C monitor: caught sig 2
 monitor: unloading
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs

 

0 Kudos
_Val_
Admin
Admin
‎2023-04-25 02:45 AM
In response to Exonix
Jump to solution

Mmmm, this is a bit odd, considering you do observe it on TCP dump. 

run the following:
fw monitor -F "10.10.10.22,0,10.10.10.1,0,0"

 

0 Kudos
_Val_
Admin
Admin
‎2023-04-25 02:46 AM
In response to _Val_
Jump to solution

BTW, all traces and debugging should be done in parallel with the authentication request. Just a reminder.

0 Kudos
Exonix
Advisor
‎2023-04-25 02:48 AM
In response to _Val_
Jump to solution

yes, sure 👍

0 Kudos
Exonix
Advisor
‎2023-04-25 04:10 AM
In response to _Val_
Jump to solution

there is traffic one way only :

[Expert@fw-outside:0]# fw monitor -F "10.10.10.22,0,10.10.10.1,0,0"
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_off
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of fwmonitorfreebufs
PPAK 0: Get before set operation succeeded of kiss_debug_force_kdprintf_enable
PPAK 0: Get before set operation succeeded of simple_debug_filter_saddr_1
PPAK 0: Get before set operation succeeded of simple_debug_filter_sport_1
PPAK 0: Get before set operation succeeded of simple_debug_filter_daddr_1
PPAK 0: Get before set operation succeeded of simple_debug_filter_dport_1
PPAK 0: Get before set operation succeeded of simple_debug_filter_proto_1
 FW monitor will record only ip & transport layers in a packet
 For capturing the whole packet please do -w
PPAK 0: Get before set operation succeeded of fwmonitor_ppak_all_position
 monitor: getting filter (from command line)
 monitor: compiling
monitorfilter:
Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
PPAK 0: Get before set operation succeeded of fwmonitormaxpacket
PPAK 0: Get before set operation succeeded of fwmonitormask
PPAK 0: Get before set operation succeeded of fwmonitorallocbufs
PPAK 0: Get before set operation succeeded of printuuid
PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=54910
ICMP: type=8 code=0 echo request id=43263 seq=1
[vs_0][fw_1] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=54910
ICMP: type=8 code=0 echo request id=43263 seq=1
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=55124
ICMP: type=8 code=0 echo request id=43263 seq=2
[vs_0][fw_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=55124
ICMP: type=8 code=0 echo request id=43263 seq=2
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=55166
ICMP: type=8 code=0 echo request id=43263 seq=3
[vs_0][fw_1] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (ICMP) len=84 id=55166
ICMP: type=8 code=0 echo request id=43263 seq=3
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19104
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19104
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19104
UDP: 1645 -> 47075
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19553
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19553
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=19553
UDP: 1645 -> 47075
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=26876
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=26876
UDP: 1645 -> 47075
[vs_0][fw_1] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=26876
UDP: 1645 -> 47075

 

0 Kudos
_Val_
Admin
Admin
‎2023-04-25 04:16 AM
In response to Exonix
Jump to solution

That is because of the filter. Try expanding the filter:

fw monitor -F "10.10.10.22,0,10.10.10.1,0,0" -F "10.10.10.1,0,10.10.10.22,0,0"

This should show you both ways now

0 Kudos
Exonix
Advisor
‎2023-04-25 04:20 AM
In response to _Val_
Jump to solution 

[vs_0][fw_0] eth0.3348:oq[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=14024
UDP: 47075 -> 1645
[vs_0][fw_0] eth0.3348:OQ[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=14024
UDP: 47075 -> 1645
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=50923
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=50923
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=50923
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:oq[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=41140
UDP: 47075 -> 1645
[vs_0][fw_0] eth0.3348:OQ[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=41140
UDP: 47075 -> 1645
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=54678
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=54678
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=54678
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:oq[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=5311
UDP: 47075 -> 1645
[vs_0][fw_0] eth0.3348:OQ[44]: 10.10.10.1 -> 10.10.10.22 (UDP) len=156 id=5311
UDP: 47075 -> 1645
[vs_0][ppak_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=55022
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:iq[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=55022
UDP: 1645 -> 47075
[vs_0][fw_0] eth0.3348:IQ[44]: 10.10.10.22 -> 10.10.10.1 (UDP) len=255 id=55022
UDP: 1645 -> 47075
0 Kudos
_Val_
Admin
Admin
‎2023-04-25 04:39 AM
In response to Exonix
Jump to solution

Great. we see that FW box communicates with radius. it means the issue is not about connectivity. check the basic radius config to see there is no issue with the registration and handshake on both sides

 

0 Kudos
Exonix
Advisor
‎2023-04-25 04:50 AM
In response to _Val_
Jump to solution

on the MS RADIUS I see - "Access Granted", Event ID 6272. On the Server I've configured only Radius Clients and Rules. I was doing this many times already, but faced such issue first time

0 Kudos
the_rock
Legend
Legend
‎2023-04-25 05:38 AM
In response to Exonix
Jump to solution

@Exonix 

Not sure if anyone mentioned this yet, but reading all the answers, it triggered my memory about similar issues I had with customer of ours and after some time with TAC on the phone, we realized below was the problem and as soon as it was changed, everything started working. Yes, PAP is way less secure, but we could never get it working with ms-chap2 auth method.

Andy

 

Screenshot_1.png

 

PhoneBoy
Admin
Admin
‎2023-04-24 04:19 PM
In response to Exonix
Jump to solution

The IP of the interface which is needed to communicate with the RADIUS server will be used to originate the connections.
That won’t necessarily be your management IP.

Having said that, I am curious: what precise IP are you using in SmartConsole for the relevant gateway?
Does it match the NAS IP in your tcpdump?

0 Kudos
Exonix
Advisor
‎2023-04-24 11:24 PM
In response to PhoneBoy
Jump to solution

Management IP: 172.16.16.1
Interface IP (Gateway for DUO Server): 10.10.10.1

It matches in the fields SRC/DST, but doesn't in RADIUS Data

0 Kudos
Exonix
Advisor
‎2023-04-25 01:14 AM
In response to PhoneBoy
Jump to solution

I found this article: set global-radius-conf (checkpoint.com)

but how can check what is set right now?

0 Kudos
Chris_Atkinson
Employee Employee
Employee
‎2023-04-25 01:17 AM
In response to Exonix
Jump to solution

First to confirm relevance of that document, what model is your gateway?

CCSM R77/R80/ELITE
0 Kudos
Exonix
Advisor
‎2023-04-25 01:36 AM
In response to Chris_Atkinson
Jump to solution

not Quantum Spark... Just a VM on VMWare

0 Kudos
PhoneBoy
Admin
Admin
‎2023-04-25 06:04 AM
In response to Exonix
Jump to solution

I’m pretty sure that command is unique to Quantum Spark appliances.
I strongly recommend a TAC case here: https://help.checkpoint.com

Exonix
Advisor
‎2023-04-26 09:52 AM
In response to PhoneBoy
Jump to solution

I've run this command - CheckPoint didn't say it was wrong, but there was no effect

0 Kudos
PhoneBoy
Admin
Admin
‎2023-04-26 11:27 AM
In response to Exonix
Jump to solution

Most of the officially supported configuration commands via CLI need to occur via clish, not the expert mode shell.
This is not a valid command in clish on a regular gateway, I can assure you:

image.png

I'm not 100% sure what "set" is doing in expert mode.

0 Kudos
the_rock
Legend
Legend
‎2023-04-26 11:44 AM
In response to PhoneBoy
Jump to solution

Interesting, but it appears it does work? lol

Example in my lab (no errors...)

[Expert@quantum-firewall:0]# set global
[Expert@quantum-firewall:0]# set global-radius-conf
[Expert@quantum-firewall:0]# set interface
[Expert@quantum-firewall:0]# set mode
[Expert@quantum-firewall:0]#

0 Kudos
Chris_Atkinson
Employee Employee
Employee
‎2023-04-24 06:09 PM
Jump to solution

Which endpoint vpn client version are you using out of interest and what Jumbo for R80.40?

Does the following link work for you?

sk112933: Endpoint Security VPN client timeout reached during the time that a third-party server is ...

CCSM R77/R80/ELITE
0 Kudos
Exonix
Advisor
‎2023-04-25 01:08 AM
In response to Chris_Atkinson
Jump to solution

on the MNGT Server Jumbo ist 180, and there is no Jumbo on Security Gateway

We changed timeouts, now we receive two Duo Pushes, but still no connection

0 Kudos
Chris_Atkinson
Employee Employee
Employee
‎2023-04-25 01:12 AM
In response to Exonix
Jump to solution

Running without a jumbo isn't best practice given the age of R80.40 and how about the clients?

Did you already allow/configure the NAS IP that you see in DUO?

Which interface is the DUO server routed via?

CCSM R77/R80/ELITE
0 Kudos
Exonix
Advisor
‎2023-04-25 02:01 AM
In response to Chris_Atkinson
Jump to solution

VPN Client 86.50

What do you mean "NAS IP that you see in DUO?"

Now we found something else: even if we set MS NPS as the RAIDUS (avoiding DUO) - it also doesn't work, even MS NPS allowed access...

0 Kudos
Chris_Atkinson
Employee Employee
Employee
‎2023-04-25 02:25 AM
In response to Exonix
Jump to solution

The NAS IP in the AVP shown in the captures versus (or in addition to) whichever you have configured it to currently accept messages from. Though I think at this point you have two options:

1. Engage TAC for a debug plan to investigate further.

2. Apply a Jumbo to the Gateway to eliminate known issues such as:

Radius Timeout.PNG

CCSM R77/R80/ELITE
_Val_
Admin
Admin
‎2023-04-25 12:23 AM
Jump to solution

Did you disable some of the implied rules, by any chance?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

View All ≫
Upcoming Events

    CheckMates Events