VLAN unexpected captive portal change requirement.
-
Hello All, sorry if this is the wrong area.
I'm using 2.3.5 RELEASE
II have two physical interfaces, one connected to the WAN and one to the LAN. Nothing to special.
WAN 192.168.1.1 (DHCP Assigned from the router)
LAN 192.168.10.1 Static
DHCP range listening on LAN providing IP's 192.168.10.1/24The Wireless AP's are UBNT Unify with a SSID of woodsidebreaks.co.uk (not relevant, but included for completeness)
We have the captive portal listening on the LAN interface and when people connect it shows some blurb and requires them to click OK etc to continue. This is all working fine and without an issue.
The Unify's allow up to five wireless networks to be created and a need has arisen for another wireless network, but without captive portal, this is secured a PSK where as the other one is OPEN and secured with the portal.
I created a VLAN 100 and attached it the physical LAN interface, then created the new interface as 172.16.10.1 and added DHCP for the clients connecting in that range.
Added a firewall rule to allow all traffic from the new net to anywhere.
then added another wireless config to the Unify control panel, configured it for VLAN 100 and enabled it.
Connected a client to the new wireless network, obtained an IP in the expected range and began some ping tests within. All seems well until trying to get out to the wider network.
I was able to ping the external radius server, but nothing else.
After lots of trolling the internet and head scratching I began just grasping at straws.
It seems and this is the question. That despite adding rules to the firewall, somehow the captive portal is still effecting the traffic passing through although not configured to listen on the new interface.
I needed to add the new range of IP's to the Allowed IP Addresses for pass through within the captive portal settings. Eve though the captive portal in its own settings should only be listening on the LAN interface and not the new OPT1 which is listed but not highlighted.
All is now working as wanted, but I didnt expect to have to make this change to the Captive Portal when I'm not wanting captive portal on that interface ?
Is this expected, I dont know if its a fault or just a strange requirement to make VLAN's work when captive portal is listening on the parent interface?