• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Using Only Captive Portal Feature

Scheduled Pinned Locked Moved Captive Portal
13 Posts 3 Posters 14.4k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B
    buggy
    last edited by Feb 8, 2012, 10:05 AM

    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.

    1 Reply Last reply Reply Quote 0
    • M
      marcelloc
      last edited by Feb 8, 2012, 11:23 AM

      [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.

      Treinamentos de Elite: http://sys-squad.com

      Help a community developer! ;D

      1 Reply Last reply Reply Quote 0
      • B
        buggy
        last edited by Feb 8, 2012, 8:34 PM

        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 ?

        1 Reply Last reply Reply Quote 0
        • M
          marcelloc
          last edited by Feb 8, 2012, 8:38 PM

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

          Treinamentos de Elite: http://sys-squad.com

          Help a community developer! ;D

          1 Reply Last reply Reply Quote 0
          • B
            buggy
            last edited by Feb 16, 2012, 8:08 AM Feb 15, 2012, 10:00 AM

            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…

            1 Reply Last reply Reply Quote 0
            • M
              marcelloc
              last edited by Feb 15, 2012, 12:28 PM

              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·

              Treinamentos de Elite: http://sys-squad.com

              Help a community developer! ;D

              1 Reply Last reply Reply Quote 0
              • N
                Nachtfalke
                last edited by Feb 15, 2012, 3:36 PM

                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.

                1 Reply Last reply Reply Quote 0
                • B
                  buggy
                  last edited by Feb 15, 2012, 4:14 PM

                  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

                  1 Reply Last reply Reply Quote 0
                  • B
                    buggy
                    last edited by Feb 15, 2012, 5:29 PM

                    @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.

                    FW-Log.png
                    FW-Log.png_thumb

                    1 Reply Last reply Reply Quote 0
                    • N
                      Nachtfalke
                      last edited by Feb 15, 2012, 6:12 PM

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • B
                        buggy
                        last edited by Feb 15, 2012, 6:51 PM

                        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 ?

                        1 Reply Last reply Reply Quote 0
                        • N
                          Nachtfalke
                          last edited by Feb 15, 2012, 7:37 PM

                          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.

                          1 Reply Last reply Reply Quote 0
                          • B
                            buggy
                            last edited by Feb 15, 2012, 10:09 PM

                            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.

                            1 Reply Last reply Reply Quote 0
                            1 out of 13
                            • First post
                              1/13
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                              This community forum collects and processes your personal information.
                              consent.not_received