WLAN WIFI Cloud Config

Guys,
We are currently in the process of moving our AP's from firebox managed to wifi-cloud, was simple on firebox couple of vlans and policies on the firewall and that was it.
I have just moved one AP to the cloud to test, I can see it, I can set up SSID, but ideally I do not want to use bridged modes as all my guest wifi clients will be pulling local dhcp addresses, I have looked at Nat, but can I get it to go, none of my switches have vlans on at present, it's just a flat network, anybody point me in the right direction, ideally want a range for visitors and a range for internal clients but on a seperate IP range to my local dhcp addresses.

Cheers

Gaz

Comments

  • To have a single AP have multiple SSIDs, each with a different subnet, you need to use VLANs, and you either need to have the AP directly connected to a firewall interface or you need the AP VLANs set up on your switches.

  • Cheers Bruce,
    We are moving away from our physical fireboxes to go to a virtual cloud one, hence the need to move the AP's to the cloud, I will setup a Vlan on my switches now and see how far I get.

    Gaz

  • The solution is the same for cloud or GWC managed AP

  • Getting closer, I have the Vlan of one of my SSID's on the Ap120 set up on the switch and tagged on the port the AP plugs into, now, how does the firebox know which vlan ID to look for, is that done as a seperate vlan in network configuration or in the gateway access controller.
    Also as the port is tagged for the SSID on the switch, I lose the management side of it as it's cloud based and it uses a local DHCP IP of my lan.
    Sorry for all the questions, as you can tell Vlans are new to me.

    Cheers

    Gaz

  • You need to set up a mgt VLAN which is non-tagged.

    "By default, management communications traffic to the AP is untagged, so we recommend that you add an untagged VLAN for management traffic"

    From here:
    Configure VLANs for WatchGuard APs
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/wireless/ap_vlan_about_c.html

    You set up the VLANs in XTM in the Network area, and associate a VLAN with a firewall interrface.

  • Cheers Bruce,
    Figured out the Vlan against interface after I posted, I have a management Vlan for my other AP's that are managed by the firebox, but as soon as you convert the AP to a cloud managed one, you lose the ability on the AP to assign anything against the IP it assigns itself, unless I am missing something.

    Cheers

    Gaz

  • Ok, Sorted the managed side of it, getting traffic from the cloud managed AP to the firebox, but now I get the following logged on the firebox, Tried adding to allowed sites, the IP is a DHCP one assigned from the Cloud AP, seems it's trying to resolve to google's dns server, but thinks it's spoofed.

    2020-10-08 10:41:10 Deny 10.75.0.77 8.8.8.8 dns/udp 52928 53 Firebox Firebox ip spoofing sites 59 127 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" Traffic

    Thoughts.

    Cheers

    Gaz

  • That indicates that XTM does not expect to see packets from 10.75.0.77 on the interface listed - which in this case seems to be Firebox - which is an alias for firewall interfaces.
    Any idea where 10.75.0.77 is defined?

  • The only place 10.75.0.77 is listed is in the DHCP pool on the AP Cloud settings, it assigned that address to a device that is connected to the SSID with that pool, that SSID has a vlan id of 3, tagged on the switch, and then tagged on the firewall interface it's plugged into, traffic seems to get to the firewall, but then throws that error.

  • What is the VLAN 3 subnet as defined in XTM ?

  • Bruce, Vlan 3 is on a optional zone, with a IP address of 10.75.0.103, dhcp is disabled as the AP provides them, that is assigned to eth0 where only Vlan 3 is selected, and send / receive tagged traffic for vlan is ticked.

    Gary

  • Sorry subnet is / 16, got carried away

  • No more ideas
    Time for a support incident
    If you find the issue, please post it

  • Got a cased logged, been passed over to 2nd line, will post the issue and hopefully the fix.

    Cheers for your help Bruce, seems you live on here, If you don't work for watchguard they should be paying you.

    Cheers

    Gary

  • Just a user, trying to help when l can

  • I realize this is an old post. Gary, do you remember the resolution for this? I'm having a very similar issue with an AP trying to send syslog data back to the controller. Most of the time the syslog traffic correctly passes through from my management VLAN to the controller, and every once in a while I get a IP spoofing warning with the correct IP of the AP, and the interfaces are "firebox".

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @keysd
    The firewall will drop traffic whenever it sees traffic on an interface it's not expecting it on as "spoofing"

    You can:
    -Make sure the traffic exiting the AP is the correct subnet for the VLAN/network it's on.
    -Turn off IP Spoofing in Default Threat protection.

    See:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/intrusionprevention/spoofing_attacks_about_c.html

    I would suggest ensuring that the correct IP is being written by the AP for that network -- simply turning off the spoofing drop behavior on the firewall will generally cause traffic that can't get back where it came from when replied to since the source IP is for a different network.

    -James Carson
    WatchGuard Customer Support

  • Thanks @james.carson

    The IP address is correct according to the traffic log. There is a possibility the traffic is being sent to the wrong interface if something stripped the VLAN tag. I'm curious why the interface is reported as "firebox".

    I noticed something else that might be of interest. Syslog traffic that is successfully passing the firebox always has a random source port. The traffic suspected as spoofing always has a source port of 514.

    Maybe I need to do a packet capture between my switch and the firebox to have a look at the traffic hitting my VLAN interface?

  • A source port of TCP port 514 suggests that this is a Syslog reply packet.
    Perhaps the firewall no longer has session info matching this packet, and thus denies it.

Sign In to comment.