Help with Device Discovery FortiWifi80CM

[dbadams]

Hello wonderful Fortinet owners! 

I have an issue with my Forti80CM that I can't seem to find any solution to and its driving me nuts. Worst off, I bet its something really simple too. Here is the issue: 

I moved away from my home router/wifi/switch, which was a basic netgear you pickup at bestbuy, and got a FortiWifi80cm. The idea was just to have all the devices on one big broadcast domain regardless if they are wired or wireless. So I followed the wizard and bridged my hard switch with my wifi access point into a single softswitch interface. So all my devices are on the same subnet and using the FortiWifi as a DHCP pool, and for the most part everything is working as expected. . . . for the most part. 

The problem is wifi devices cannot discover other wifi devices automatically relative to the application doing the discovery. Examples: My kids' tablets cannot find each other when playing minecraft. My android phone no longer can cast youtube to our roku stick. My Windows PCs can no longer find other PCs. I can explicitly ping all these devices from each other just fine, but anything to do with auto discovery just doesn't work.

I've done several things so far. For starters, I disconnected my FortiWifi and reconnected my netgear. With the cheap netgear, everything worked as it should so I know its not the devices themselves. Next I turned off all WIDS and security profiles on all my policies just to be on the safeside. Next I checked every possible FortiResource I could find to see if VLAN Pooling is being implemented. I can't find any evidence of any.  Then I tried playing around with some CLI commands, such as forwarding broadcast domains, but many of the switch type functions are not available unless you are specifically in transparent mode. 

Guys, I am truly stuck so I thought I'd try here as a last resort. How crappy would it be if I had to abandon my FortiWifi because of this but for my family's sake, it is a deal breaker.  I know I could start sniffing packets and analyzing the layers but I thought I'd see what you all thought first. if anyone was any suggestions whatsoever, it would greatly be appreciated. 

Thanks, 

Devin. 

[Spock]

Devin, Spock here...

Sounds like your Fortinet is passing ICMP traffic for pinging IP devices, but it is not passing SSDP or other ND (Neighborhood Discovery) protocols that are needed by your various devices & the services they are using.

You may have to do some packet captures to see what protocols are attempting to communicate between devices and what, specifically, is causing them to error out during negotiation. (Sounds like a great opportunity to learn more about network discovery protocols and what can interfere with them.)

We Vulcans love this stuff! We have a saying: "All annoying problems are learning opportunities in disguise."

I would enjoy a mind meld on your problem. Please keep me in the loop.

Spock out...

ETX

[dbadams]

Hey Spock,

Thanks for your input! It looks like I"ll be packet sniffing soon! As for the protocols, I know my kids' minecraft game uses IGMP for discovery and multiplayer. Now when it comes to casting Youtube to a streaming device, such as a Roku Stick, it turns out that the protocol being used is called "Discovery and Launch" or DIAL for short. 

After some research (http://help.fortinet.com/fos50hlp/52data/Content/FortiOS/fortigate-firewall-52/Multicast%20Forwardin...), I did discover that multicast cast traffic is being forwarded by default on a FortiGate running in NAT mode. But does this still apply to software switched interfaces? I"m not too sure, so I enabled it anyways through the CLI to be safe:

 config system settings       set multicast-forward enableend

It should also be noted that I could not find this enabled when I searched my running configuration beforehand. 

My Wifi interface is being tunneled back to the FortiWifi before being passed to the other LAN ports, so maybe the TTL is being increased and dropped. To mitigate this,  I enabled the CLI command that allows Multicast traffic to through the FortiGate without decreasing the TTL count. Here is the command to do that: 

 config system settings       set multicast-ttl-notchange enableend

Once both of these settings were configured, I was able to successfully discover and play minecraft with my kids on their tablets!  

Not very scientific of me, I still should be packet sniffing to see what was actually the cause, but I'm just way too lazy (or busy) at this point. 

As for the Youtube casting? Interestingly enough, I can cast from a  computer that is connected via a wired LAN port to a wireless device like my Roku just fine. I just cant cast from a wireless device, such as a phone or tablet, to another wireless device. As of today, I cannot find any documentation from Fortinet about how the FortiGate handles DIAL traffic. That is my next challenge! Once I get an answer, I'll report back! 

Devin Out! 

[Spock]

Devin,

Wow, I had never heard of the DIAL protocol before. I have added that to my protocol library and will be researching more about it as soon as I get the time.

Explicitly forwarding all multicast traffic thru your software switch was a smart first move, and TTL timeouts due to packet processing latencies is one of the most common network application failure modes.

(I see TTL timeouts and TCP connection resets all the time with my packet capture rig when analyzing client telecom problems. Once TTL timeouts are known for sure, it is usually easy to reconfigure both server & client to be more patient with each other before hanging up on the conversation. Usually there are hops along the route that also add varying amounts of latency, but frequently they are owned & controlled by 3rd parties and beyond re-configuration approaches - thankfully not the case in your situation. I just did a state-of-the-art broadband circuit upgrade at a major retailer's flagship store because web-based LOB applications were timing out during critical transactions and tweaking the app/service TTL's just wasn't cutting it enough - sometimes the Last Mile latencies are the ultimate bottleneck that only a switch to fiber & Ethernet DIA can handle.)

WiFi can also introduce horrendous latencies, especially with the increasingly noisy & contentious WiFi radio bands saturation that we're all starting to encounter. (Often when I do a service call for commercial WiFi connection reliability problems, I encounter numerous unrelated broadcast domains all contending for the same WiFi channel - and all with their WiFi radios broadcasting with way too much signal power. It's like a dozen frantic parents all yelling instructions to their children at the same time at a rock concert.)

It would be interesting to measure how much actual packet processing latency your Fortinet WiFi tunneling thru your software switch is creating as a percentage of overall end-to-end WiFi latency. (These are the kinds of real world performance quantification that Vulcans thrive on - "you can't manage what you can't measure".)

Thanks for providing the actual CLI commands that you used to tweak your FortiWiFi configuration. Those are now in my growing Fortinet technical support library, as well. (Still hoping a Fortinet engineer will comment on VDOM vs VLAN processing overhead in our other posting thread.)

Hope to learn more from your intelligent troubleshooting efforts, and I will always share whatever I know - it is The Vulcan Way.

Spock out...