packet loss on SSID in bridge mode over vlans

[chechoSV]

Hello Everyone, i have a problems on 2 VLANS subinterfaces. 

packet loss on SSID in bridge mode 

I perceive problems when connecting to 2 SSIDs, with a machine with Windows 10 or 11 the AP authenticates the device and immediately when pinging the VLAN gateway it manages to respond without problems, but when I go out to other networks outside the VLAN, for example I perceive packet loss for example when pinging Google.

After a few minutes I start to get out of the internet and to other networks without any problem.

The funny thing is that this happens only in Windows, I have tried Android, IOS and Ubuntu.
When connecting to the AP with these OS I have no problems.

The problen running on Fortigate version 7.2.5

1. First, Windows Device is connected and the ping its OK to vlan gateway.

 

2. then I ping google, but it doesn't respond

 

3. after about 2 minutes google responds

 

this happens in 2 vlans, but in the others I don't have this problem

[knagaraju]

Hello chechoSV,

Please take the flow debugs in fortigate cli during the time of the issue to isolate what is causing the issue.

diagnose debug reset
diagnose debug flow filter addr 8.8.8.8
diagnose debug flow filter proto 1
diagnose debug flow trace start 1000
diagnose debug enable


To disable the debugs please run
diagnose debug disable
diagnose debug reset

[ebilcari]

If the ping from the host to the GW is always stable, than from a troubleshooting perspective the FAP and FSW is working properly.

From this behavior (2 min delay) it looks like the problem is on policy matching in FGT. Are you using FSSO groups in the firewall policies for these windows devices?

[chechoSV]

Hello, good morning, if there are FSSO groups with policies for each group of users, however, checking the policies view, all users are matching with a policy that is above ALL TO ALL

My question is, does it affect that this policy is above all those that use FFSO and nobody is coinciding with those of FSSO

[ebilcari]

More specific rules should be above, so for example if you have a rule with a FSSO group that should be above another rule that has subnets/addresses only. If FGT doesn't find the group for that user it will fall back to the other policy.

If FGT have a delay of listing the FSSO users, you may start to troubleshoot that part. At this point you have to isolate the problem, and find out if internet access is allowed only after FGT learns the user. The FSSO users can be checked from GUI:

or from CLI:

GW # diag debug authd fsso list
----FSSO logons----
IP: 10.1.1.1 User: FORTINET Groups: CN=FORTINET,OU=USR,DC=EB,DC=EU

[chechoSV]

Hello, good morning, I want to show you the first screenshot, I was noticing that above the FSSO policies, there was a policy called ".Accesos-Temporales" and all the devices were passing through that policy.

0 bytes in FSSO Policies

 

In the second screenshot, I modified that policy and now everyone is in their respective FSSO policy.

I want to validate with the client on site, how it is behaving with this change that I make.

 

[ebilcari]

Most probably that rule was set to stay there temporarily until the FSSO was implemented. As a safe step you can move it at the bottom after the FSSO rules to monitor which users/IP will hit that rule. In this way you can t-shoot without affecting user's work.

[Bjay_Prakash_Ghising]

Hi chechoSV

Please check the following:

1. Channel Consumption
Verify which radio channel the device is connected to (Form WiFi Client Tab) and its utilization (From Managed AP Tab). Because even if users have good signal strength but are connected to the most used channel then it will have heavy packet loss. It usually happens for 2.4 GHZ RF users.

As the channel carries the data throughput for the wireless users and If you encounter high channel usage either from high user count or high traffic from other users. It will eventually have high latency and packet loss for the end user.

To resolve the issue, try to give the least used channel, mostly 5 GHZ channels. It will provide high data throughput and better performance for the user.

2. Verify the links
Check each and every connected node and link that the wireless traffic traverses. If your ISP link is having packet loss then without a doubt the wireless user will suffer the packet loss.
(You can usually monitor the loss from the SD-WAN tab and link monitor if configured. If not, then define repeat count in execute ping option to monitor and analyze the traffic response.

Hope that helps,

Kind Regards,
Bijay Prakash Ghising