tx350z wrote

I don't know how else to explain the problem; the built-in portals are tightly integrated into the controller software, bound to a single IP/port, and separated only by URI. That means the controller web UI must be accessible from every VLAN needing access to a portal. This alone is a huge security concern.

Regarding EAP software and AC hardware controllers:

That's only a security problem if you think you would have to open the whole subnet to reach just one IP. But that's not the case and the solution is outlined in the recipe linked above. You just need to set a static route to the controller's IP for the controller/built-in portal. If using VLANs, this requires Inter-VLAN routing, which almost all managed switches in the T1/T2/T3 series do support.

Regarding EAP controller:

The EAP controller binds to INADDR_ANY, so you can just set up another IP (i.e. an IP alias if you have only one interface) on your server to have it listen to more than one IP. I deployed a server in my LAN using two different IPs/interfaces for the controller over a single trunk port. Works fine; the controller can be reached from both VLANs under two different IPs:

[CODE]
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:8043 *:* LISTEN 1384/java
tcp 0 0 *:29811 *:* LISTEN 1384/java
tcp 0 0 *:29812 *:* LISTEN 1384/java
udp 0 0 *:29810 *:* 1384/java
udp 0 0 *:27001 *:* 1384/java
[/CODE]

Using two or more IPs for the server's interface(s) connected to the switch allows to reach the EAP controller through as many IPs as you define.

But make sure to not use this setup on a Linux system outside an isolated private network w/o firewalling several ports not needed for communication with EAPs. There are indeed security-related flaws related to binding all and every EAPC service to INADDR_ANY. I did report those bugs to TP-Link already and won't go into more detail until this has been fixed by them in v2.6 or v2.7 for Linux.

tx350z wrote

In my case Easy Smart switches are being used so no inter-VLAN routing can be done by the switches. I agree that you can multi-home a net adapter which just leads to even greater security issues; both those that you mention as well as having every portal exposed to every sub-net.

You got me wrong. Multi-homed servers do not introduce security problems, but binding to INADDR_ANY has problems even on a server with a single IP.

Multi-homing can be set up a) with separate subnets, completely unrelated to any other local subnets the host is in, and b) using VLANs on a Linux server (eth0,10, eth0,12 etc.) perfectly supporting a TL-SG108PE/TL-SG108E with VLANs (in fact, I use this fine switch, too, as an edge switch to connect the EAPs to).

If you want to secure the server, block port 1099 for any host except localhost.If you want to try wether official v2.5.3 or whatever you use can run with privilege separation, try to set up the scheme outlined in the README of the tpeap replacement attached as a zip archive below.