First IP on SSL-VPN has no network access

[smxko]

Hi,

we use SSL-VPN with FortiClient via Entra ID SAML. We have 3 Entra groups for accessing SSL-VPN. The IP range for all clients on SSL-VPN is 192.168.15.1 - 192.168.15.254.

Strangely, when a clients gets the assigned the IP 192.168.15.1, FortiClient connects but there's no network access. Bytes sent / received in FortiClient is only a few kbytes. When I view the logs, I see that the Client mostly only does DNS / LDAP requests to our domain controller. But no SMB to our fileserver or whatsoever. When I try to run ICMP to the domain controller, I get a timeout. Wierdly enough, under forward logs I see "PING ACCEPT (240B / 240B) - so from FGT's perspective, it replies to the ICMP request done by 192.168.15.1.

I also ran Wireshark on the client and there it gets eaven crazier. When I monitor the SSL-VPN interface, I only see the ICMP reply from the domain controller to the client but not the ICMP request leaving through the SSL-VPN interface.

This happend on multiple devices but not on all of them, always when the .1 was assigned. That address is not used anywhere else on the network. I also checked FGT's FIB, the address is not in conflict. As a workaround, I set the assigning IP range starting from 192.168.15.2. But what could possibly be the culprit here? It might be a local problem but I already checked IP conflicts via "route print" and "Get-NetIPAddress" but the IP always was unique to the Fortinet SSL VPN Adapter.

[funkylicious]

hi,

is the same range also set in the sslvpn portals ( source ip pools ) / firewall rules / sslvpn settings ( tunnel mode client settings > address range / automatically assign addresses ) ? maybe a typo was made in a object that is used.

as for the routing table, when a computer is assigned that IP can you see it with the command, get router info kernel | grep 192.168.15. as part of any block ? 

[smxko]

Yep, double checked all address objects, on FGT it's all set correctly. On some clients, it is actually working even when the user is in the same SSLVPN Entra Group and gets assigned the .1. That's why I think that this isn't a configuration issue. According to FIB, the IP is bound / routed to the SSLVPN interface.

So based on these observations, I really think this is a local problem on some clients. Are there any tools, maybe even from Fortinet to debug this?

[funkylicious]

are the users part of the same Entra Group as those that in the past were assigned the .1 IP and didnt work ?

also, are you using realms/portals to separate the connection for each group or you just created a single realm, the default / , same portal and different user groups were created which reference the saml server and a different object id / group in it ?

[smxko]

Yes, these users are in the same Entra Group. Maybe this makes it clearer:

• Client A, Entra Group 3, 192.168.15.1 > Doesn't work
• Client B, Entra Group 3, 192.168.15.1 > Works
• Client C, Entra Group 2, 192.168.15.1 > Works
• Client A, Entra Group 1, 192.168.15.1 > Doesn't work
• Client A, Entra Group 2, 192.168.15.1 > Doesn't work

As said before, it somehow boils down to the individual clients itself.

We use a single portal for Entra Auth for all clients and distinguish user access by one of the 3 Entra security groups

[smxko]

I checked all local interfaces for conflicting IPs but there are none. Local Ethernet and WiFi adapters are getting leases from another range.