Dear @ITV ,

ITV wrote

However, guests are still trying to connect to the management-vlan-IP-adres of the controller as being the portal

 

Versus the vlan-100 IP-adres of the controller (i.e. where the portal resides for that specific vlan).

For example - the management vlan is 192.168.9.0/24.

The default gw is 192.168.9.240. The controller, the wifi-guest-portal and the DNS-server are running on the same VM with ip 192.168.9.235.

For vlan-100 this 9-subnet is replaced with 192.168.100.*/24.

This includes the default gw (i.e. .100.240), the controller, the wifi-guest-portal and the DNS-server (all three are .100.235)

The Omada-cloud portal shows all the vlan IP's. Meanung it looks like the controller is vlan aware?

How do I enforce the wifi-guest-clients to use the portal-IP-address of vlan-100?

This is normal, because your controller itself is in the management VLAN, and the controller itself has only one interface, if it is in the management VLAN then it can only have the IP of the management VLAN, and your client also needs to use the portal configuration on the controller, the client is required to communicate with the The client needs to communicate with the Controller for authentication.

Unless the controller goes offline, they can not communicate with each other, but in this time the controller's portal function will be also disabled.

Best Regards!

  @Hank21 

Sorry for the late response - was pretty busy these last few weeks/days.

In our case the controller (i.e. Linux-software) is available in all vlans.

See also attached screenshot: this is (more-or-less) confirmed by the cloud portal.

Meaning the controller and guest portal is also in all vlans based on an IP-address within its own subnet.

2 questions:

(1) - Why create a security risk by giving guest-devices access to a management vlan?

(2) - How would you configure a guest-vlan when working with a guest-portal?

With warm regards - Will