Default VPN-SSL realm in multirealms scenario

[REDES_UCHILE]

Hello everyone:

We are new Fortinet costumer and need help with the default domain configuration in a multirealm SSL VPN scenario.

For example, we have the following realms configured:

- https://vpn.domain.com (default realm)
- https://vpn.domain.com/realm1 (realm 1)
- https://vpn.domain.com/realm2 (realm 2)

Our idea is that users can connect only to these 3 realms.

But when testing, we noticed that if a user mistypes one of the realms (by example: https://vpn.domain.com/realm200), the user is redirected to the default realm.

This is not desired. We expect that if this happens, the connection will be discarded by the firewall because there is no realm to match.

Is that possible?.

Thanks in advance

[ebilcari]

What's the FGT firmware version in this setup? I tested in 7.2.10 and the realms that don't exist will not open:

There are some changes on the latest firmware and the behavior may have changed in 1066448.

[REDES_UCHILE]

We have an FGT-3300E with 7.0.14

[Toshi_Esumi]

@ebilcariI just confirmed the behavior of non-existing realm @REDES_UCHILE described with my FG40F v7.2.10. I think the key is in below GUI authentication-rule view:

At the bottom, it's showing "All Other Users/Group", which is NOT configurable and always there with "Realm: / ". So if no matching realm is configured, it seems to be designed to follow the default/implicit rule to use the "no realm" group to match the username and if the user name exists in the group (my case SSLVPNusers), it actually connects successfully.
I tried "realm3" with an existing user and got connected with FortiClient VPN tunnel mode.

Some snippets of sslvpn application debug output for realm1 and realm3 is blow:
[realm1] 2024-10-08 15:15:42 [250:root:1f9f]req: /remote/login?realm=realm1
[realm3] 2024-10-08 15:19:56 [250:root:1fa4]req: /remote/login?realm=realm3
...
[realm1] 2024-10-08 15:15:42 [250:root:1f9f]fsv_logincheck_common_handler:1350 user 'realm1-toshi' has a matched local entry.
[realm3] 2024-10-08 15:19:56 [250:root:1fa4]fsv_logincheck_common_handler:1350 user 'toshi-local' has a matched local entry.
...
[realm1] 2024-10-08 15:15:42 [250:root:1f9f]sslvpn_validate_user_group_list:1940 validating with SSL VPN authentication rules (3), realm (realm1).
[realm3] 2024-10-08 15:19:56 [250:root:1fa4]sslvpn_validate_user_group_list:1940 validating with SSL VPN authentication rules (3), realm ().
...

[realm1] 2024-10-08 15:15:42 [250:root:1f9f]deconstruct_session_id:492 decode session id ok, user=[realm1-toshi], group=[realm1-group],authserver=[],portal=[full-access],host[x.x.x.x],realm=[realm1],csrf_token=[3AA4D3F1612A335115D05CEE4A88462A],idx=0,auth=1,sid=619cdc9d,login=1728425742,access=1728425742,saml_logout_url=no,pip=no,grp_info=[eRrZr5],rmt_grp_info=[]
[realm3] 2024-10-08 15:19:56 [250:root:1fa4]deconstruct_session_id:492 decode session id ok, user=[toshi-local], group=[SSLVPNusers],authserver=[],portal=[full-access],host[x.x.x.x],realm=[],csrf_token=[56F4F4BBD71543EEBB6ACD5CBB38201B],idx=0,auth=1,sid=60c30aab,login=1728425996,access=1728425996,saml_logout_url=no,pip=no,grp_info=[dg5xo5],rmt_grp_info=[]

I guess I need to submit a NFR to our MSP SE to make the default behavior selectable when the given realm doesn't exist, either go to "non realm" group or just drop with an error message.


Toshi

[REDES_UCHILE]

Toshi:

Huge thanks for your feedback!. It's good to know that this has nothing to do with the version we use.

Hopefully you have good news from your MSP and they can offer you an alternative for this behaviour.

Best regards

[Toshi_Esumi]

I don't think they would have any alternative unless they agree to develop a new option to change the default behaviour or the design, which wouldn't be available until 7.6.5 or later like 7.8.x even if they agreed.

Toshi 

[Toshi_Esumi]

You probably won't call this as alternative. But I now believe this is the FTNT's original intention of the "SSL VPN realm" design  -- "Don't define/configure the default realm if you want to fail attempts to non-existent realm".
So I won't file a NFR(new feature request) for your case. They would simply reject/ignore even if I did.

After I changed the config above to below, the connection attempt with a realm "/realm4" was dropped after 40%. Then I got "Connection down" windows message. Because no usergroup is bound with the default realm '/'.

sslvpn application debug showed below:
2024-10-10 15:26:32 [251:root:1fa5]no valid user or group candidate found.
2024-10-10 15:26:32 [251:root:1fa5]login_failed:405 user[toshi-rad],auth_type=32768 failed [sslvpn_lo gin_unknown_user]

The user "toshi-rad" exists in SSLVPNusers group. But it's now bound to realm1, instead of the default-realm '/'. Nothing is bound.

Toshi

[REDES_UCHILE]

Hi Toshi: 

Thank you very much again for your feedback.

We will generate a ticket to our supplier to see if they can give us an alternative.

If we don't have good results, we will have to modify the logic of our realms definition.

We will let you know what response we get.

Regards

[rbraha]

Hi @REDES_UCHILE 

I would say its expected to be redirected to default realm because FGT cannot redirect the user to the correct realm ,which if using web mode you can probably save it as bookmark in end user browser or if using free version of FortiClient you can save on Remote Gateway ,URL of firewall including realm so user can only enter credentials to authenticate.

[REDES_UCHILE]

First of all, thank you for replying.

We have VPN web access disabled, so we are using the Forticlient VPN only.

While saving the Remote Gateway URL is an option, it is not ideal for us.

We would like the FGT to notice that the realm does not exist and therefore discard the connection attempt.

Regards