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
0
Sign In to comment.
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".
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.