Hi @Josvell 

Thanks for posting in our business forum.

What you said is counter-intuitive and against the whole point of the portal.

When you are connected to the portal, you first join the SSID that is configured to be the portal. Then, you get the DHCP IP. Usually, the IP is from the VLAN you configured for the clients. This is what has been supported and expected.

I cannot see the point of doing this. Join SSID > determine the IP this client gets or manually configure it? Then why not just join the core network if this is a trusted device? Why would it join the guest SSID that you have enabled the portal?

And, you need to worry about how to determine the IP address the client gets.

Every single client connected to the portal SSID will manually configure an IP?

Even if you need to assign an IP address, it has nothing to do with the portal.

Configure the IP-MAC binding. You always needed some devices to get an IP, so you should set the IP-MAC binding. 

Hi @Josvell 

Thanks for posting in our business forum.

Josvell wrote

  @Clive_A I may be wrong. I clarify that I do not know very well some things. But as far as I understand, the captive portal intercepts all http and https traffic to the portal in order to authenticate me and for that the router has to assign an IP to my device before

 

 I use the captive portal in Vlan since I do not have an Omada AP ( I use a common AP)

 

 In said Vlan the Dhcp has a specific range that it will assign. Example: 192.168.100.1-192.168.100.64 in this way any guest will be assigned an IP between 1-64 and the computers on my network will already have a static IP outside that range.

 

 In those cases the devices would also have to be added. trust in free-client authentication and this process is more laborious. My other suggestion would be to fix it up a bit and make the free-Client authentication a bit more intuitive. since when you add devices you can only see the Mac and you cannot add a name to it nor are there buttons to activate or deactivate it from the list more comfortably

 

I really appreciate what they are doing and the hard work that goes into it, I also understand that there are many things that They are still finishing polishing.   

 

I'm sorry if I have any errors in the translation.  

When you intend to create this SSID for the guests, you have VLANs prior to the portal and SSID. So, you don't separate the core network devices(your devices) and the guests and you insist on placing them in the same VLAN.

Isn't this a security concern you should worry about before the portal?

While the router can support multiple VLAN interfaces, you give up this feature and insist on the VLAN in one instead of creating a dedicated guest network for your devices. Why put trusted and guests in the same network in the first place? And find a remedy after this is configured? 

This is a loophole in your configuration plan instead of the product problem/missing feature. From the architecture of your network creation, you leave this loophole.

Trust-free clients, what do you intend them to get authenticated?

What do you intend for the ACL scheme for them?

I think if you think I don't understand why and what you asked for, we are probably not on the same page. Something unaware from as you did not specify the whole network plan/scheme.

I find it absurd to understand this request in the first place and it is against the purpose of the portal. I hope you can clear this up before we move further into this discussion.