Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
sanderl
New Contributor III

Unreliable traffic between segments

I start a new topic while this problem is still not resolved and since the other topic about this same issue is not accurate anymore. This topic starts with a clear description of the issue including an overview of the situation.

 

This is the old topic (for reference please do not refer anymore to it to avoid confusion).

 

The network schematic:

fortiproblem2.jpg

 

the issue:

If connected wireless to ssid "test99" all is fine. No issues and superfast.

 

If connected to "ssid" clients experience weird issues.

2 examples:

1. Roblox games do not (never) load, and give an error message.

2. Downloading apps/update from google play store is terribly slow ... 1%,2%,3%...

 

I deliberately do not (yet include) and config/capture (see also previous topic).

 

extra information:

I never had any of these issue, for over ~7 years. It started after upgrading to 7.0.11. And if you read the old topic, 2 things constantly cross: software switch vs hardware switch, that issue is now gone. All is connected to 1 hardware switch and VLANs with bridged ssids.

The netgear is configured to tag VLANs on the uplink and to the FAP. furthermore there are no (known) issues in the network other than this...

 

Please help out in finding if this could be a configuration issue or bug. Thank you!

36 REPLIES 36
sanderl
New Contributor III

Done, the problem then moves from vlan 10 to 99 and vice versa...

 

EDIT: Sorry, badly worded. The problem stays on vlan 10. But moves from test99 ssid to vlan 10 when I change bridge vlan id and vice versa.

gfleming

OK so when the client is connected to "ssid" when "ssid" is bridged to VLAN 99 it breaks roblox? And roblox works on "test99" when bridged to VLAN 10?

 

In this case we need to focus on the wifi IMO.

 

What model FortiAP is it and what version is it running?

Cheers,
Graham
sanderl
New Contributor III

No, when a client is connected to vlan 10 it breaks. Test99 and vlan 99 always works. And I have 7 FortiAps, several models and all have the same issue. No wifi problem thus, but in fortios. The problem started in 7.0.11 in the fortigate.

When ssid or test99 is bridged to vlan 99 it works. When ssid or test99 is bridged to vlan 10 it stops.

 

And also, wired devices, like my windows pc have the same behavior (on vlan 10 now. As well as when it was not a vlan 10 yet (old post) wired devices were bridge to a hardware switch (lan) untagged, had the same problem).

 

It seems something is wrong in the vlan 10 "network" (hardwareswitch) that causes this problems since 7.0.11. (Before that was an untagged hardwareswitch lan)

 

Test99 and vlan 99 is pretty empty.

 

Again, never had any issues like these. It started in 7.0.11 and when downgraded to 7.0.10 it was gone (old post).

 

Why not stay on 7.0.10? I use ssl and fortigate has a vulnerability ;).

gfleming

OK it's getting conusing again hahaha. But I see your edits and understand now that the problem is centered around VLAN 10 for wired and wireless clients. You specify "hardwareswitch" along with VLAN 10. But VLAN 99 exists on this same hardwareswitch. So that IMO is not something to highligh here. 

 

Can you do me a favour? Can you change the IP address of VLAN 10 interface to something pretty random like 172.27.243.1/24 and then manually change one of your endpoint IPs to exist in the same subnet with 172.27.243.1 as the default gateway?

 

I'm really curious to see if you have the same issues if you use a different IP subnet.

 

 

Cheers,
Graham
sanderl
New Contributor III

Since I am clearly experiencing problems since 7.0.11.

 

What is this "solved" (how is it solved) in bug ID 856202:

https://docs.fortinet.com/document/fortigate/7.0.11/fortios-release-notes/289806/resolved-issues

 

Furthermore I see a lot of NP7, NP6xLite and NPU "resolved" issues. Might these still be partially there or perhaps have been implemented and provoke my experienced behavior?

gfleming

I don't think that applies to you: you aren't running a cluster, you aren't getting kernel panics or reboots, and in the other thread we eliminated the NPU as a culprit because we disabled hardware offloading and you still had issues.

Cheers,
Graham
sanderl
New Contributor III

True, but at least it notable that these were all "new" in 7.0.11

Top Kudoed Authors