Different Authentication on different SSIDs/VLANs

[TKits]

Model :

Hardware Version : 1.0

Firmware Version : latest

ISP : [/COLOR]

Hi Guys,

i have configured an AC50 with some CAP1750 with 2 SSIDs on different VLANs

As example my AC50 has the ip 192.168.0.253/24 (ManagementNetwork) Default VLAN 1 connected to a HP 2530-24

SSID "Internal" maps to VLAN 10 Controller has 192.168.1.253/24 (ProductivityNetwork)

SSID "Guest" maps to VLAN 11 Controller has 192.168.2.253/24 (Guest-WiFI)

Multiple DHCP-Server on Gateway with all VLANs functional.

Everything works very well, but now i want to configure different Auth. on VLANs :

VLAN 10 only WPA/WPA2
VLAN 11 captivePortal with voucher Auth.(or WebAuth,onkey what ever)

If i try to connect to vlan 11 captive Portal capture my devicerequest and trys to redirect to vlan 1 192.168.0.253, but VLAN 11 is the guest-network
and devices from here i do not want in my ManagementNetwork or elsewhere...

Knows anybody how to resolve this problem ??
Is there a way to bind the captiveportal to another IP(192.168.2.253)

greets
TK

[tx350z]

You will probably need to build your own captive portal, deploy it to a server in the 192.168.2/24 subnet, then use external portal authentication to direct guest connections to the portal. I'm struggling with the same basic problem with the Omada (EAP) line of equipment.

[TKits]

Thx for your reply.
But the suggested way is not the solution what i am looking for...
The primary problem is, every standard Network is VLAN1 and the primary VLAN of AC50 is VLAN1 too.
And is not changeable with the Webaccess and the Auth.Website ist bind to this VLAN Ip-adr.

The management Website ist accessible over all other VLAN-ip-Adr. why not the Auth-page ??

[Ofloo]

Why not run your management software inside a vm and just add multiple interfaces for the captive portal or forward, ..

An other option is to run nginx virtual host and just proxy the traffic.

[R1D2]

The management Website ist accessible over all other VLAN-ip-Adr. why not the Auth-page ??

See this recipe: you would us static routes: http://forum.tp-link.com/showthread....mp-AC-products

[TKits]

Thx Guys,

to Ofloo : i will try to extract the ManagementSoftware from my Hardwaredevice AC50, may be i need a hammer or some other tools

to R1D2 : thx for your hint, but if you have read that Guide you know thats a enormous effort and i hope there is a simple Solution,
probably the programmers have to do something. It could not be so diffcult to integrate a function to bind the auth-page to other ip-adresses.
And this change could provide much more flexibilty....

[R1D2]

to R1D2 : thx for your hint, but if you have read that Guide you know thats a enormous effort and i hope there is a simple Solution,
probably the programmers have to do something. It could not be so diffcult to integrate a function to bind the auth-page to other ip-adresses.

The guide just shows one possible solution, but the principle is always the same. And no, "binding IPs to an auth page" is no acceptable solution, since authentication then could be easily circumvented by clients just having to change the IP to break into the network.

That's why every business-class solution uses VLANs for Multi-SSIDs / separation of subnets for different classes of users and this is the reason why programmers did implement it in this way on AC50/CAPs and also on EAPs, CPEs etc.

[TKits]

Hallo R1D2,

i think you has misunderstood my request... VLAN is a must have !

I mean not a simple IP-Bind, i mean an IP-Binding with VLAN-TAG.

The ManagementPage works so like i awaited, if i bind an IP-to vlan 10 then it is possible to access this page from the WLAN with VLAN10 !
Thats what i want for the Auth-Page, nothing else

And you mean that is not a risk ?!?
If the Auth-Page always bind to VLAN1 that is a potential risk cause i must open my Firewall to give the user access to the Auth-page...
If i have then Auth-page on VLAN10 with an IP from VLAN10 then it is more secure.

Now it will conflicting with every standard-network, that customer have already ...

[tx350z]

The guide just shows one possible solution, but the principle is always the same. And no, "binding IPs to an auth page" is no acceptable solution, since authentication then could be easily circumvented by clients just having to change the IP to break into the network.

That's why every business-class solution uses VLANs for Multi-SSIDs / separation of subnets for different classes of users and this is the reason why programmers did implement it in this way on AC50/CAPs and also on EAPs, CPEs etc.

I think the request to allow binding a portal to specific host IP address combined with specific VLIDs is actually the most secure configuration you can possibly have. The issue here is that for the AC and EAP product lines require the portals to all live on a single VLID which pretty must kills the idea of dividing VLAN/SSID into separate IP sub-nets UNLESS the SSID's use PSK authentication. Coupled with the fact that portal defined Local Users and Vouchers are shared by all portals, the built in portal functionality in the EAP product line is of limited use.

I've encountered the same problem as TKits (I'm using EAP225s). Specifically, the need to have different portals for different VLAN/SSIDs accessible to specific IP sub-nets. Because a portal cannot be bound to an IP, every VLAN/SSID must be in the same IP range at least from the viewpoint of the controller software. To improve security, I've resorted to using a single /20 IP range then manipulating sub-net masks using VLAN specific DHCP scopes so that each VLAN/SSID "functions" as though it is in an isolated /24 IP sub-net. It is ugly but it works.

There are two simple features that will solve the problems I've encountered. First, allow binding a portal to a specific host IP address so that VLAN/SSID/Sub-net binding can be fully implemented. Second, Local Users and Vouchers should be defined within a portal (they are currently shared across all portals).

[R1D2]

I still don't get your problem, sorry.

If there is a shared portal/auth service you have to access from all subnets (VLANs) you just create another VLAN for the auth service only.

In fact, I just did set up this scheme for a customer, but with our own captive portal, which in respect to portal/authentication pretty much works like the AC50 does. And yes, we have a private, isolated network, a transfer network for Internet access, an isolated management network and two networks bound to two SSIDs. I don't have to open the firewall of any VLAN for the portal except for the two VLANs connected with the EAP's SSIDs. The captive portal runs on a system which connects to the auth service over an isolated VLAN which is apart from private and management VLANs. There is absolutely no risk since the auth service is the only service which can be reached through its isolated VLAN.

In TP-Link's recipe you use VLANs, ACLs and Inter-VLAN routing for making the AC50 accessible for all CAPs. I still can't see why this should be a problem to give access to the AC50 only. Maybe you are to focused of running the AC50 in your main network? Our captive portal is VLAN-aware, so we don't need ACLs or Inter-VLAN routing (this does the CP automatically), but the principle is just the same. But I don't have an AC50 here to test with, we use EAPs and a dedicated router running the CP or alternatively the router and EAP software controller, both work with Multi-SSID and isolated VLANs pretty well.

[tx350z]

I can't speak for the AC/CAP products. I am using only Omada APs and controller software running on an Ubuntu server. I am also running all easy smart switches with no (very expensive) layer 3 switches or routers.

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.

Ideally, the portals should be assignable to an IP/port that is isolated from the controller IP/port. Think of it as allowing the built-in portals to function like external portals that just happen to be running on the same host as the controller software.

[R1D2]

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:

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

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]

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.

So, without the ability to bind a specific portal to a specific IP, my recommendation is to roll your own external portal which includes the security features missing from the built-in portals. That is what I am working on now.

[R1D2]

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.