APs, VLANs and no access, oh my!!!

kcallis

I have setup my AP (TL WA901ND) with multiple SSIDs in which my GUEST is tagged and accessible on my GUEST VLAN interface. If I do not enable to CP zone, my guests are able to access the internet just fine. The moment that I enable the CP, although my guest clients are able to associate with the Access Point, there is no connection with the portal page.

I currently have my GUEST interface with no access to my other interfaces expect the WAN interface, and uses public DNS servers only (so no use of the Resolver or Forwarder). I have attached my rules down below. I am assuming that I will need to use the DNS Forwarding or Resolver, but currently I use the forwarder for my interface (basically my LAN) and the rest (excluding the guest interface) uses the resolver.

VL15_Rules.PNG_thumb

Gertjan

Hi,

Your clients are using DCHP and received an IP, gateway, DNS, etc ?
As per https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - even before authenticating, clients can resolve ?

Using multiple SSID's, VLAN and NOT using the pfSEnse as a DNS for your Captive portal network means : adding 3 systems together and then test.
I wouldn't proceed like that.
Implement one step at a time, test, then add another step, combine, and test, then you know what goes wrong, and probably why.

Btw : your Captive Portal GUI firewall rules seem fine to me, but I advice you to use the commands shown here https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting so you can see also the ipfw rules (apply top to down) - the ipfw rules are not the GUI rules. ipfw rules are used first, and then the GUI rules.

kcallis

@Gertjan:

Hi,

Your clients are using DCHP and received an IP, gateway, DNS, etc ?
As per https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - even before authenticating, clients can resolve ?

Using multiple SSID's, VLAN and NOT using the pfSEnse as a DNS for your Captive portal network means : adding 3 systems together and then test.
I wouldn't proceed like that.
Implement one step at a time, test, then add another step, combine, and test, then you know what goes wrong, and probably why.

Btw : your Captive Portal GUI firewall rules seem fine to me, but I advice you to use the commands shown here https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting so you can see also the ipfw rules (apply top to down) - the ipfw rules are not the GUI rules. ipfw rules are used first, and then the GUI rules.

As long as the CP is not enable (actually even when the CP is enabled), the client get DHCP correct:

Connection-specific DNS Suffix . :

Wireless LAN adapter Wireless Network Connection:

Connection-specific DNS Suffix . : local.lan
Link-local IPv6 Address . . . . . : fe80::c887:397d:60d7:4e9e%14
IPv4 Address. . . . . . . . . . . : 192.168.15.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.15.1

I have followed the troubleshooting and this is what I ended up with:

[2.4.2-RELEASE][root@router-01.local.lan]/root: ipfw table all list –- table(cp_ifaces), set(0) ---
re0.15 2100 20 1066 1516539876
--- table(vl15_guest_auth_up), set(0) ---
--- table(vl15_guest_host_ips), set(0) ---
192.168.15.1/32 0 0 0 0
--- table(vl15_guest_pipe_mac), set(0) ---
--- table(vl15_guest_auth_down), set(0) ---
--- table(vl15_guest_allowed_up), set(0) ---
--- table(vl15_guest_allowed_down), set(0) ---

[2.4.2-RELEASE][root@router-01.local.lan]/root: ipfw table vl15_guest_auth_up list
–- table(vl15_guest_auth_up), set(0) ---

[2.4.2-RELEASE][root@router-01.local.lan]/root: ipfw table vl15_guest_auth_down list
–- table(vl15_guest_auth_down), set(0) ---

Again, this is when I have the CP enabled, since there would not be anything if it wasn't enabled? Again, if I disable the CP, then clients access the internet with no problems. If I enable the CP, if I attempt to connect to say google.com, it hangs for about 3 or 4 minutes and then timeout.

K.

CaptivePortal1.PNG_thumb

CaptivePortal2.PNG_thumb

CaptivePortal3.PNG_thumb

CaptivePortal4.PNG_thumb

Gertjan

@Gertjan:

As per https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting - even before authenticating, clients can resolve ?

Read the first 3 lines here : https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting (they explain that nearly all portal trouble related to a failing DNS accessibility)
And you changed default DNS settings ….( why ?)
With other words, according yo as the rules you showed : can clients access the DNS you specified, if it isn't pfSense itself ?
Is pfSense resolving for the captive portal clients ? I know that traffic to table named "vl15_guest_host_ips" lets through all traffic.

Can clients resolve ?

edit : The Authentication method is set to none. I never tried that one.
I guess that even when the default captive portal page shows up, you'll be hitting the next wall : no way to go further.

heper

afaik, pfsense needs to be the dns-server for the clients in order for captiveportal to work ….

Derelict

Or the DNS servers the clients are configured to use must be passed with an IP address passthrough so they can be accessed prior to punching through the portal.

IE you can tell your clients to use 8.8.8.8 and 8.8.4.4 you just have to be sure they can access them before authentication with the portal.

Gertjan

@kcallis:

As long as the CP is not enable (actually even when the CP is enabled), the client get DHCP correct:

Connection-specific DNS Suffix . :

Wireless LAN adapter Wireless Network Connection:

Connection-specific DNS Suffix . : local.lan
Link-local IPv6 Address . . . . . : fe80::c887:397d:60d7:4e9e%14
IPv4 Address. . . . . . . . . . . : 192.168.15.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.15.1
….

You used

ipconfig

You should use

ipconfig /all

and then you would see what really happens ;)

You will be seeing :

....
   Serveurs DNS. . .  . . . . . . . . . . : 192.168.15.1
....

This is valid for my setup - because as per DHCP-server instructions, I tell clients that "pfSEnse" is the DNS server - resolver.
You didn't.
You changed the rules.
You tell your clients that someone else should be used as the DNS server : Google DNS or 8.8.8.8

But … the default firewall - ipfw - rule says :

--- table(vl15_guest_host_ips), set(0) ---
192.168.15.1/32 0 0 0 0

which means : before authentication, only connections to 192.168.15.1 are possible.
The result is that DNS resolving is dead. "8.8.8.8" can't be reached.

It's ok if you want to use the DNS from Big Brother (Google, 8.8.8.8) but you should add this IP to the "Allowed IP addresses" list.
read https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting again - first 5 lines. Now you understand :)

edit : but I guess @heper is right. Live is so more easy if pfSense is the DNS for all connected clients. It's so cool, nothing to maintain, rock solid, just perfect. I'm pretty sure you can make a deal with big brother.