CheckPoint denies connection even after Push Approval

[Exonix]

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

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!

[Exonix]

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:

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

[the_rock]

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

fw ctl zdebug + drop | grep "1812"

Andy

[Exonix]

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

[_Val_]

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]

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

[_Val_]

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"

[_Val_]

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

[Exonix]

yes, sure 👍

[Exonix]

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

[_Val_]

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

[Exonix]

[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

[_Val_]

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

[Exonix]

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

[the_rock]

@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

 

[PhoneBoy]

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?

[Exonix]

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

[Exonix]

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

but how can check what is set right now?

[Chris_Atkinson]

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

[Exonix]

not Quantum Spark... Just a VM on VMWare

[PhoneBoy]

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

[Exonix]

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

[PhoneBoy]

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:

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

[the_rock]

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]#

[Chris_Atkinson]

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

[Exonix]

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

[Chris_Atkinson]

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?

[Exonix]

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

[Chris_Atkinson]

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:

[_Val_]

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