Mobile VPN with SSL: 403 Forbidden error

Hello,
I've recently configured SSLVPN with SAML authentication using this guide:
https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/General/azure-saml_ssl-vpn.html

From time to time, our users get the following 403 error (especially the first time they are authenthenticating, thereafter it happens sporadically)

In the Firewall, I found the following relevant logs:

,C03904C857A4C,db,"FWStatus, dnip_earlydrop_process, DNIP number of office.com has decreased below WATERMARK[250], pri=3, proc_id=fqdnd, msg_id=",15256985,2025-01-07 11:23:21
,C03904C857A4C,db,"FWStatus, FQDND:idomain_ip_refresh_complete::1716: Assertion failed!, pri=3, proc_id=fqdnd, msg_id=",15267913,2025-01-07 11:26:58
,C03904C857A4C,db,"FWStatus, Peer certificate preverify failed (err 10 : certificate has expired) for [/C:US/ST:California/L:Menlo Park/O:Internet.org/CN:*.internet.org] (cert 0x2eb2fc90, store 0x2dc1a8c0), pri=3, proc_id=pxy, msg_id=",15272497,2025-01-07 11:28:33
,C03904C857A4C,db,"FWStatus, Peer certificate preverify failed (err 18 : self-signed certificate) for [/C:US/ST:California/L:Menlo Park/O:Internet.org/CN:*.internet.org] (cert 0x2eb2fc90, store 0x2dc1a8c0), pri=3, proc_id=pxy, msg_id=",15272496,2025-01-07 11:28:33
,C03904C857A4C,db,"FWStatus, FQDND:idomain_ip_refresh_complete::1716: Assertion failed!, pri=3, proc_id=fqdnd, msg_id=",15273869,2025-01-07 11:28:58
,C03904C857A4C,db,"FWStatus, nginx: 2025/01/07 12:29:31 [error] 7211$0: *112997 directory index of ""/usr/share/web/none/"" is forbidden, client: XX.XXX.XXX.XXX, server:  , pri=3, proc_id=wrapper, msg_id=",15275559,2025-01-07 11:29:31
,C03904C857A4C,db,"FWStatus, FQDND:idomain_ip_refresh_complete::1716: Assertion failed!, pri=3, proc_id=fqdnd, msg_id=",15278171,2025-01-07 11:30:20
,C03904C857A4C,db,"FWStatus, ACS: no client associated for the request, pri=3, proc_id=samld, msg_id=",15282057,2025-01-07 11:31:43
,C03904C857A4C,db,"FWStatus, nginx: 2025/01/07 12:31:44 [error] 7211$0: *113003 open() ""/usr/share/web/none/favicon.ico"" failed (2: No such file or directory), client: XX.XXX.XXX.XXX, server:  , pri=3, proc_id=wrapper, msg_id=",15282070,2025-01-07 11:31:44
,C03904C857A4C,db,"FWStatus, nginx: 2025/01/07 12:32:02 [error] 7211$0: *113006 directory index of ""/usr/share/web/none/"" is forbidden, client: XX.XXX.XXX.XXX, server:  , pri=3, proc_id=wrapper, msg_id=",15282654,2025-01-07 11:32:02
,C03904C857A4C,db,"FWStatus, FQDND:idomain_ip_refresh_complete::1716: Assertion failed!, pri=3, proc_id=fqdnd, msg_id=",15284911,2025-01-07 11:32:54
,C03904C857A4C,db,"FWStatus, nginx: 2025/01/07 12:33:12 [error] 7211$0: *113013 open() ""/usr/share/web/none/favicon.ico"" failed (2: No such file or directory), client: XX.XXX.XXX.XXX, server:  , pri=3, proc_id=wrapper, msg_id=",15285738,2025-01-07 11:33:12
,C03904C857A4C,db,"FWStatus, ACS: user john.doe@company.com from sslvpn_client logged in, pri=6, proc_id=samld, msg_id=",15285737,2025-01-07 11:33:12

I'm most interested in the error entries regarding the certificate:

,C03904C857A4C,db,"FWStatus, Peer certificate preverify failed (err 10 : certificate has expired) for [/C:US/ST:California/L:Menlo Park/O:Internet.org/CN:*.internet.org] (cert 0x2eb2fc90, store 0x2dc1a8c0), pri=3, proc_id=pxy, msg_id=",15272497,2025-01-07 11:28:33
,C03904C857A4C,db,"FWStatus, Peer certificate preverify failed (err 18 : self-signed certificate) for [/C:US/ST:California/L:Menlo Park/O:Internet.org/CN:*.internet.org] (cert 0x2eb2fc90, store 0x2dc1a8c0), pri=3, proc_id=pxy, msg_id=",15272496,2025-01-07 11:28:33

I've tried to update the Trusted CA certificates for proxies in the Firebox System Manager, but as far as I can tell there is no certificate which responds to this description.

The other error which happens a lot (also on other times) is this one:
,C03904C857A4C,db,"FWStatus, FQDND:idomain_ip_refresh_complete::1716: Assertion failed!, pri=3, proc_id=fqdnd, msg_id=",15267913,2025-01-07 11:26:58

I also got a similar Fault report - I've sent it to watchguard but not sure what els I could do with this.

So to summarize: how could I resolve this 403 error which happens from time totime?

FYI I'm using Mobile VPN with SSL client 12.11

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @wouterVE
    I'd suggest opening a support case for this issue. You can do so via the support center link at the top right of this page.

    -James Carson
    WatchGuard Customer Support

  • I experienced this issue when the server name used in the Mobile VPN client did not match the host name in the SAML configuration. A prime example would be using the IP address in the Mobile VPN client while the SAML configuration uses a FQDN.

    Please ensure the Mobile VPN client is connecting to the identical value of the Host Name in the SAML configuration and see if it resolves the issue.

  • Hi @james.carson
    Thanks for your suggestion, I've submitted a support case.

    @John_Sells
    I've checked and the clients are using the correct FQDN as configured in the saml configuration (i.e. https://connect.company.com). When they encounter this error and immediately try again with the same paramaters, it does succeeds so there must be something else on the server side imo.

    I did notice something on Entra on the singe sign on config (enterprise applications-> Watchguard vpn -> Single sign-on - 5) Test single sign-on with watchguard)

    When I perform this test on an unsupported browser (e.g. firefox) I got the exact same 403 Forbidden: Invallid session error as in my first screenshot.

    The URL of this page is https://connect.company.com/auth/saml/acs

    So I'm wondering whether this is something client related after all? e.g. that the underlying browser to show this pop-up is not the correct version or something like that?

  • Hey @wouterVE any update on this from support? We just rolled out SAML authentication and are seeing the same issue with some users. Same logs, etc. I just opened a ticket but wondered if you have come to a conclusion since you beat me to it by about 20 days.

  • Hi @netwatch2077
    No, we haven't found a real conclusion. They suggested that the users were using the IP instead of the URL which leads to this error (you can try it yourself).
    Not sure whether this is the real cause as I've witnessed users logging in using the URL and receiving this same error. Anyway, we are now 1 month into deployment and haven't received many reports of this error anymore. I think it happens especially the first time users are authenticating. After this, it seldom re-appears.

    I'd be happy to receive updates from your side if you've found a real cause :)

Sign In to comment.