Request: blocked hostname
-
Hi,
The captive portal instance should run on it's own reserved interface.
One of the advantages is then : add your host names to aliases, and make nice rules with them on the interface's Firewall tab. -
Hi,
I'm not sure you understand or i have explained it well enough.
In addition to the "Allowed Hostnames" can we have a "blocked Hostnames"
-
Why would you need that? If they are not "allowed" then they blocked - how the captive portal works.
-
@jinksy said in Request: blocked hostname:
Hi,
I'm not sure you understand or i have explained it well enough.You nailed it !!
The "Allowed Hostnames" tab contains a list with host names that are accessible to the Captive portal visitor even before he authenticates - for example, while visiting the login page.
This is useful so pages could be included into the login-page with usage rules, images hosted remotely, and stuff like that.
Nothing to do with limiting or allowing access to hosts after being authenticated. For this, you have your firewall rules on the Firewall => Interface tab. -
Oh i see, I thought it was for allowing access or to bypass the captive portal, similar to what you can do with MAC addresses.
Do you know of any way you can block certain hostnames possibly using regex?
In short i want to block certain hostnames from being able to access or use the network based on hostname, aprox 3000 potential devices, and i dont want to assign each MAC a static IP to block it on the firewall access list.
PS thank you for the clarification,
-
So your saying these devices would be able to auth, ie some user using them with ability to auth to the captive portal. And you don't want them to be able to?
-
Yes, its a "public" network and i dont want corporate devices using it,
-
Now I get yah... what are these devices - laptops/PCs? Windows for example can be prevented from connecting to specific wifi networks..
That is the rub when running a corp network where you try and filter, but then have a guest network for "guest" to use that you don't filter - your users just can jump on this guest network and circumvent your filters.
What stops them from just connecting to their phones hotspot and circumventing?
This is better controlled on the device by limiting what wifi they can actually connect to, etc. Windows allows for filters, you can do a denyall other than your allowed, etc.
If these are specific types of devices you could deny them from getting an IP from your dhcp server with use of partial mac address..
-
You have hit the nail on the head, and thats what i've requested to be implemented, wireless filters, which works really well.
It's mainly a security concern that a corporate Windows laptop can connect to the same network as 400 other users, not everyone has the best intention... hell if i wasnt were i was doing what i do i would have poked a little myself
Thank you
Chris
-
Normally you run guest network in isolation mode.. I have never seen an AP even the cheapest of the cheapest wifi routers normally support isolation mode for an SSID, they sometimes call it something different.
But wifi device A on ssid XYZ can not talk to device B.. This should help with security concerns of corp devices on same network as guest devices.
Normally anyone that runs a hotspot should be in this sort of setup - say your starbucks and the like.. Hotels for example normally like this.. But then you normally always force vpn connections on laptops as well so that even if they connect to a wifi network that is open, all their traffic goes through a vpn, and firewall on the device would prevent access to laptop itself..
-
Your right again... Cisco just name it "Public Secure Packet Forwarding" , which we have implemted,
-
Unifi calls its Guest Policy and Access Control - you can run this without a captive port or with, etc. And prevent clients from talking to each other..
Like I said have never seen an AP that doesn't have some way of isolation of clients.. BTW your mac control on your captive portal running on pfsense would not stop client A from talking B.. Those controls would only work for devices talking to pfsense or beyond.
-
When using multiple AP's, all hooked up to a 'dumb' switch, and this switch hooked up to an OPTx interface on pfSense, each AP should be enforced to allow communication to OPTx - and no body (any other device on the switch) else.
Client Isolation, or what ever the name is, on each AP isn't enough.Consider "AP1" and 2 clients connected to it. Client Isolation on this AP handles the job. But a third client, connected to AP2 would be able to "see" client 1 and 2 on AP1.
On a low-budget Cisco/Linksys - typically an E1200 - using the DD-WRT OS, this can be handled with :
#!/bin/ash insmod ebtables insmod ebtable_filter ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d Broadcast -j ACCEPT ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d 00:0f:b5:fe:4e:e7 -j ACCEPT ebtables -t filter -A FORWARD -s 00:0f:b5:fe:4e:e7 -d 0:0:0:0:0:0/0:0:0:0:0:0 -j ACCEPT"00:0f:b5:fe:4e:e7" is the MAC of my OPTx (pfSense - Captive portal) interface.
It states :
Allow all broadcasts.
Allow all traffic coming to interface OPTx
Allow all traffic coming from OPtx
(drop the rest)With these ebtables rules on each AP, inter AP communication is prohibited.
I guess the same result can be obtained with a "smart switch".
