Captive Portal blocks WiFi-network access [SOLVED]

gregoryzero

Good day everyone!

I'am using pfSense 2.1.2-RELEASE (i386) as a gateway, captive portal and dhcp-server.
pfSense has 4 interfaces configured (WAN LAN WIFI and OPT) all dhcp-server enabled, DNS forwarder also enabled.

Also, I have configured 3 Wifi-networks on UBIQUITY WiFi-controller:

1 - guest network for clients (segregated from others by VLAN)
2 - network for work and personal usage
3 - test network.

The problem is - When I enable captive portal on interface OPT, and connect to WiFi-network 2 or 3, my device receives IP-adress 10.1.., which is correct, and I can authenticate, connect and browse the web.
But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection…
When captive portal is disabled, every WiFi-network works fine.

Where is the problem?

heper

do you have the vlans trunked between the wifi and pfsense ? does each vlan have an interface assigned in pfsense ? is there a switch between pfsense & the wifi controller, how is that configured ?

gregoryzero

@heper:

do you have the vlans trunked between the wifi and pfsense ? does each vlan have an interface assigned in pfsense ? is there a switch between pfsense & the wifi controller, how is that configured ?

I have 4 TP-Link TL-SG2424 switches linked together by Cat5 cord.

Switches wich serve WiFi AP's, have VLANs ports set to:

Link Type - GENERAL
Egress Rule - TAG

WIFI interface in pfsense has corresponding VLAN configured on all 4 TP-Link switches
OPT interface in pfsense has corresponding VLAN configured on TP-Link switch 1

Gertjan

@gregoryzero:

…..
But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection...

This seems normal to me.
These IP's are auto-assigned IP's.
That means, if a DHCP request isn't answered by any DHCP server in x time, the device auto-assigns itself an IP.
These are always in the "169.254.." range.
And yes, the client 'made up" this IP by isself, but there wil be no Gateway, no DNS, no nothing.
"169.254..**" isn't even routable, so …. no "Internet".

So: on "network 1", no DHCP requests are passed to a DHCP server (or: the reply won't make it back).
In both cases: the log of the DHCP server will shed some more light.

gregoryzero

@Gertjan:

@gregoryzero:

…..
But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection...

This seems normal to me.
These IP's are auto-assigned IP's.
That means, if a DHCP request isn't answered by any DHCP server in x time, the device auto-assigns itself an IP.
These are always in the "169.254.." range.
And yes, the client 'made up" this IP by isself, but there wil be no Gateway, no DNS, no nothing.
"169.254..**" isn't even routable, so …. no "Internet".

So: on "network 1", no DHCP requests are passed to a DHCP server (or: the reply won't make it back).
In both cases: the log of the DHCP server will shed some more light.

DHCP-server log shows this:

dhcpd: send_packet: Permission denied
Failed to send 300 byte long packet over bce1_vlan30 interface

Gertjan

@gregoryzero:

DHCP-server log shows this:

dhcpd: send_packet: Permission denied
Failed to send 300 byte long packet over bce1_vlan30 interface

Well, that's clear enough.

I guess: undo all the vlan-stuff and all starts working. Start digging in that direction.

gregoryzero

@Gertjan:

@gregoryzero:
DHCP-server log shows this:
dhcpd: send_packet: Permission denied
Failed to send 300 byte long packet over bce1_vlan30 interface
Well, that's clear enough.

I guess: undo all the vlan-stuff and all starts working. Start digging in that direction.

It seems, that everything will be easier…
I applied the 2.1.4 update and it seems, that this issue has been resolved.
Thanks everyone for help.