Difference between "Bridge SSID to FortiGate wired network" and "FortiAP local bridging"

[frederik]

Hi

The documentation (http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/wifi-ethernet_b...) names two different bridge operations:

[ol]

Bridge SSID to FortiGate wired network

FortiAP local bridging (Private Cloud-Managed AP)[/ol]

The setup of the SSID seems identical to me. While in the first variant an interface on the Fortigate is being configured this step is missing in the second variant.

My setup would look like: FortiAP (Subnet C) <--> Switch (L3) <--> Fortigate (Subnet I)

The point is: when the traffic leaves the FortiAP anyhow (in bridged mode) why should I setup a software interface on the Fortigate? Whats is the intention of this? What do I gain?

I have somehow the feeling that I have to choose the first variant if I want to use VLANs (what I do not need in my case).

Thank you very much!

[AndreaSoliva · Accepted solution]

Hi

It is probably not an answer to your question but let's see:

There are two modes to configure a SSID which means bridge or tunneling. If you confgure a SSID for tunneling you can do whatever you want the traffic from the AP listining for the tunneled SSID will be ALWAYS forwarded to the WiFi controller on the FGT and you can use UTM Features etc. because the traffic is ALWAYS going to the WiFi controller on the FGT. If you use on a SSID bridge the interface on the FAP which is listening for the bridged SSID is bridged. This means the traffic is NOT going ALWAYS to the WiFi controller instead the traffic goes directyl from the FAP interface to the segment in which the FAP interface is connected. Of course you can use VLAN's on the bridged SSID. Finally the first question you should answer yourself is following:

- Must the users connected to a SSID for some reason connecting directyl to a server etc. for performance reason etc.

If the answer is yes the FAP should be connected to the same segment as the servers (performance) or to a seperated interface using a specific VLAN connecting directly to the server (not so good regarding performance).  Keep in mind if you use this bridged function YOU CAN NOT USE ANYMORE UTM features on the SSID because the traffic goes not anymore to the WiFi controller.

If the answer is NO you should use from my point of view a seperated interface on the FGT connecting all your FAP's because the traffic is tunneled the traffic comes anyway always to the FGT WiFi controller and you are using UTM features it is better to connect the FAP's to an seperate Interface.

If you are using a FAP im Branche Office and the FAP is connected over the WiFi Headquarter you should use bridge SSID because otherwise the user can not surf to anywhere if the connection from the Branche to the Headquarter is not anymore up. If you do so the user connecting in the Branche to the SSID bridge they can surf arround even the Headquarter connection is down. Keep in mind in this moment the Headquarter connection is down and you are using remote authentication from the Headquarter like WPA2 Enterprise no more NEW users can authenticate as long as the Headquarter connection is down. This users which are already authenticated can surf arround even the Headquarter connection is down.

Hope this helps

have fun

Andrea

[AndreaSoliva · Accepted solution]

Hi

It is probably not an answer to your question but let's see:

There are two modes to configure a SSID which means bridge or tunneling. If you confgure a SSID for tunneling you can do whatever you want the traffic from the AP listining for the tunneled SSID will be ALWAYS forwarded to the WiFi controller on the FGT and you can use UTM Features etc. because the traffic is ALWAYS going to the WiFi controller on the FGT. If you use on a SSID bridge the interface on the FAP which is listening for the bridged SSID is bridged. This means the traffic is NOT going ALWAYS to the WiFi controller instead the traffic goes directyl from the FAP interface to the segment in which the FAP interface is connected. Of course you can use VLAN's on the bridged SSID. Finally the first question you should answer yourself is following:

- Must the users connected to a SSID for some reason connecting directyl to a server etc. for performance reason etc.

If the answer is yes the FAP should be connected to the same segment as the servers (performance) or to a seperated interface using a specific VLAN connecting directly to the server (not so good regarding performance).  Keep in mind if you use this bridged function YOU CAN NOT USE ANYMORE UTM features on the SSID because the traffic goes not anymore to the WiFi controller.

If the answer is NO you should use from my point of view a seperated interface on the FGT connecting all your FAP's because the traffic is tunneled the traffic comes anyway always to the FGT WiFi controller and you are using UTM features it is better to connect the FAP's to an seperate Interface.

If you are using a FAP im Branche Office and the FAP is connected over the WiFi Headquarter you should use bridge SSID because otherwise the user can not surf to anywhere if the connection from the Branche to the Headquarter is not anymore up. If you do so the user connecting in the Branche to the SSID bridge they can surf arround even the Headquarter connection is down. Keep in mind in this moment the Headquarter connection is down and you are using remote authentication from the Headquarter like WPA2 Enterprise no more NEW users can authenticate as long as the Headquarter connection is down. This users which are already authenticated can surf arround even the Headquarter connection is down.

Hope this helps

have fun

Andrea

[Bromont_FTNT · Accepted solution]

Not sure example #1 is correct.... vlans should be used there not the software switch... I'll check on this.

[frederik]

Thanks for your answers. I understand the difference between the tunnel and the bridge approach. And I was aware of loosing all UTM functionality in bridge mode.

What I don't understood was why Fortinet propose to create an interface on the Fortigate for a bridge approach because the traffic will "leave" the FAP but will still be routed by the Fortigate. I discussed the situation with another person and I might begin to understand:

In the example provided by Fortinet they have a captive portal in use. My read is that you cannot setup a captive portal some other way in a bridge environment. One have to create a switch. From my point of view smaller Fortigate appliances might impact the performance as well because all the traffic is then routed again through a software switch.

I am confident now that the solution without the switch is the right one for me. Thanks for your time and help!

Frederik

[Bromont_FTNT]

Yes, that example is a very poor one, it describes the steps to get your wireless and wired on the same subnet but lacks some required steps such as creating the vlan interface on DMZ and also assigned vlan ID to the bridge interface.

[AndreaSoliva]

Hi

in general you got it...if you use a Captive Portal you have to use tunneled because the Captive Portal is running on the FGT and not on the FAP. In general DO NOT USE software switches is absolutly not recommended and neccessary. Again if you use bridge there is a GOAL to reach meaning like performance isseu getting NOT TO FGT bringen NOT THE traffic to FGT instead go directly. Again in GENERAL you do not need bridge normaly by standard use tunneled on a seperated interface meaning for Captive Portal guest and for internal use. Of course you can mix the stuff meaning using bridge for internal use getting direct to server and Captive Portal tunneled for guest access.

hope this helps

Andrea

[AndreaSoliva]

Hi

if you like to have the SSID on the same subnet as your LAN for example do following:

- place your AP on the same subnet as your internal LAN. Because -or hopefully- within the internal LAN there is a DHCP server for your client the AP will receive the IP for mgmt. from your DHCP server.

- create a SSID and if you create the SSID set it to bridge as assing the VLAN ID if neccessary (default is 0). Actually if you place the FAP in the same subnet as your client/server you do not need a VLAN ID this is only neccessary if your clients/server are connected to different stuff mixing up on one switch segment. For the SSID define the DHCP server as relay and point it to the DHCP server within the internal LAN.

If the FAP is coming up in this constellation it will request by DHCP a IP for mgmt. only. The SSID is configured with the DHCP relay etc. from this point of view all in the same segment and no traffic goes to the FGT because of the SSID bridged.

Of course you can add another SSID for guest in tunnel mode and with a seperated IP range DHCP server served by SSID meaning FGT.

More or less that's it.....internal use can go directly disadvantage you use all UTM features. Guest must go to FGT because of tunneled and UTM feature can be fully used.

I personaly would never use bridge if I do not have to use for some reason but is my last option :)

Hope this helps

have fun

Andrea

[frederik]

Hi Andrea

I personaly would never use bridge if I do not have to use for some reason but is my last option :)

One example: if you want to add 3 FAPs to a 60D and a 60D has only 175 MBps (roughly 21 MB/s) CAPWAP throughput I have the strong feeling that I will make my internal staff not really happy .

I would love to use a tunnel but my Fortigate just don't have the power for this particular setup - or do I miss something?

Best regards

Frederik

[AndreaSoliva]

Hi

I understand your doubts but do a test...nothing easier as connect all FAP's to one interface and tunnel all SSID's and go ahead for a test. We have many many customers which are using this config and nobody complains about performance. Keep in mind that this setup is for not only wirlesss meaning all this customers are using by standard cabling for the internal access and the SSID's are used for devices which do not have cabling which means IOS device, android etc. A setup for internal based on -only wireless- I would never do because to many factors are impacting wirless like interferences etc. From this point of view this stuff is mainly used for guest access and for internal access and/or outside world for devices which do not have a cabling etc. Go ahead and do a test...is configured in 5 minutes and you can test and try. Keep in mind that if you do test that UTM features are mainly impacting also the performance like Antivirus, WebFilter etc. If you do test do not doing test with Internet based tools etc. use test tool which you have full controll like:

           http://www.metageek.net/support/downloads                    (inSSIDer für Windows / Mac / Android)            http://www.nirsoft.net/network_tools.html                    (WifiInfoView für Windows)            http://www.ekahau.com/products/heatmapper/overview.html      (HeatMapper für Windows XP / Windows Vista / Windows 7)

or to test over internal server:

http://sourceforge.net/projects/jperf)

Try to eliminate every factor which means UTM feature, duplex mismatch or not known factors like ISP etc.

hope this helps

Andrea