Installation Guide

This setup has been tested using VMware ESXi, Fusion and Workstation products with 16 GB of RAM dedicated to the virtual machine. It might work using other VMware products. To properly run the PacketFence virtual appliance, you need a CPU that supports long mode. In other words, you need to have a 64-bit capable CPU on your host. PacketFence ZEN comes in a pre-built virtual disk (OVF). If you are using an ESX type hypervisor, you need to import the OVF using vSphere Client (or vCenter).

First network card of virtual machine is configured to receive an IP through DHCP.

The virtual appliance passwords are:

Make sure that there is only one virtual network card created, and also make sure that your vEthernet is connected to a virtual switch (vSwitch). That virtual network card will be used as the PacketFence management interface.

Newer versions of VMware Player handle VLAN trunking a lot better. With that in mind, we can use a single interface on the VM. So, you need to ensure that your VM host is plugged into a physical trunk port with VLAN 1,2,3,5,10 and 200 as the allowed VLAN. These VLANs will be used later in configuration examples.

This setup has been tested using VMware ESXi, Proxmox VE and VirtualBox but will also work with any hypervisor PacketFence supports as well as bare-metal servers.

You will need a virtual machine or server with 16 GB of RAM dedicated to machine as well as 4 CPUs. Make sure you allocate at least 200GB of disk space for PacketFence.

Provision a virtual machine with the specifications above, mount the ISO in the CD/DVD drive of the machine and start it. The installer will open and you will simply have to follow the instructions on screen to complete the installation.

First, make sure your server follows the specifications above and then burn the ISO onto a DVD or USB key and boot it on the server. The installer will open and you will simply have to follow the instructions on screen to complete the installation.

Install kernel development package:

Ensure runc and podman are uninstalled (PacketFence uses docker+containerd.io)

Install kernel development package:

As a first configuration step, you need to enable 802.1X globally on the switch. To do so, use the following:

The next step is to configure AAA so it will use your newly created PacketFence server. Make sure you replace the PF_MANAGEMENT_IP variable with your actual PacketFence management IP (172.20.100.2 in our example) in the following commands:

Once AAA is ready, we can configure some or all switchports to perform 802.1X. In our example, we will only configure port no. 10 to use 802.1X:

Write the switch configuration to memory.

From Configuration → Policies and Access Control → Authentication Sources, click New external source → Email. As 'Name' and 'Description', specify 'email-source'.

Additional options available

Then add an 'Authentication Rules' with name 'catchall' with no condition and with the following two 'Actions':

Click on Create to save the new authentication source.

Now let’s add our new Email-based authentication source to our guests captive portal. From Configuration → Policies and Access Control → Connection Profiles, click on the guest profile that we previously created. In the 'Sources', click on the (+) button and add the newly created Email source, 'email-source'. Save the changes by clicking on the Save button.

Unplug and unregister your endpoint. Reconnect the endpoint - you should see the captive portal with the new Email-based registration option.

Now that you understand what authentication sources and alerting are, we will add an SMS authentication source on our guest portal. We previously used the 'Null' source but we will add an other source. Portal profiles can provide multiple authentication sources.

From Configuration → Policies and Access Control → Authentication Sources, click New external source → SMS. As 'Name' and 'Description', specify 'sms-source'. Then add an 'Authentication Rules' with name 'catchall' with no condition and with the following two 'Actions':

You will also need to select the proper carriers to do your test. Make sure you include the one your are using for your cellular phone.

Click on Create to save the new authentication source.

To use Clickatell as an SMS source, first register at https://www.clickatell.com to get an API Key for the SMS integration. Then add it as an authentication source the same way as above, except choosing 'Clickatell' instead of 'SMS' in 'Add source → External'. Enter a name, description and your Clickatell API key in the source configuration, then add the authentication rule.

Now let’s add our new SMS-based authentication source to our guests captive portal. From Configuration → Policies and Access Control → Connection Profiles, click on the 'guest' profile that we previously created. In the Sources, click on the (+) button and add the newly created SMS source, 'sms-source'. Save the changes by clicking on the Save button.

First unplug and unregister again the Microsoft Windows 7 endpoint. Then, connect the endpoint in switch port no. 10 - you should see the captive portal with the new SMS-based registration option. Note that the Null option will also be offered.

In many other NAC solutions, it is not possible to support unmanageable devices such as entry-level consumer switches or access-points. Using PacketFence, with the new inline mode, it can be use in-band for those devices. So in other words, PacketFence would become the gateway of that inline network, and NAT or route the traffic using IPTables/IPSet to the Internet (or to another section of the network). Let see how it works.

No special configuration is needed on the unmanageable device. That’s the beauty. You only need to ensure that the device is "talking" on the inline VLAN. At this point, all the traffic will be passing through PacketFence since it is the gateway for this VLAN.

The access control relies entirely on IPTables/IPSet. When a user is not registered, and connects in the inline VLAN, PacketFence will give him an IP address. At this point, the user will be marked as unregistered in the ipset session, and all the Web traffic will be redirected to the captive portal and other traffic blocked. The user will have to register through the captive portal as in VLAN enforcement. When he registers, PacketFence changes the device’s ipset session to allow the user’s mac address to go through it.

Inline enforcement, because of it’s nature, has several limitations that you must be aware of.

This is why it is considered a poor man’s way of doing access control. We have avoided it for a long time because of the above mentioned limitations. That said, being able to perform both inline and VLAN enforcement on the same server at the same time is a real advantage: it allows admins to maintain maximum security while they deploy new and more capable network hardware providing a clean migration path to VLAN enforcement.

VLAN assignment is currently performed using several different techniques. These techniques are compatible one to another, but not on the same switch port. This means that you can use the more secure and modern techniques for your latest switches and another technique on the old switches that doesn’t support latest techniques. As it’s name implies, VLAN assignment means that PacketFence is the server that assigns the VLAN to a device. This VLAN can be one of your VLANs or it can be a special VLAN where PacketFence presents the captive portal for authentication or remediation.

VLAN assignment effectively isolate your hosts at the OSI Layer2 meaning that it is the trickiest method to bypass and is the one which adapts best to your environment since it glues into your current VLAN assignment methodology.

When the VLAN isolation is working through SNMP traps all switch ports (on which VLAN isolation should be done) must be configured to send SNMP traps to the PacketFence host. On PacketFence, we use snmptrapd as the SNMP trap receiver. As it receives traps, it reformats and sends them into a redis queue, managed by pfqueue service. The multiprocessed pfqueue service reads these traps from the redis queue and takes a decision based on type of traps. For example, it can respond to them by setting the switch port to the correct VLAN. Currently, we support switches from Cisco, Edge-Core, HP, Intel, Linksys and Nortel (adding support for switches from another vendor implies extending the pf::Switch class). Depending on your switches capabilities, pfqueue will act on different types of SNMP traps.

You need to create a registration VLAN (with a DHCP server, but no routing to other VLANs) in which PacketFence will put unregistered devices. If you want to isolate computers which have open security event in a separate VLAN, an isolation VLAN needs also to be created.

In previous versions of PacketFence, it was not possible to have RADIUS enabled for inline enforcement mode. Now with the new hybrid mode, all the devices that supports 802.1X or MAC-authentication can work with this mode. Let’s see how it works.

You need to configure inline enforcement mode in PacketFence and configure your switch(es) / access point(s) to use the VLAN assignment techniques (802.1X or MAC-authentication). You also need to take care of a specific parameter in the switch configuration window, "Trigger to enable inline mode". This parameter is working like a trigger and you have the possibility to define different sort of triggers:

This will trigger all the nodes that connects to the GuestAccess SSID to use inline enforcement mode (PacketFence will return a void VLAN or the inlineVlan if defined in switch configuration) and the MAC address 00:11:22:33:44:55 client if it connects on another SSID.

The concept of having a RADIUS enforcement is to not use registration, isolation, nor the portal capabilities of PacketFence. Everything here is for RADIUS integration only. By default the management interface will be the RADIUS interface. If needed, it is possible to add an other interface from Configuration → Network Configuration → Networks → Interface. When doing so, you must select Other as the type of interface. Moreover, you must select radius as an additionnal listening daemon.

Using RADIUS enforcement, everytime a device connects to the network, a matching production VLAN will be assigned, depending on the rules in Configuration → Policies and Access Control → Authentication Sources.

DNS enforcement allows you to control the network access of the device by using the pfdns service on PacketFence.

The architecture of DNS enforcement is as following :

This enforcement mode used by itself can be bypassed by the device by using a different DNS server or by using its own DNS cache.

The first can be prevented using an ACL on your routing equipment, the second can be prevented by combining DNS enforcement with Single-Sign-On on your network equipment. Please see the Firewall Single-Sign-On documentation for details on how to accomplish this.

In order to configure DNS enforcement, you first need to go in Configuration → Network Configuration → Networks → Interface then select one of your interfaces and set it in DNS enforcement mode.

After, you need to configure a routed network for this interface by clicking New routed network. See the 'Routed Networks' section of this document for details on how to configure it.

Once this is done, you need to restart the pfdhcp and pfdns services.

In previous sections, we correctly configured our switch to do 802.1X. Now let’s slightly modify that configuration so that we enable MAC authentication and 802.1X on a new switch port. This will demonstrate the configuration differences.

Once AAA is ready, we can configure some or all switchports to perform MAB (MAC Authentication Bypass) and 802.1X. In our example, we will only configure port no. 11 without VoIP support:

If you want to test some ports with a VoIP phone (ex: Voice VLAN 200), add the following lines to your interface configuration:

Finally, for some operations (like VoIP), PacketFence still need to have SNMP access to the switch. Make sure you configure the two SNMP communities like:

When done, don’t forget to save your configuration changes using the write mem command.

You can now test the registration process. In order to do so:

On the computer:

Register the computer using the Null authentication source.

Once a computer has been registered, make sure:

You should now define the domain you want to use as the default one by creating the following realm in Configuration → Policies and Access Control → Domains → REALMS.

Next, restart PacketFence in Status → Services

First configure your domains in Configuration → Policies and Access Control → Domains → Active Directory Domains.

Once they are configured, go in Configuration → Policies and Access Control → Domains → REALMS.

Create a new realm that matches the DNS name of your domain AND one that matches your workgroup. In the case of this example, it will be DOMAIN.NET tied to mydomain.

Where :

Now associate DEFAULT and NULL realms to your domain.

You should now have the following realm configuration

In order to use Google as a OAuth2 provider, you need to get an API key to access their services. Sign up here : http://code.google.com/apis/console. In the Google APIs Console, go into 'Credentials → Create Credentials → OAuth client ID → Web Application', then enter a name and make sure you use this URI for the "Authorized redirect URIs" field : https://YOUR_PORTAL_HOSTNAME/oauth2/callback. Of course, replace the hostname with the values from general.hostname and general.domain. Save to get the Client ID and Client secret.

You can keep the default configuration, modify the App ID & App Secret (Given by Google on the developer platform) and Portal URL (https://YOUR_PORTAL_HOSTNAME/oauth2/callback).

Also, add the following Authorized domains : *.google.com, *.google.ca, *.google.fr, *.gstatic.com,googleapis.com,accounts.youtube.com (Make sure that you have the google domain from your country like Canada ⇒ *.google.ca, France ⇒ *.google.fr, etc…​)

Once you have your client id, and API key, you need to configure the OAuth2 provider. This can be done by adding a Google OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Google as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Facebook as an authentication source, you also need an API code and a secret key. To get one, go here: https://developers.facebook.com/apps. When you create your App, make sure you specify the following as the Website URL: https://YOUR_PORTAL_HOSTNAME/oauth2/callback Of course, replace the hostname with the values from general.hostname and general.domain.

To find the secret, go in your newly created app, and click on 'Settings → Basic'.

While in 'Settings → Basic', add YOUR_PORTAL_HOSTNAME in the App Domains field. Next, you will need to add the product Facebook Login. Click on Set up, and choose Web platform. Go through the 5 steps, then on the left side of the screen, go in Settings under Facebook Login. For Valid OAuth Redirect URIs, enter https://YOUR_PORTAL_HOSTNAME/oauth2/callback and then save changes.

Also, add the following Authorized domains : *.facebook.com, *.fbcdn.net, *.akamaihd.net, *.akamaiedge.net, *.edgekey.net, *.akamai.net (May change)

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a Facebook OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

You can keep the default configuration, modify the App ID & App Secret (Given by Facebook on the developer platform) and Portal URL (https://YOUR_PORTAL_HOSTNAME/oauth2/callback).

Moreover, don’t forget to add Facebook as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Github, you also need an API code and a secret key. To get one, you need to create an App here: https://github.com/settings/applications/new. When you create your App, make sure you specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback

Of course, replace the hostname with the values from general.hostname and general.domain.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a GitHub OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add GitHub as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Kickbox, you need a API key. To get one, first create an account on https://kickbox.io, then navigate to https://app.kickbox.com/settings/keys. Click on 'API Keys → Create Key'. Pick a name and choose 'Production' mode and 'Single' verification.

Once you have your API key, you need to configure the OAuth2 provider. This can be done by adding a Kickbox authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Kickbox as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use LinkedIn, you also need an API code and a secret key. To get one, you need to create an App here: https://developer.linkedin.com/. When you create your App, make sure you specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback

You can get more details about how to configure your LinkedIn application inside Microsoft documentation.

Of course, replace the hostname with the values from general.hostname and general.domain.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a LinkedIn OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add LinkedIn as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

Using OpenID Connect is a bit different than other OAuth2 sources. The reason behind that is because you will setup your own OpenID Connect source or depend on a provider for it. Configuration like token path, authorize path or API URL are specific to your setup. For more information on how to create your own or get a host please visit: http://openid.net/connect/.

When you create your App, make sure you specify the following as the Callback URL, https://YOUR_PORTAL_HOSTNAME/oauth2/callback.

Of course, replace the hostname with the values from general.hostname and general.domain.

OpenID connect have different ways to be configured, make sure to create a client ID and a client secret to work with PacketFence.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding an OpenID OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add OpenID as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Twilio, first create an account on https://www.twilio.com. From the console (dashboard) https://www.twilio.com/console create a 3rd Party Integration. Note the Account SID and Auth Token for later use. From the Phone Manager https://www.twilio.com/console/phone-numbers/incoming click the "+" button to Buy a number with SMS capability - no payment is needed to start using this phone number right away.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a Twilio OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Enter your 'Account SID', 'Auth Token' and 'Phone Number (From)' from above. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

Moreover, don’t forget to add Twilio as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

To use Windows live, you also need an API code and a secret key. To get one, you need to create an App here: .https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade When you create your App, make sure you specify the following as the Callback URL https://YOUR_PORTAL_HOSTNAME/oauth2/callback replacing the hostname with the values from general.hostname and general.domain.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a WindowsLive OAuth2 authentication source from Configuration → Policies and Access Control → Authentication Sources. Remember to add the Authentication Rules with at least two Actions (example: Role and Access duration).

The App ID in PacketFence will be Application (client) ID in the Azure portal.

The App secret must be a client secret created in the Certificates & secrets section of your app on Azure AD. Note that Azure AD secrets do expire so make sure you set a reminder to update your secret before it expires.

Moreover, don’t forget to add WindowsLive as a Source from your connection profile definition, available from Configuration → Policies and Access Control → Connection Profiles.

Open the PacketFence administration web interface and go to Configuration → Policies and Access Control → Authentication Sources.

First create RADIUS sources for each Eduroam servers you want to define.

To do that click New internal source and choose RADIUS.

Fill the Name, Description, Host, Port, Secret and disable Monitor. (The information to configure that source could be found on the Eduroam platform)

Next click on Exclusive Sources and click on New exclusive source then Eduroam.

Associate the Radius sources you previously configured in 'Eduroam RADIUS AUTH' section, define the radius listening port and keep the type to Keyed Balance.

In order to handle correctly external and internal students with your Eduroam source, you will need to:

Go to Configuration → Policies and Access Control → Connection Profiles → New Connection Profile.

Create a connection profile named External Eduroam authentication Check Automatically register devices then create a Realm filter eduroam. Make sure to add the previously created Eduroam source to match on the external users.

Go to Configuration → Policies and Access Control → Connection Profiles → New Connection Profile.

Create a connection profile named Local Eduroam authentication Check Automatically register devices then create a SSID filter Eduroam. Make sure to add the AD source to match on the local users.

First, you need to refer to the previous step Configure the Eduroam source.

For this use case, there is no need to create a connection profile in PacketFence. FreeRADIUS will only perform a NTLM Auth and won’t send RADIUS request to PacketFence API.

PacketFence supports SAML authentication in the captive portal in combination with another internal source to define the level of authorization of the user.

First, transfer the Identity Provider metadata on the PacketFence server. In this example, it will be under the path /usr/local/pf/conf/idp-metadata.xml.

Then, transfer the certificate and CA certificate of the Identity provider on the server. In this example, they will be under the paths /usr/local/pf/conf/ssl/idp.crt and /usr/local/pf/conf/ssl/idp-ca.crt. If it is a self-signed certificate, then you will be able to use it as the CA in the PacketFence configuration. Make sure -----BEGIN CERTIFICATE----- and -----END CERTIFICATE---- headers are present in these certificate files.

Then, to configure SAML in PacketFence, go in Configuration → Policies and Access Control → Sources and then create a new Internal source of the type SAML and configure it.

Where :

Once this is done, save the source and you will be able to download the Service Provider metadata for PacketFence using the link 'Download Service Provider metadata' on the page.

Configure your identity provider according to the generated metadata to complete the Trust between PacketFence and your Identity Provider.

In the case of SimpleSAMLPHP, the following configuration was used in metadata/saml20-sp-remote.php :

In order for your users to be able to access the Identity Provider login page, you will need to activate passthroughs and add the Identity Provider domain to the allowed passthroughs.

To do so, go in Configuration → Network Configuration → Networks → Fencing, then check Passthroughs and add the Identity Provider domain name to the Passthroughs list.

Next, restart iptables and pfdns services to apply your new passthroughs.

First select a billing provider and follow the instructions below.

Once you have configured one or more billing source, you need to define billing tiers which will define the price and target authentication rules for the user.

In the PacketFence administration interface, go in Configuration → Advanced Access Configuration → Billing tiers

Then click Add billing tier and configure it.

Where :

PacketFence supports subscription based billing using Stripe as a billing provider.

PacketFence allows users to extend their access before it has ended. In order to do so, you need to enable Allow access to registration portal when registered accessible via the Captive Portal tab of the Connection Profiles. Once this is activated, the users can reach https://YOUR_PORTAL_IP/status and select Extend your access in order to be able to access the billing section after they have registered.

This should provide the information about whether or not the username/password combination is valid

These information are available through the POST fields of the request

The server should reply with two attributes in a JSON response

Example JSON response :

This should provide the actions to apply on a user based on it’s attributes

The following attributes are available for the reply : access_duration, access_level, sponsor, unregdate, category.

Sample JSON response, note that not all attributes are necessary, only send back what you need.

In PacketFence, you need to configure an HTTP source in order to use an external API.

Here is a brief description of the fields :

Currently, PacketFence requires that multi-factor authentication be disabled for the PacketFence app. If you use Azure AD premium, you can create a rule to exclude this only for the PacketFence application. If you don’t use Azure AD premium, this must be disabled for all your users.

With this configuration, you can now use this source in your connection profiles to authenticate and authorize users on the captive portal and use it with EAP-TLS to authorize users (getting the role and access duration) as long as your EAP-TLS certificates use the distinguished name of the Azure AD users as their common name. Additionally, you can use this source for authenticating users in the admin interface and for VPN access.

First, head to 'Configuration→System Configuration→Admin Login' and set 'SSO Status' to enabled. If you want to enforce the usage of your SSO policy for login (i.e. disable the username/password), you should disable 'Allow username/password authentication' in this page.

Optionally, you may need to configure the 'SSO Base URL' if your PacketFence captive portal must be accessed under a different named than what is defined in the 'Hostname' and 'Domain' values that are in 'General Configuration'.

Next, you will need to configure a connnection profile for authenticating administrators. Go in 'Configuration→Policies and Access Control→Connection Profiles' and create a new connection profile with these values:

After this, restart api-frontend and httpd.portal and when accessing the admin interface login page, you should see a new option named 'Single Sign On'. This text can be changed in the 'Admin Login' configuration section.

Any authentication mechanism that can be used on the portal (SAML, Akamai MFA, TOTP, etc) can be used for authenticating administrators using this process. Refer to the appropriate section for each feature in this guide in order to configure them on your connection profile used for authenticating administrators.

Depending on your needs, you may want to adjust the configuration of the policy on the captive portal when authenticating administrators. The portal modules make this process highly flexible and customizable. You can modify the 'Default admin SSO policy' in 'Configuration→Advanced Access Configuration→Portal Modules' or create your own policy that you can then configure in your connection profile that authenticates administrators. Refer to the Portal Modules section of this documentation on how to customize the captive portal for your needs.

Provides the user a choice between multiple sources using advanced filtering rules, manual selection of the Sources and selection of the Portal Modules.

All the defined "Sources" and "Modules" are available for use. Mandatory fields can be defined in the module, but they will only be shown if applicable to the Source.

Dynamically select a Source from the Connection Profile based on an object attribute (Object Class, Authentication Type, Authentication Class).

Manually define specific roles when registering a device. This is useful for a technical crew to register new devices.

In Configuration → Advanced Access Configuration → Portal Modules, click "New Module" and select type "Other → Select Role". In "Admin Roles" chose the user role(s) that is required to use this module. In "Roles" choose the user role(s) that can then be assigned.

For example; technicians in the AD group technical support will have the role technical support while registering. In "Admin Roles" add technical support, then in "Roles" add default, voice and guest. Technicians that have the technical support role will be prompted to assign either the default, voice or guest role when registering a new device.

The on_failure and on_success "Actions" allow the creation of a more complex workflow and permit the root portal module change based on the result of authentication.

Consider that a root portal module is linked to an Authentication::Login module and associated with a Connection Profile. In order to present a Guest authentication if the login failed, configure a New Root Module called "Guest portal policy" with the "Module" set to Authentication::SMS, and in the previous "Authentication::Login" module add the "Action" on_failure ⇒ Guest portal policy.

To automatically create the database tables required by the Survey, the MySQL pf user must be granted the CREATE and ALTER privileges. The MySQL root user must be used to GRANT these privileges.

Access the MYSQL CLI as the root user:

From the MySQL CLI grant the privileges:

Configure the survey in /usr/local/pf/conf/survey.conf. Here is an example of a survey:

The Captive Portal will now collect some data from the user (ex: survey1 field firstname) and some data contextually (ex: survey1 data ssid).

The available parameters to collect user data are defined as:

The available parameters to use contextual data are defined as:

In Configuration → Advanced Access Configuration → Portal Modules, click "New Module" and select type "Other → Survey". Use the following setting then click Create:

Add the survey to an existing Portal Module (Choice, Chained or Root) or create a New Root Module dedicated for the survey:

In "Policies and Access Control → Connection Profiles → Name of the profile", ensure the correct "Root Portal Module" is selected.

The data collected from the example survey is stored in the survey_survey1 database table. Create a Report for the survey in /usr/local/pf/conf/report.conf and add the following parameters:

Refer to the Reports section of this document for advanced configuration.

Once configured, optionally for security, it is recommended to revoke the CREATE and ALTER privileges from the pf user. The MySQL root user must be used to REVOKE these privileges.

Access the MYSQL CLI as the root user:

From the MySQL CLI revoke the privileges:

In Configuration → Network Configuration → Networks → Fencing → Passthroughs, add passthroughs with the format:

When pfdns receives a DNS request for a passthrough domain it will forward the unaltered DNS record for the FQDN instead of a response for the Captive Portal. An ipset entry will be added to permit the device to access the real external IP address for the FQDN via iptables routing.

In Configuration → Network Configuration → Networks → Fencing, add a comma-separated list of FQDNs in "Proxy Passthroughs", including wildcard domains like *.example.com. Only TCP port 80 is used, so do not specify ports. Click Save.

When pfdns receives a DNS request it will respond with the IP address of the Captive Portal, and when the device makes a HTTP request on the Captive Portal for a FQDN that has a configured passthrough the request is forwarded through mod_proxy.

In Configuration → Compliance → Security Events, choose Security Event 1300003, configure how the event is handled when a device is parked:

Match machine authentication on secure wireless ssid:

Match machine authentication from a previous connection and is connected on a secure ssid:

Match user authentication and machine authentication on a secure ssid:

Match user authentication without machine authentication on a secure ssid:

Match without machine authentication (BYOD):

Example of attributes that can be filtered:

PacketFence uses Apache for its captive portal, administration interface and Web services. The PacketFence Apache configuration is located in /usr/local/pf/conf/httpd.conf.d/.

These files are dynamically generated with Perl and services are only activated on the network interfaces needed for each purpose.

The other files in this directory are managed by PacketFence using templates, so it is easy to modify these files based on the configuration. SSL is enabled by default to secure access.

During installation self-signed certificates will be created in /usr/local/pf/conf/ssl/ (server.key and server.crt). The certificates can be replaced anytime by either a 3rd-party or existing wildcard certificate without issue. Please note that the CN (Common Name) needs to be the same as the one defined in the PacketFence configuration file /usr/local/pf/conf/pf.conf.

In certain circumstances - for example to show an AUP after a successful 802.1X connection - "SSO emulation" may be used so that the user does not need to re-enter their credentials on the portal after having entered them during 802.1X EAP. The connection profile option 'Reuse 802.1X credentials' can be enabled for this purpose. The username used during the 802.1X connection will be reused with the different authentication sources to recompute the role from the portal.

As a security precaution, this option will only reuse 802.1X credentials if there is an authentication source matching the provided realm. This means, if users use 802.1X credentials with a domain part (username@domain, domain\username), the domain part needs to be configured as a realm under the RADIUS section and an authentication source needs to be configured for that realm. If users do not use 802.1X credentials with a domain part, only the NULL realm will be matched IF an authentication source is configured for it.

Upper case string.

Example:

assigns the upper case value of Calling-Station-Id to PacketFence-UserName.

Lower case string.

Example:

assigns the lower case value of User-Nam to PacketFence-UserName.

Join strings.

Example:

assign the joined string of the values and separator to PacketFence-UserName.

A part of a string.

Example:

assigns the first 6 characters of a string to PacketFence-UserName.

EUI48 format of a MAC address.

Example:

assigns the EUI48 MAC address to PacketFence-UserName.

A random integer between a range.

Example:

assigns a random integer between 10620 and 12600 to Session-Timeout.

Log a message in packetfence.log.

Example:

logs the value of the RADIUS request attribute User-Name appended with " logged".

Replace a string or character.

Example:

replace the character "z" by the character "r" from User-Name and assign it to PacketFence-UserName.

Regular expression match on a string or character.

Example:

extract the value from TLS-Client-Cert-Common-Name before the @ sign and assign it to TLS-Stripped-UserName.

LDAPfilter actions override the internal LDAP filter that PacketFence creates internally (uid=$username) so a custom filter can be created that matches specific needs.

Example user search that checks permission based on some criteria:

set_role_on_not_found defines a role if the rule does not match.

Adding the action set_role_on_not_found = REJECT will reject the device if the LDAP filter match returns empty. On the other hand, if a filter match is found then the set_role action is applied.

role_from_source checks if the LDAP attribute exists, if so it is added in the ldap_attribute context (available in the RADIUS filters).

Example that takes the LDAP attribute customRadius value and adds it in the RADIUS answer. In the authentication rule add an action "Role from source" to customRadius. Next create a RADIUS filter that will add the custom RADIUS attributes:

This option will add an AND condition (&) to the LDAP filter generated by PacketFence.

Example of an LDAP filter that is generated by PacketFence:

If an LDAP filter is manually defined as:

The filter will be combined and generated as:

If the "Search Attributes" feature is not required, this will still store the users' DN in the PacketFence-UserDN attribute.

This condition overrides the default basedn in the LDAP source and will test if an object is in a specific OU.

If you send the IP address of nodes in accounting data and want to update iplog entries of your nodes, you can enable 'Update the iplog using the accounting' setting from Configuration → System configuration → Main configuration → Advanced.

Using PacketFence, it is possible to add security events to limit bandwidth abuse. The format of the trigger is very simple:

Let’s explain each chunk properly:

In this section we will explain how to proxy RADIUS requests based on an advanced criteria.

First you have to create RADIUS authentication source like above and create for example two realms "to_NPS" and "to_ISE" (associate the RADIUS sources in the REALMs)

Next you have to enable the RADIUS filters in the packetfence.authorize and packetfence.post-proxy scope, to do that you have to go in _Configuration → System Configuration → RADIUS → General , and enable "Use RADIUS filters in packetfence authorize" and "Use RADIUS filters in packetfence post-proxy".

After this step restart the packetfence-radiusd-auth service (systemctl restart packetfence-radiusd-auth.service).

Here are some examples of what you can do with the RADIUS filters (the content of the radius_filters.conf file):

Proxy the RADIUS request to the to_NPS realm if the Calling-Station-Id or Colubris-AVPair attribute matches the regex ACME$

Proxy the RADIUS request the to_ISE realm if the Calling-Station-Id or Colubris-AVPair attribute contains ACME_Admin$ and add the attribute Realm with the value to_ISE in the RADIUS request (can be for example used as a filter in a connection profile)

Proxy the RADIUS request to the NULL realm if the Calling-Station-Id or Colubris-AVPair attribute matches the regex Guest$

Proxy the RADIUS request to the to_ISE realm if the Calling-Station-Id attribute matches the regex ACME$

Proxy the RADIUS request to the to_ISE realm if the device role is Employe and the status is registered

The easiest method for performing this detection is to trigger on any device class change which will trigger the security event whenever the device is detected transitioning from any device class to another. Since some of these transitions may be normal in your environment, you can add whitelisting of transitions via the "Device class change whitelist" parameter which allows you to list valid transitions (ex: "Windows OS" to "Mac OS X or macOS").

Instead of detecting all transitions, you can perform detection and security event triggering on specific device class transitions. In order to do so, declare all the transitions that should trigger the security event in the "Manual device class change triggers".

To create the syslog regex parser you will need to go to Configuration → Integration → Event Handlers → Add a Event Handler → regex

Here is the configuration of the syslog regex parser:

Save the regex rule.

You can directly test your rule. In the previous example the parser expect a syslog string like this:

In order to have a correct match in the rule, you will need to have a valid iplog entry in the database. Put the string in the test box and then click on the RUN TEST button, you should get:

We can see that PacketFence will execute the security event on the MAC address 00:11:22:33:44:55.

Now you will need to create the security event with the trigger id '2000340' in order to isolate the device. In order to do so, go to Configuration → Compliance → Security Events → New Security Event

Definition:

Triggers:

Remediation:

Click on the SAVE button.

Now you will need to restart the pfqueue and the pfdetect services.

Make sure that you have your pipe file otherwise the process won’t start.

Security Onion is a Ubuntu-based security suite. The latest installation instructions are available directly from the Security Onion website, https://github.com/Security-Onion-Solutions/security-onion/wiki/Installation

Since a security suite consists of multiple pieces of software tied together, you may be prompted for different options during the installation process. A detailed "Production Deployment" guide can also be found directly from the Security Onion website: https://github.com/Security-Onion-Solutions/security-onion/wiki/ProductionDeployment

Once Security Onion is installed and minimally configured, integration with PacketFence is required to be able to raise security events based on sensor(s) alerts. syslog is used to forward sensor(s) alerts from Security Onion to the PacketFence detection mechanisms.

The simplest way is as follow (based on https://github.com/Security-Onion-Solutions/security-onion/wiki/ThirdPartyIntegration);

On the Security Onion server:

Configure /etc/syslog-ng/syslog-ng.conf by adding the following to enable sending sguild log entries to PacketFence:

Sending sguild alert output to syslog requires DEBUG to be changed from 1 to 2 under /etc/sguild/sguild.conf

A restart of the sguild daemon is then required

A restart of the syslog-ng daemon is then required

On the PacketFence server:

Modify rsyslog configuration to allow incoming UDP packets by uncommenting the following two lines in /etc/rsyslog.conf:

Configure /etc/rsyslog.d/securityonion_ids.conf so it contains the following which will redirect Security Onion sguild log entries and stop further processing of current matched message:

Make sure the receiving alert pipe (FIFO) exists

Restart the rsyslog daemon

At this point, Security Onion should be able to send detected alerts log entries to PacketFence.

A configuration of a new 'syslog parser' as well as some security events are the only remaining steps to make full usage of the Security Onion IDS integration.

Configuration of a new 'syslog parser' should use the followings:

Configuration of a new security event can use the following trigger types:

First we need to modify the Suricata configuration to output the alerts into a fast.log file.

Locate the outputs section and modify the fast options as follow:

Reload the configuration on all minions with (it will take few minutes to apply):

You can verify the configuration done under:

If you want to disable some rules in suricata, you can use so-rule:

You can also check this video to understand how to manage suricata rules:

Now we need to send the alerts from the /nsm/fast.log to PacketFence.

Replace the PACKETFENCE_MGMT_IP with your PacketFence management IP interface.

Restart Rsyslog:

On the PacketFence server:

Modify rsyslog configuration to allow incoming UDP packets by uncommenting the following two lines in /etc/rsyslog.conf:

Configure /etc/rsyslog.d/securityonion_ids.conf so it contains the following which will redirect Security Onion sguild log entries and stop further processing of current matched message:

Make sure the receiving alert pipe (FIFO) exists

Restart the rsyslog daemon

At this point, Security Onion should be able to send detected alerts log entries to PacketFence.

A configuration of a new 'syslog parser' as well as some security events are the only remaining steps to make full usage of the Security Onion IDS integration.

Configuration of a new 'syslog parser' should use the followings:

Configuration of a new security event can use the following trigger types:

Go to Configuration → Integration → Firewall SSO → Add Firewall → Barracuda.

For our example, when the user registers on the portal it will be registered and the role staff will be assigned. The PacketFence server will send a request to the Barracuda database.

If you want to see if it’s working, open an SSH access to your Barracuda and run this command following commands:

You will get that:

To enable Identity Awareness:

To enable RADIUS Accounting for a Security Gateway: 1. In the 'SmartDashboard Network Objects tree', open the Security Gateway. 2. On the 'General Properties' page, make sure that the Identity Awareness Blade is enabled. 3. On the 'Identity Awareness' page, select RADIUS Accounting.

Gateway interfaces must be authorized to accept connections from PacketFence RADIUS Accounting.

To select gateway interfaces: 1. In the 'RADIUS Client Access Permissions' section, click Edit. 2. Select 'All Interfaces - All Security Gateway interfaces can accept connections from RADIUS Accounting clients'. 3. Leave the default port to 1813. 4. Click OK on both windows to submit the configuration. 5. Select 'Policy' > 'Install' from the SmartDashboard menu.

Make sure that you have the correct LDAP Objects created on the Checkpoint.

Go to *'Configuration' → 'Firewall SSO' → 'Add Firewall' → 'Checkpoint' *.

You can check the correct log in with the SmartView Tracker under 'Network & Endpoint Queries' → 'Predefined' → 'Identity Awareness Blade' → 'Login Activity'

First, attach ISE-PIC to Active Directory and set it up as an Identity Provider as described here: https://www.cisco.com/c/en/us/td/docs/security/ise/2-6/pic_admin_guide/PIC_admin26/PIC_admin26_chapter_010.html

Add a new Template and call it PacketFence. Make it match the following:

To add PacketFence as an identity provider, hover over "Providers" and click "Syslog Providers.", then click "Add".

Then add each of your PacketFence servers as Syslog providers using the syslog template you created above. In the case of a cluster, add each member management IP and the management virtual IP.

Make sure your syslog header configuration matches this:

Add a Cisco ISE-PIC firewall SSO entry in "Configuration→Integration→Firewall SSO"

You should then see User Sessions populating under “Live Logs” in ISE-PIC. The source should say "syslog"

Go to your FortiGate administration webpage in User & Device → User → User Groups → Create New.

You can also see that in the webpage at User & Device → Monitor → Firewall

The default endpoint attribute is the Calling-Station-Id so the MAC address shows up under User Name, we can change that in CLI:

Go to System → Network → Interfaces.

Select the interface that will communicate with PacketFence and check 'Listen for RADIUS Accounting Messages' then confirm.

Go to Configuration → Integration → Firewall SSO → Add Firewall → FortiGate.

If you want to see if it’s working, you can log into the firewall over SSH and run these following commands:

The JSONRPC module shipped with PacketFence is meant as a generic firewall SSO module to be used with Linux or BSD firewalls that do not by default ship with a vendor-specific interface to do SSO with.

A compatible server must implement the methods Start and Stop, both with the identical set of parameters provided below.

A simple JSON-RPC server written in Python that is compatible with this specification and creates ipsets based on the SSO information provided by PacketFence can be found at https://github.com/tribut/ipset-rpcd.

Go to 'Configuration' → 'Integration' → 'Firewall SSO' → 'Add Firewall' → 'JSONRPC'.

Go to Configuration → Integration → Firewall SSO → Add Firewall → JuniperSRX.

You need to setup webapi management as follows

Next setup user entry settings

Then you need to allow traffic from the PacketFence management interface to port you set up on webapi settings (i.e. 8443) on SRX device.

For debuging the webapi set (disable it when you won’t need it anymore):

To check registered device entries on SRX use

or

to see more details about OS, device type etc.

Please visit https://www.tenable.com/downloads/nessus to download Nessus v7 and install the Nessus package for your operating system. You will also need to register for the HomeFeed (or the ProfessionalFeed) in order to get the plugins.

After you installed Nessus, follow the Nessus documentation for the configuration of the Nessus Server, and to create a user for PacketFence.