EndPoint VPN Error Following Upgrade

[superd]

Hi all,

Ive upgraded one of our FWs from r80.10 -> r80.40, and now I am recieving the below error for endpoint VPN connections. 

"You are not authorized to recieve and office mode IP address"

The only untoward message I can find in vpn.elg debug is below - but possibly a red herring, not certain. 

[vpnd 5997 4126250688]@CPFW-R77.20[10 June 13:40:22] check_uint_attribute_value: failed to get attribute [sr_info_auth_grps_fetched] from userobject
[vpnd 5997 4126250688]@CPFW-R77.20[10 June 13:40:22] check_uint_attribute_value: read attribute [sr_info_auth_grps_fetched] on user object, value is 0

The above error is mentioned in SK115352 >> however, user has NOT got multiple accounts internal and ldap, so I dont believe its a valid fix here.

SmartLog shows the authentication as successfull, but without any further entries.

The other GW is still on r80.10, and working fine with the same policy. Im not sure if that may have some impact here with differing versions.

Also, the clients use a certificate to authenticate. Im wondering has something changed with .10 and .40 in terms of certificates. The certificate is self signed.

Any thoughts much appreciated.

D

[the_rock]

Hm, thats indeed a bit strange. So that message clearly would indicate that it believes that user is not authorized to get the OM IP address, though it does show its authenticated, so to me at least, would tell me that cert auth part is fine. Can you confirm that maybe office mode settings did not change on that firewall?

Andy

[superd]

Hi, no changes to office mode.

Ive updated the thread with the following errors / messages found in vpn.elg:

[vpnd 5997 4126250688]@CPFW-R77.20[10 June 13:40:22] check_uint_attribute_value: failed to get attribute [sr_info_auth_grps_fetched] from userobject
[vpnd 5997 4126250688]@CPFW-R77.20[10 June 13:40:22] check_uint_attribute_value: read attribute [sr_info_auth_grps_fetched] on user object, value is 0

[the_rock]

The only thing I found with those errors is below link, but not so sure it applies : (. Maybe worth TAC case, as that sounds like a pretty serious problem. Never mind, I see its same sk you mentioned as well...Just as a test, to be 100% sure, can you attempt user/pass method to see if that works?

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[PhoneBoy]

That message indicates a license issue.
With cplic print from the relevant gateway, we can confirm if you have the correct license that allows for Office Mode.
If you have the correct license and the upgrade causes it to break, it's probably a bug and a TAC case will be necessary.

[superd]

Thanks - I thought so too. But licensing looks ok. Ive also dropped an eval on it, just to be sure, with no effect. Ive a call open with TAC.

[the_rock]

Im pretty positive its not license issue.

[Egenity]

This week, I ran in to a very similar situation with a client. 

Their environment was R80.10 JHF Take 30 upgrading to R80.10 JHF Take 55.

Upon upgrade, it immediately broke all VPN attempts with a very similar error (unable to obtain Office Mode IP).  In this particular situation, office mode IP addresses are administered by DHCP, which may be why the error differs.

This is a known issue in the later JHF releases, and support provided a specific hotfix to repair it.

Here is sk178767 for the issue:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[the_rock]

Thats odd, because I never had that problem with any customers on those versions. Also, error message does not seem to match with what @superd posted originally.

[Egenity]

Correct.  As my post indicated and explained, similar, not the same error message. 😁

"This week, I ran in to a very similar situation with a client. "

"Upon upgrade, it immediately broke all VPN attempts with a very similar error (unable to obtain Office Mode IP).  In this particular situation, office mode IP addresses are administered by DHCP, which may be why the error differs."

[the_rock]

Thats true : - ). Personally, I doubt its related, but if @superd is willing to try, he could also confirm with TAC.