Using Only Captive Portal Feature



  • In my company we already have WiFi access for guests and employees smartphones. WiFi network has no connections to our corporate network, and it serves only as internet access. Our current configuration is like this:

    [WiFi AP]–-----[Router Cisco 1811]–---(ISP...)

    Since we currently have fixed WPA-PSK at our WiFi AP (D-Link DWL2200-AP), we would like to "insert" captive portal with permanent access (1 year or so) for our employees, and voucher based access for our guests.

    Currently our WiFi network (192.168.1.0/24) is at separate VLAN 21 at C1811 router, and this VLAN is allowed free access to internet.

    How to incorporate pfSense to establish more controllable access to internet ? What networks do we need (LAN/WAN), with which settings ? Can you please give me few guidelines ?

    We don't need any other functionality from pfSense, since C1811 already handles many other things (Citrix Secure Gateway, VOIP, Mail server, ...)

    Thanks in advance.



  • [WiFi AP]–-[pfSense]–--[Router Cisco 1811]–---(ISP...)

    Place pfsense between Wifi AP and router.
    Use lan to connect to wifi and wan to connect to router.



  • Thanks for reply. I configure it like you proposed.

    However, I would like to access to webconfigurator from WAN side, and not from LAN side (WiFi clients). I successfuly opened WAN side, so my question is:

    How to disable access to pfSense server from LAN side ?



  • Be sure you have created rules to permit gui access from ips you trust and then disable the anti-lock rule on system -> advanced.



  • I've succesfully configured Captive Portal. But my problem is to asure access to the pfSense webConfigurator only from 2 IPs on WAN side, and disable this access from LAN.

    With current configuration, described above, I am still allowed to access webConfigurator from LAN side, after I pass Captive portal.

    Also, I don't know what is the best way to configure pfSense in my particular case (using only captive portal feature).

    I configured our Access Point (AP) with two SSIDs, each on separate VLAN. First Vlan (VLAN 11) goes directly to C1811, while second VLAN (VLAN 10) goes to Captive Portal (LAN interface). WAN interface is connected again to VLAN 11.

    Direct traffic between VLAN 10 and VLAN 11 are not allowed in C1811.

    I configured DHCP for both subnets on C1811 (DHCP is not configured at pfSense) as follows:

    VLAN10 (Captive portal users):
    Gateway: 192.168.0.5 - LAN interface of pfSense
    DNS Server: 192.168.0.5 - same as above

    VLAN11 (employees with permanent access to Wi-Fi):
    Gateway: 192.1168.1.1 - c1811
    DNS Servers: 213.191.128.8, 213.191.128.9 (public DNS servers of my ISP)

    I don't know if this is correct. Should I set public DNS servers for CP users as well. On that way, I should not allow port 53 from LAN side, and could delete this rule ?

    All settings not showed below are left at default values.
    Since Captive portal feature works OK, I didn't showed them here.

    My question:
    Is below setup OK (DNS, DHCP, etc.) ?
    Why I can still get webConfigurator from LAN side ?

    GENERAL SETUP:

    GATEWAYS:

    INTERFACES->WAN:

    INTERFACES->LAN:

    FIREWALL->ALIASES:

    FIREWALL->WAN:

    FIREWALL->LAN:

    SERVICES->DNS FORWARDER:

    Thanks in advance…



  • I think that you need to change webgui to https as captive portal needs port 80 to show auth screen.

    Go on system -> advanced to change gui protocol·



  • Hi,

    on pfsense LAN interfacve you should add firewall rule on the top of all other rules which blocks access to pfsense GUI and SSH (if enabled).

    action: block
    protocol: TCP/UDP
    source ip: any
    source port: any
    destination ip: LAN-Address of pfsense
    destination-port: 80 (HTTP)

    This will block HTTP traffic initiated from LAN subnet on the pfsense web GUI.
    The DNS server must be the pfsense LAN IP address for the guest wifi users. CaptivePortal is running on Port 8000 so you must allow this for CP to work.

    On WAN interface the rule you created is correct.

    On LAN interface the reject rule will block DNS to pfsense LAN interface and will block the CP on LAN interface (port 8000).
    So just create a rule like I described above and everything else could be open. So your guests have full access to the net, but not to the GUI and before they get access they need to authenticate against pfsense CP.



  • I thought that port 8000 is for captive portal. When I try to go to google.com, I've got:

    http://192.168.0.5:8000/index.php?redirurl=http%3A%2F%2Fwww.google.com%2F



  • @Nachtfalke:

    Hi,

    on pfsense LAN interfacve you should add firewall rule on the top of all other rules which blocks access to pfsense GUI and SSH (if enabled).

    action: block
    protocol: TCP/UDP
    source ip: any
    source port: any
    destination ip: LAN-Address of pfsense
    destination-port: 80 (HTTP)

    This will block HTTP traffic initiated from LAN subnet on the pfsense web GUI.
    The DNS server must be the pfsense LAN IP address for the guest wifi users. CaptivePortal is running on Port 8000 so you must allow this for CP to work.

    On WAN interface the rule you created is correct.

    On LAN interface the reject rule will block DNS to pfsense LAN interface and will block the CP on LAN interface (port 8000).
    So just create a rule like I described above and everything else could be open. So your guests have full access to the net, but not to the GUI and before they get access they need to authenticate against pfsense CP.

    Thanks for detail answer :-)

    So, when I left only two rules for LAN:
    1. Block any/any to LAN-address/port 80
    2. Allow everything (else) from LAN net

    That worked OK, but still I was able to access GUI from "LAN net", but when going to its WAN address: 192.168.1.5.
    Then I add new rule on LAN interface, similar to first one, and block port 80 from LAN net to WAN-address/port 80
    This finally disabled access to GUI interface from LAN side.

    Is that OK ?

    Now everything works fine, I'm just wandering my Firewall logs. There are lot of rejected/blocked traffic from other clients belongs to WAN side (separate VLAN 11 for employees - 192.168.1.0/24), mostly at ports 137/138, but also there are blocked traffic originating from public addresses to the WAN address at port 80 (see marked entry at attached pic).

    I'm just not sure if this is OK.




  • @buggy:

    You are absolutly right. You need to block the WAN-Interface, too, for the source (LAN subnet).
    I am using two pfsense at work with different VLANs and I just put all Interface IPs and Interface Ports into two aliases and then blocked it.
    So what you did is correct.

    The many blocks are "ok" - this is how the Steful Packet Inspection (SPI) firewall of pfsense works. You shouldn't worry about that.

    The marked block etry is probably and old connection a client on the LAN initiated to a webserver and was closed by the firewall but not by the webpage itself.



  • Excellent, Nachfalke!

    So, I'm almost finished. There is only one more thing which I doubt about my complete setup. At first, I had intention to use WPA2-Enterprise for my employees with separate Radius server connected to my APs. Now I see that I will have lot of problems with that approach (some smartphones, older laptops, etc. will not be able to connect, additional maintaining of radius server, etc…). I don't need to have here the best possible security, since Wi-Fi is not connected to our corporate network, this is just for just public internet access.

    So, I see two alternatives here:
    1. To leave employees on separate VLAN 11 (connected directly to my router C1811), and configure for them WPA2-PSK. I see two disadvantages here: I know that WPA2-PSK can be sniffed, and discovered by potential intruders, and another disadvantage is that our employees can easily say shared PSK to their colleagues (although we want to grant WiFi access only to some employees), so we will not have full control who is actually using WiFi.

    2. To have all clients (employees and guests) access public internet via pfSense Captive Portal, guests by using vouchers, and selected employees by using username/password created in pfSense.

    So my question is which alternative is better regarding security, or what is harder to break - WPA2-PSK or pfSense captive portal username/password ?



  • Hi,

    I am nor sure if there is really a big difference in "security". If the WPA2 key is strong enough then it shouldn't be breakable. As far as I know WPA2-CCMP (AES) has no security holes. The only problem could be a weak password.
    But weak nor strong password will protect you against an employee which gives the key to someone else.

    But you will have the same problem when using CaptivePortal and username/password or voucher. If someone gives this credentials to someone else then they can use it. BUT there is an advantage of CP. CP allows you to enable that a credential can only be used by one client at one time. If two employees are using the same username/password then there is only one able to connect.
    To "break" the CP itself - don't know if this is possible by an attacker - but the attacker can do a bruteforce attack - in theory.

    Perhaps you should think about the freeradius2 package as backend for the CP. Using vouchers for the guests and storing username/passwords on freeradius or in the local user store on pofsense itself.

    The advantage of CP is I think that you can deny the access to the internet. It is not relevant if the employees/guests do have access to a protected (WPA) WLAN or not.  You want to deny access to internet and not access to WLAN itself.
    Further CP offers you the possibility to limit bandwidth for the users so noone is able to use up all your bandwidth.

    With freeradius2 as backend of CP you are able to set times when an employee is able to authenticate on CP. But you can do this with a firewall rule and a shedule that blocks traffic from 6pm until 6pm or something else.

    Further CP is able to allow a passthrough for know MAC addresses. So you can enter all MACs of the employees devices you would like to allow. Others must use a username/password and guets can use vouchers. Of course - MAC address can be cloned but how many of your employees does know how to do that. Ok - an attacker can sniff the MAC and change it.

    It is really hard to decide but I would say:
    Use CP instead of WPA encryption

    But not sure which CP features or authentications methods you should use.



  • Thanks again for sharing your ideas.

    Yes, there are lot of alternatives.

    Considering WPA2-PSK, it seems that long and random enaugh PSK is practically impossible to break. So, the simplest solution will be to have two SSIDs, connected to two VLANs - first for guests, opened at AP (no keys), and controlled by pfSense CP (vouchers), another one for employees with WPA2-PSK. Only problem is possibility that one employee gives key to others, but I think we can live with that.

    Another approach will be to have all traffic going via CP. On that way, only one SSID/VLAN would be sufficient. I don't know exactly how CP is working, but probably it stores IP/MAC of user which successfully authenticated by vouchers or user/pwd. If this is correct, then it seems to me that it will be easier to sniff IP/MAC combination, and possibly misuse it, then to break WPA2-PSK. But I'm just guessing, I'm really not security expert. Also, if using plain http for CP where users enter their username/passwords, I think that credentials can be sniffed quite easy if using http. If, on the other side, I force https at CP, then I will probably have some issues about deploying root certificate, especially on some smartphones, etc. I know that same applies to vouchers for guests, but vouchers validity is measured in hours, so if attacker even succeed to grab the voucher code, he can use it same day only. Credentials for employees should be valid for much longer time.

    So, these were just my ideas about various alternatives. At the moment, consdering all above, it seems to me that first alternative might be easier to configure and maintain, and "good enaugh" in my current scenario.


Log in to reply