pfSense Captive Portal Edit

Saturday, 21 May 2011 11:40 administrator
Print

imagespfSense: Captive Portal Logo Edit

(-Webadmin-) This article was copied from another blog - Disclosure: I am not connected with pfSense/BSD Perimeter LLC in any business manner, I am just a user. I created this feature focus for my own reasons but decided to publish it anyway. The real push for this article to me is how to control the jpg format on the public portal page. See the last part of this article to disclose the "File" area and how to manipulate your public portal page with your business artwork. 

Introduction

For the uninitiated pfSense is a standalone firewall/router the is based on FreeBSD which is designed for use on standard PC hardware. It uses the OpenBSD Packet Filter (hence the pf) for the firewall as well as advanced features such as hardware redundancy via CARP, VPN and load balancing. However I will be talking about an interesting feature called the captive portal on pfSense 2.x. 

A captive portal normally sits between the client hosts on the network and the Internet. It normally requires a login from the user before permitting access. This is useful if you wish to allow/deny some people getting online with your wireless at your house party, stop visitors accessing the internet at the office or simply for displaying an acceptable use policy.

Captive portals will normally permit access to a IP/MAC address pair that has been authenticated by the device. As anyone that knows about networking will tell you both MAC and IP address can be easily spoofed by an attacker on a LAN to an already authenticated pair permitting the attackers traffic through the Portal. This weakness is something to keep in mind when thinking of using a captive portal.

Even though a captive portal has this weakness why is a good idea to implement one? It works on any operating system that supports a web browser (Windows, Mac, Linux, BSD, etc) and requires no additional software to be installed on the host computers. These advantages are obviously great from a management perspective by allowing the device to work with any modern operating system and decreasing some administration overhead by not having to manage more software on the client computers.

Services: Captive Portal

All the configuration of the captive portal is done via the Services menu in the web interface. All the standard options are covered such as:

Some of the more interesting features that the pfSense portal has to offer are:

Authentication Options

pfSense has a few diffrent authentication options for the captive portal:

No authentication will allow traffic through the captive portal without authenticating which is useful for the bandwidth limiting feature. The local user management uses the locally stored database to authenticate users, which is handy for smaller networks with small amount of users. RADIUS authentication uses a RADIUS Server which is configured separately for more complex environments with many users. 

A Pass-through MAC address is an option which allows a configured MAC address to pass through the captive portal without authentication. There is also an option (MAC filtering) that allows you to disable the verification of MAC address which can prove useful if you have routers or other such layer 3 devices in the way of the captive portal and the clients. The 'allowed IP address' is the same idea as the pass-through MAC address but using the IP address instead of MAC address.

The users tab is where all the local accounts that are used for local authentication are managed. The user account controls are basic allowing username, password, full name (not parsed) and account expiration date when creating a new account. Accounts can also be edited and removed from this interface. Pfsense 2.0 will be improving the user account system drastically, for more information see the pfSense 2.0 section below.

HTTPS (SSL) Login

When there is not a HTTPS login option I always feel really uneasy. Thankfully pfSense has such an option if it's not a little tricky to set up. Three things must be there for HTTPS to work, a server name, the certificate (in a X.509 PEM format) and the key (RSA private key PEM format).

The first required step to enabling the SSL login is a server name for checking against the Common Name on the SSL certificate so it doesn't generate a name mismatch error. A certificate and private key must be pasted into the web interface for the SSL connections to be functional. The certificate and key can be easily generated from the tool on the System: Advanced functions page. Please note that a self-signed certificate will display an error message in the client browser unless its set up to trust it.

 

Customisable Portal Pages

The customisable pages are a nice feature of the portal to help it fit in with a network (e.g. to show a company style login page). The pfSense captive portal allows highly customisable login and error pages by allowing users to upload customised HTML pages with messages about network use or to add company logos (which are managed by the file manager).

The file manager speaks for its self really, it's the place you manage the uploaded files for the customised captive portal pages. It's nice to see that there is a way to keep track of the uploaded files and that they aren't just stuck in a directory out of the way.

Other Features

The URL redirection feature works by changing the website that would be loaded after going through the captive portal. This is useful for an intranet site or a hard to remember external domain that everyone should be directed through.

The per-user bandwidth restrictions allows you to limit the upload and download speed per user. This is a very useful feature to stop people taking up all the bandwidth which works well with the no authentication mode selected. 2.0 Alpha-Alpha features Note: These features are taken from a pre-release alpha build of pfSense 2.0 (2.0-ALPHA-ALPHA, built on Tue Jun 23 08:18:08 EDT 2009) and anything said here could change before final release. The new 2.0 release will allow you to run the captive portal on more that one interface, previously you could only use one interface at a time. This is a small improvement that will help administrators of larger networks deal with scalability and bandwidth concerns. The users tab in the Captive portal UI (Services:Captive portal) will be replaced with a Vouchers tab in version 2.0 since the user account management has been made more system wide. 2.0 User Manager

While this is not directly a captive portal feature the user manager is a heavy dependency for the local authentication used on many smaller networks. The local user management interface has been moved to System:User Manager (in the System menu under User Manager) and has been vastly improved to support more advanced settings like per user SSH Authorized Keys and will be used in a more system wide manner. Groups will also be implemented in the User manager so system privileges can limited to only what people require which is naturally a good practice. Restrictions that are assigned to groups, users are then added to groups to have the restrictions applied to their accounts. Restrictions include limiting access to web UI pages and shell access.

An LDAP server backend will be available for user authentication with fall back to the internal user/group database incase of the server being unavailable. This fits in with the vastly upgraded user management system and will surely make administrators happy.

Conclusion

(-webadmin-) UPDATE 5-30-2011 

This article was a good find for me and started me on the right path however I still have not found a concise way to walk through this. I gathered bits and pieces along the way. I am now drafting a job-aid doc so I don't loose my mind the next time. 

I like to use the captive portal that pfSense provides to allow the use of internet access and allowing guest users internet access. I also have used it on a wireless AP to allow guest wireless services for SOHO environments. By setting up your port security you can tunnel all users on guest wireless through the firewall and have your inside LAN safe. A true "Hotspot" setup. See my other articles posted on this site that will outlne the steps needed to setup guest wireless services in a small business environment. 

Tips & FAQ's

Here are some tips and FAQ's I discovered along the way... I used a Dlink 655 and did not manage the Internet interface, instead I managed the network interface and used the network portion to add an IP address to the same subnet I setup on the Opt1 pfSense GUI. When I tried to use the internet port on the Dlink interface the Dlink wants to route to another segment and separate the IP addressing you setup on Opt1 with an inside segment. This does not work with the Portal. 

Instead in my particular setup my Opt1 port is setup on 10.0.2.1 and my network static address on the Dlink is setup on 10.0.2.2 on the network interface - not the internet port. This is the same address you would use (10.0.2.2) to manage the Dlink Web Gui interface. It wasn't until I figured this out looking at the logs on the Dlink and losing a few LB's and hair. Remember to turn off DHCP on your wireless AP. Your pfSense box if setup correctly will supply all addressing. 

Another mistake along the way, I originally setup the new firewall for my customer and changed the segment differently than his original segment he was using with his Watchguard Firebox. That was a mistake also as his small network used IP printing using static IP's and there were 2 databases that he used. I knew about the Databases as I set them up using SQL and figured I would rework them - WRONG! I have worked on his network and assumed a few items and actually knew ahead about these two databases as I just fixed them a month ago. Next time a bit of pre-planning will prevent headaches when you go to deliver. 

So I had to re-setup the Lan port on the watchguard/pfsense build to match his original network segment addressing. This would seem normally an easy item with pfSense but when you change a Lan port addressing you also need to change your DHCP scope and the box will not usually acknowledge the change in the Lan port in the DHCP scope until you reboot. Not a big deal but you always have to be 2 steps ahead and have your plan setup. So I had to reboot after changing the subnet, use a static ip to reconnect to the GUI and then setup DHCP. Just throwing this stuff out there in case your trying the same thing I did. 

One more item - Block interface for Admin Web Console...Create a rule that blocks access on TCP port 443 and this will prevent anyone gaining access to the pfSense Admin WebConsole on the guest wireless subnet. I also block the web interface of the wireless AP and you can use the ip address block method as the AP is not the gateway but just an subnet address to allow the AP to work. In my case, I used a 10x subnet/24 with 10.0.2.1 as the gateway. The AP has any address on the 10.0.2.x/24 subnet to allow it to work. Remember to setup this subnet in the pfSense interface menu. 

-Update 6/7/2011- This above did not work the way I needed it - By blocking 443 on the guest wireless subnet it will also block any use of HTTPS out the firewall. So I am still searching. Along the way of searching I found m0n0wall. I literally threw together a watchguard x700 in about 15 minutes and had the portal already running. So if you are wondering about m0n0wall - try it - that is all I can say. IMHO it fits small SOHO setups. There are some limitations regarding states and not able to run multiple wan but most SOHO setups will have either DSL or Cable Modem so this is not a limitation. A bit off the thread - and back to blocking the AP Web Management Page - Still looking for different was to block this but in the mean time I have implemented a 15 plus complex character password. This may be where I leave it but I don't give up easily. 

Good luck to you and email me if you have any pointers or need help... I am building out another x700....  (m0n0wall - and it boots fast! - try it!)

http://www.nettechonline.net/index.php?option=com_content&view=article&id=96:m0n0wall-firewall-rules-dmz-or-captive-portal&catid=64:m0n0wall-rules&Itemid=79

H. 

Last Updated on Tuesday, 07 June 2011 21:36