Skip to main content
A
Anonymous_User
Contributor
April 19, 2022
Solved

Bridging SSID via VLANs

  • April 19, 2022
  • 3 replies
  • 30420 views

Hi all, I would greatly appreciate help in resolving a problem I have with FG-80F and FAP-433F both on 7.2.0 where I'm trying to bridge WiFi with local interface using VLANS, without software switch.

Configuration:

  • System/Settings/VLAN switch mode: on
  • ports 1-4 as "internal_LAN", VLAN Switch with VLAN 167. This interface is configured with an IP and DHCP. All hosts connecting to this IF get IP fine.
  • ports 5-6 as "internal_IoT" - VLAN 50, I've tried different configs but for now it's unconfigured
  • FAP is connected to FG port 4 (which is internal_LAN)
    "WiFi_LAN" SSID for my LAN is configured as "bridge" and since it is physically connected to VLAN 167, it works fine bridging WiFi with LAN.

I'm trying to create a "WiFi_IoT" as bridge specifying "OPTIONAL VLAN ID" 50 and have it bridged with "internal_IoT".

 

Here is what I've tried so far.

Software switch: SS requires tunneling mode for SSID but then it's pretty easy, add SSID and unconfigured physical interfaces into it, configure SS with IP and DHCP and all connected get IP - done but not in bridge and no VLANs

 

I tried, deleting "internal_IoT" VLAN switch to free up ports 5 and 6, then creating a VLAN 50 subinterface for SS: remove IP and DHCP from SS, configure SS VLAN (50) with IP and DHCP, then if I specify "OPTIONAL VLAN ID" (50) for "WiFi_IoT" (which is a member of SS) - wifi clients get IP fine, but no matter what I do, physical interfaces 5 and 6 (which I added to SS for this config) never get served IP.

 

I tried creating VLAN SWITCH, adding 4 and 5 to it, then creating VLAN as subinterface with IP and DCHP but physical interfaces never get served by it.

 

I've tried creating VLAN SWITCH with ID 50 and no IP config, then adding it to SS but physical ports again never get served with IP

 

Since AP is physically connected to "internal_LAN", I tried setting VLANFORWARD as enabled for "internal_LAN" VLAN SWITCH thinking that it would pass traffic from AP tagged to other VLANs but no avail.

 

I've seen youtube where bridging SSIDs to VLANs in "bridge" mode and specifying "optional vlan id" was done but in that config AP was connected to FortiSwitch 108 which was then fortilinked to FG

 

Is there a way for me bridge SSIDs to FG using VLANs?

Best answer by Anonymous_User

@pminarik

THANK YOU FOR YOUR HELP!

You were right - trunk port did not take untagged traffic from the AP.

 

I need another VLAN switch for FAP management but I couldn't add a trunk port into that switch and I dont have any more free ports to populate the switch with.

 

Here is what I ended up doing that worked (kind of):

  • unset trunk for the port FAP is connected to, let's call it port "B"
    created a new VLAN switch ("mgmt FAP") with ID 200, IP, and DHCP, populated with port "B"
  • FAP did not need any modifications, it obtained the IP from VLAN switch and came online but, as expected, none of bridged SSIDs worked
  • without removing port "A" from the "mgmt FAP" switch, config system interface edit "B" set trunk enable
  • all bridged SSIDs became visible to their respective VLANs and accepted clients

So, everything works as expected except no changes can be made to "mgmt FAP" switch UNLESS port "B" is unset trunk.

Is this normal?

 

I've tried, per article you referenced upstream, to configure FAP management for manual IP and VLAN but that configuration still requires a VLAN switch on FG, which, again, needs at least one interface that I dont have.

 

Is there a better way or did I miss anything?

3 replies

Anthony_E
Staff
Anthony_E
Staff
April 21, 2022

Hello FortiForum,

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

 

Thanks,

Best Regards
Debbie_FTNT
Staff & Editor
Debbie_FTNT
Staff & Editor
April 22, 2022

Hey FortiForum,

I am by no means an expert in all things SSID bridging and VLAN, but I think your issue is the following:

- your SSID is in bridge mode

- it is physically connected on port4, so FortiGate considers the SSID a part/extension of port4

-> port1-4 are a switch

-> SSID is technically part of this because it is technically a part of port4

 

You're looking to have the SSID bridged to interfaces it is not physically connected to, correct?

Or do you want to have the SSID both bridged to port1-4 (VLAN 167) AND port5/6 (VLAN50)?

 

From what I could find, you might need a VLAN interface with ID 50 on port4, and with VLAN ID 50 in SSID, the SSID should be considered part of the VLAN ID, not part of the physical port4

Then you could use the VLAN interface + port5 + port6 and create a switch with subnet and DHCP (or VLAN 50 interfaces on port5/port6)

If I'm wrong, please let us know and we will continue to see what documentation we can find.

    A
    Anonymous_UserAuthor
    Contributor
    April 22, 2022

    Hi Debbie, thank you for your attention.

    The ultimate goal is NOT to use tunnel mode on any SSID but instead bridge them to their respective VLANs. Pardon my switcharoo game, but in my initial ports I used hypothetical interfaces and port numbers, but the principal is the same. Below is my actual configuration. AP is connected to FG-80F to port "b"

    The goal is:

    • IoT to be on VLAN 30 including physically connected devices as well as connected to "wifi IoT"
    • My main network on VLAN 167, similarly to IoT, including physically connected and "wifi LAN"
    • Both of the above wifi to stay in "bridge" mode

    You see, I understand that since AP is physically connected to VLAN switch "internal LAN" port "b" and considered to be a part of it, shouldn't there be a way for that switch to "forward" other VLANS?
    Then I can specify "OPTIONAL VLAN" 30 for "wifi IoT", create a new HW VLAN switch "internal IoT" with "VLAN ID" 30, add internal5 and "wifi IoT" to it?

     

    InterfacesInterfaces

    Internal LANInternal LAN

     

    sswitch IoTsswitch IoTwifi LANwifi LANwifi IoTwifi IoTAP ProfileAP ProfilePoliciesPolicies

    pminarik
    Staff
    pminarik
    Staff
    April 22, 2022

    I have two suggestions to feed the discussion, but neither is perfect. Hopefully someone will be able to flesh it out further...

     

    Some assumptions for the example below:

    • internal1 - interface facing the FortiAP
      internal2 ~ 3 - interfaces facing the IoT devices
    • FortiAP's own management traffic does not use VLAN-ID (untagged)
      locally-bridged SSID "IoT" is set to tag client traffic with VLAN-ID 50
      IoT devices expect untagged frames (VLAN 50 is the "native" vlan for that segment)

    Let me know if this roughly matches your goal. (If it's too different, we may need to re-think the sample setup below)

     

    Idea #1: Using VLAN-switch

    • The interface facing the FortiAP should be set to trunk:

    config sys interface > edit internal1 > set trunk enable

    • The interfaces facing the IoT devices should be included in a VLAN switch with VLAN ID 50.

    At this point, client traffic should behave like so:

    • Packets from the bridged SSID are VLAN-tagged (50) by the FortiAP, accepted on the trunk-interface, and forwarded out of the IoT VLAN-switch with the tag stripped (native VLAN).
    • In the reverse direction, IoT devices send untagged packets into the IoT VLAN-switch, the VLAN-tag (50) is attached and they are forwarded out of the trunk-interface to the FortiAP.

    However, I am uncertain as to what should happen to the FortiAP's traffic.
    By default it will hit the trunk-interface with no VLAN-tag, and I was not able to find out what happens to untagged frames hitting the trunk-interface. If they get dropped, then this is likely a show-stopper for this solution attempt. (there also doesn't seem to be any sort "set native-vlan" option for the trunk-interface)

     

    If perhaps you could make the FortiAP tag its own management traffic, then that could let you steer its traffic through the trunk-interface into another VLAN-switch (matching the given VLAN-ID)?


    Idea #2: Using the "traditional" hardware switch + VLANs on top of it

    With the non-VLAN-switch approach, things could work like so:

    • hardware switch interface (ports 1~3): process untagged frames -> handle FortiAP management traffic
    • VLAN interface on top of the HW switch: process wifi client frames tagged by FortiAP, and egress traffic towards the wired IoT clients, but still VLAN tagged(!)

    Con: You would need another switch on the path to strip the VLAN-tag if the IoT devices expect untagged frames.

    A
    Anonymous_UserAuthor
    Contributor
    April 22, 2022

    @pminarik

    Thank you for your time. Your assumptions are almost correct with one omission: there is still "internal LAN" interface that should be bridged with "wifi LAN" to service VLAN 167

    Idea #1
    So, for this great idea I would need:

    • remove internal1 from all interfaces and make it physical, unconfigured (no VLAN, no IP, no DHCP) or with IP config but no VLAN?, and set trunk enable
    • attach AP to internal1 - wouldn't I need internal1 to assign IP to AP?
    • create VLAN switch for IoT with internal1-3, VLAN ID set to 50, IP and DHCP configured
    • create VLAN switch for LAN with internal4-6, VLAN ID set to 167, IP and DHCP configured

    WiFi Config:

    • IoT wifi - in bridge mode, Optional VLAN ID set to 50
    • LAN wifi - in bridge mode, Optional VLAN ID set to 167

    Correct?

    pminarik
    Staff
    pminarik
    Staff
    April 22, 2022

    Yeah, additional bridging would simply consist of the repetition of:

    - set the "optional" VLAN ID for the bridged SSID

    - create VLAN-SWITCH with the same VLAN-ID (solution #1) / or create another VLAN-interface on top of the HW-switch with the same VLAN-ID (solution #2)

     

    And you're right about "wouldn't I need internal1 to assign IP to AP?". That's the part where I am not certain about solution #1. I suspect that the trunk-interface may not accept untagged traffic.

    If you're willing to test this, and the trunk-interface indeed does not accept untagged frames from the FortiAP, then you could consider setting the management VLAN-ID for the FortiAP, as described in this KB . If you choose to go this way, then you will additionally need to make one more VLAN-switch with the same VLAN-ID. This would then be the place to configure the IP/subnet/DHCP for the FortiAP.

    Terms & ConditionsAccessibility statement