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]

no, we don't see any drops. Will do debug right now

[Exonix]

Hello All,

I've contacted Support, but it still takes time. I changed NAS-IP using How to configure RADIUS authentication between Gaia OS and Microsoft Windows Server 2008 (checkpoint... 

fw-outside> show aaa radius-servers NAS-IP
NAS-IP: 10.10.10.1

But TCPDUMP still shows mngt IP...

there is also one unclear point for me: What does VLAN do in the TCPDUMP, why is it Duplicate Request?

[Chris_Atkinson]

This guide is for configuring Radius to authenticated admins logging into the appliance CLI it doesn't necessarily apply to remote access auth...

[Exonix]

how to change it for Remote Authentication then? as you can see the incrorrect IP is presented in the package

[PhoneBoy]

There isn't a way that I am aware of to directly configure the IP used in the RADIUS packet.
In which Check Point object(s) does the IP you are seeing in the RADIUS packet appear and in what precise locations?
It is highly recommended you work this issue with the TAC: https://help.checkpoint.com 

[Exonix]

Hello PhoneBoy,

Our Support works with TAC via thier Channel. Yesterday we had a call, I showed everythig and collected full debug logs. They are working on them.

The visible IP address belongs Gateway Object in the CheckPoint:

[PhoneBoy]

So it's configured as the Main IP, correct? (in the General tab of the object)
That makes sense and also gives you a way to potentially change it (though this may have other side effects). 

[Exonix]

I can't change it because it is management IP. But maybe I could change it so that the requests came not from the IP interface, but from the IP FW? then it will match to each other.

[Exonix]

Question: how can I configure Policy Based Routing to send traffic via correct interface? I've configured like this, but it dind't help. Probably I need to configure source, but what?

 

[PhoneBoy]

As far as I know, Policy Based Routing does not apply to traffic originating from the gateway itself.
For that, you can use the regular routing table.

Regardless, the issue doesn't appear to relate to the interface the traffic is routed out, but the IP inside the RADIUS packet.
That's not something you can "fix" through a routing change.

Is there some reason you can't just adjust the configuration on the RADIUS side to accept the relevant IP?
It seems like that would resolve the issue much quicker than working through the TAC. 

[Exonix]

RADIUS accepts both adresses and answers Access-Accept, but GW sends second request in 30 secs.
I have an assumption that CP is waiting for a response not to the interface address (10.10.10.1), but to the NAS-IP address, which is the IP of the object. In our test lab we have only one interfaces on the CP, but in the production - many... Very soon I will be testing NPS, which will be directly connected to the "NAS-IP" interface, so source IP and NAS-IP will be same.

[Expert@fw-outside:0]# tcpdump -nni any port 1812
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

15:06:02.466341 IP 10.10.10.1.48453 > 10.10.10.20.1812: RADIUS, Access-Request (1), id: 0x15 length: 128
15:06:02.466350 ethertype IPv4, IP 10.10.10.1.48453 > 10.10.10.20.1812: RADIUS, Access-Request (1), id: 0x15 length: 128
15:06:02.585598 ethertype IPv4, IP 10.10.10.20.1812 > 10.10.10.1.48453: RADIUS, Access-Accept (2), id: 0x15 length: 276
15:06:02.585598 IP 10.10.10.20.1812 > 10.10.10.1.48453: RADIUS, Access-Accept (2), id: 0x15 length: 276

15:06:32.467353 IP 10.10.10.1.48453 > 10.10.10.20.1812: RADIUS, Access-Request (1), id: 0x15 length: 128
15:06:32.467361 ethertype IPv4, IP 10.10.10.1.48453 > 10.10.10.20.1812: RADIUS, Access-Request (1), id: 0x15 length: 128
15:06:32.471554 ethertype IPv4, IP 10.10.10.20.1812 > 10.10.10.1.48453: RADIUS, Access-Accept (2), id: 0x15 length: 276
15:06:32.471554 IP 10.10.10.20.1812 > 10.10.10.1.48453: RADIUS, Access-Accept (2), id: 0x15 length: 276

[Exonix · Accepted solution]

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