We'd love to hear about it! Click here to go to the product suggestion community
I want to deploy WiFi on two sites, both having an UTM to manage WiFi. I would like to allow users to travel between sites and connect to the same WLAN (i.e., the same SSID) on both sites.
The sites are also connected via VPN. I can use a common RADIUS server from both sites, so cross-site credentials are not a problem. But does this mean that all I need to do is create WLANs with the same SSID in both UTM configurations? I suspect that the answer is "no", for otherwise anybody could just setup a rogue AP with the desireed SSID and might capture the credentials when folks attempt to connect to them. In fact, in a test setup, Windows 10 clients "knowing" one of the sites will not simply connect to the other site; it causes confusion and takes (sometimes repeated) removal of known networks and rescan until connecting to the other site works. If my suspicion is right, there must be some additional secret dentifier that is different per UTM. Is there? If so, can I make both UTMs use the same secrets identifier?
(Alternatively, can I manage both sites WiFi centrally from a single UTM? I am afraid no because APs seem to contact only a local UTM)
To connect a remote AP via VPN, add to the tunnel 220.127.116.11 as a local IP for the UTM that manages WiFi.
You confuse me a bit when discussing RADIUS and secret identifiers. WPA2 Enterprise uses only RADIUS, not any secret.
I would think that it would be possible to manage WiFi separately and still use the same SSID in both locations without confusing the clients. If you try this, please let us know your results.
Cheers - Bob
i believe Windows uses the DNS dettings, home group staus, and domain server adjacency, as well as SSID, to distinguish different networks from each other.
Would your configurstion work acceptably if the DNS servers were the same in both locations?
if you have one DNS server on each side of the tunnel, it should work to have both DNS servers provisioned by both dhcp servers, but the closest server listed first on each subnet.
In reply to DouglasFoster:
Intriguing, this sounds promising and I'll give it a try.