fail to telnet client authentication after upgrade to R80.30 (from R77.10 > R77.30 > R80.30)

[LeeBingKang]

Hi All,

I would like to seek for your suggestion on my recent issue whereby i unable to do telnet client authentication to my standalone firewall after upgrade to R80.30.

I did try to do the telnet client authentication on the previous (R77.30) and initial version (R77.10), at it works fine. However, its doesn't work after i upgraded to R80.30. I did try to search this feature on CheckPoint resource and found this feature still exist on R80.30 SmartConsole R80.30 Help (checkpoint.com)

Right now, i try to fresh install a new standalone machine (r80.30) with VM environment and test for this function.

Lastly, i appreciate if someone able provide me some guide on further investigation or solve this issue.

Thanks.

[the_rock]

Are there any relevant logs as to why it fails?

[LeeBingKang]

Hi @the_rock , there is no relevant log shown in it as the log will be generated when authentication success.

[LeeBingKang]

I did try to create a rule with "client Auth" action on the fresh install R80.30 standalone VM, and tested the telnet authentication on it. It Works.

[the_rock]

Good, but just wondering, wasnt that rule there after the upgrade!!??

[LeeBingKang]

The rule already at there, i did try create a new rule on top of the exisitng but still no respond from firewall when doing the telnet client authentication.

[PhoneBoy]

Client Authentication has been deprecated in R8x and you should move to Identity Awareness with Captive Portal (web based).
As for troubleshooting, you might try a packet capture to see what happens at that level.
Maybe also an fw ctl zdebug +drop to see if that shows anything.

[LeeBingKang]

Hi @PhoneBoy 

Thanks for your information and noted on it. Meanwhile, i currently opened a case with TAC and look forward into it. I will update at here if have any.

[LeeBingKang · Accepted solution]

Hi Guys, i just get conclusion with CheckPoint support last week regarding this issue and there are 2 items need to be awared:

1. Make sure the port 259 content of the fwauthd.conf (at $FWDIR/conf) is like"259 fwssd in.aclientd wait 259" and not like "#259 fwssd in.aclientd wait 259". If you aware is with "#" use vi editor to remove it and do cpstop and cpstart.

2. Make sure you have rule to allow internal host to firewall with port 259 before the stealth rule. This rule needed due to the rule matching architecture between R77 and R80.

For the "#" on the fwauthd.conf, it might be happened after you installed the IPS policy or maybe installed with jumbo hotfix (i just guess on it).

Lastly, that's all my sharing for this issue and hope that can help others which might faced same issue as me.

[David_C1]

I ran it to the same issue after applying JHFA Take 102 for R80.40, and the fix was to uncomment the line you reference above. Nice, undocumented change.

I agree IA is the way to go, but there are certain circumstances where this is not practical for our environment. Until these issues are addressed, we are stuck with client authentication.

Dave

[PhoneBoy]

I'm curious what these circumstances are, particularly since you can authenticate with a web browser in Identity Awareness.

[David_C1]

Here's one example, from a thread back in 2020 on this very issue:

"User A logs into his Windows desktop and has an Access Role assigned to him via AD group membership. Identity Collector is the method used for this Access Role. This Access Role gives him access to Systems A, B, and C.
User A is also an authorized user of System D, but this is a more critical/sensitive system. Before he can access this system, he needs a new Access Role assigned. This Access Role is granted via Captive Portal using RADIUS (MFA) as the authentication mechanism. We want this so that his access to System D is open only when needed, and we want the use of MFA for heightened security. His Active Directory account and RADIUS account are two different accounts. In R80.40, once he authenticates through Captive Portal, his access to Systems A, B, and C are cut off. This is not practical the user's work activity."

Hope that makes sense. Basically we want to use Identity Collector for "typical" access, and Captive Portal (and MFA with RADIUS) for "step up" access to more critical systems. However, the authentication to Captive Portal wipes out the Access Roles granted via Identity Collector, and this would cause too many issues for our users.

Dave

[PhoneBoy]

It seems like that particular use case could be solved by using Mobile Access.
All modern gateways include a license for five MAB users.
In any case, I don’t see Client Authentication (as it existed in the earliest days of the product) coming back. 

[the_rock]

I recall after reading your update (thank you for that) that even before R55 version, they always used to advise to put client auth rule BEFORE the stealth rule, so traffic does not get blocked inadvertently.