This setup has been tested using VMware ESXi, Fusion and Workstation products with 12 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).

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 version of VMware Player handles the VLAN trunking a lot better. Having that said, 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.

Install kernel development package:

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 'Add source→External→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 'Save' 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 'Add source→External→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 'Save' 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 of it. 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 one 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→Interfaces'. 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 → Interfaces' 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 'Add 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.

It’s possible to enable traffic shaping based on the role of the device. In order to enable it you need to go in 'Configuration → Network Configuration → Inline Traffic Shaping' and select the role you want to define a limit. Set a upload and download speed limit and save.

Next restart the tc service to apply the new rules.

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 and Pages'.

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 (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 and Pages'.

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 and Pages'.

To use Instagram, you also need an API code and a secret key. To get one, go here: https://www.instagram.com/developer/clients/manage/. 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.

Once you have your information, you need to configure the OAuth2 provider. This can be done by adding a Instagram 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 Instagram as a Source from your connection profile definition, available from 'Configuration → Policies and Access Control → Connection Profiles and Pages'.

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 and Pages'.

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

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 and Pages'.

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 and Pages'.

To use Pinterest, you also need an API code and a secret key. To get one, go here: https://developers.pinterest.com/apps. When you create your App, make sure you specify the following as the Redirect 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 Pinterest 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 Pinterest as a 'Source' from your connection profile definition, available from 'Configuration → Policies and Access Control → Connection Profiles and Pages'.

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 and Pages'.

To use Twitter, you also need an API code and a secret key which Twitter calls consumer key and consumer secret. Obtain this information by creating an new application from your Twitter Apps Management page. 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 Twitter 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 Twitter as a 'Source' from your connection profile definition, available from 'Configuration → Policies and Access Control → Connection Profiles and Pages'.

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://account.live.com/developers/applications. 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, and check 'Live SDK support'.

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

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

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

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

The information to configure that source could be found on the Eduroam platform.

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

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

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

Once the source is configured, you will need to create a new connection profile.

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

Create the Connection Profile named External Eduroam authentication Check Automatically register devices then create a REALM filter Eduroam. Next, make sure to add the Eduroam source previouly created.

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 'Passthrough' and add the Identity Provider domain name to the 'Passhtroughs' list.

Next, restart iptables and pfdns 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 :

This section will contain the following examples:

The Authentication Choice module allows to define a choice between multiple sources using advanced filtering rules, manual selection of the sources and selection of Portal Modules.

All the sources that are defined in the 'Sources' field will be available for usage by the user. Same goes for the modules defined in 'Modules'.

You can also define which mandatory fields you want to prompt for these authentication choices. Although you can still configure them on any 'Authentication Choice' module, they will only be shown if they are applicable to the source.

In addition to the manual selection above you can dynamically select sources part of the Connection Profile based on their object attribute (Object Class, Authentication type, Authentication Class).

You can see the 'default_guest_policy' and 'default_oauth_policy' for examples of this module.

The SelectRole module allows to define specific roles manually when registering a device. This is useful if for instance you ask your technical crew to register new devices.

The configuration is simple, you have a role which is the 'Admin role' the one allowed to select the role while registering a new device and the 'Role List' which is the list of roles that can be chosen from while registering a device.

For instance; techs are in the AD group tech support and get the role 'tech support' while registering, let’s put 'tech support' as the 'Admin role'. They are allowed to register new devices with the roles 'default', 'voice' and 'guest'. Every time someone with the role 'tech support' will try to register a device on a connection profile where this portal module is active, then the crew memeber will be asked to choose which role to assign to this device.

The on_failure and on_success actions allow you to create a more complex workflow and will permit to change the root portal module based on the result of the authentication. Let’s say you have a root portal module linked to a Authentication::Login module associated to a connection profile and you want to present a Guest authentication if the login failed. Then you need to configure another root portal module "Guest" linked with a Authentication::SMS module and in the previous Authentication::Login add and action on_failure ⇒ Guest.

In order for the survey tables to be created automatically based on the definition of your surveys, you must grant create and alter rights to the database user defined in pf.conf. By default this user is 'pf'. On your database, connect to the MariaDB CLI as root and execute the following:

Next, you will have to configure your survey in /usr/local/pf/conf/survey.conf. Here is an example of a survey:

In the example above, some of the data is being collected via fields on the captive portal directly (ex: survey1 field firstname) and some are collected via contextual data (ex: survey1 data ssid).

Fields are defined the following way:

Data fields are defined using a query and has access to node and person informations. Here are a few examples:

In order for your survey to be available on the portal, you will have to configure a portal module for it. In order to do so, go in 'Configuration→Advanced Access Configuration→Portal Modules' and create a new Survey portal module with the following settings:

Then either add your survey to another portal module (Choice, Chained or Root) or create a Root portal module dedicated to the survey:

Once that is configured, make sure you have the right Root portal module on the applicable connection profile in 'Policies and Access Control→Connection Profiles→Name of the profile→Root Portal Module'.

All the data that is collected in the example survey will be stored in a table named survey_survey1. You can create 'Dynamic Reports' on your survey tables via /usr/local/pf/conf/report.conf. Here is an example for the survey created above:

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

When you are happy with the structure of your surveys, it is recommended to remove the CREATE and ALTER rights to the pf database user from a security perspective. In order to do so, execute the following commands. This step is optional and should only be done once the structure of your survey is set in stone.

If you just enabled the passthroughs, you should restart the iptables services after configuring the parameter (/usr/local/pf/bin/pfcmd service iptables restart).

Then add passthroughs in Configuration→Network Configuration→Networks→Fencing→Passthroughs. They can be of the following format:

In addition to the options above, you can prefix the domain with . (.example.com) to white list all the subdomains of example.com (ex: www.example.com, my.example.com).

Should you combine multiple times the same domain with different ports (example.com,example.com:udp:1812,example.com:udp:1813) in the passthroughs, it will open all ports specified in all entries. In the previous example that would open ports 80, 443 in TCP as well as 1812 and 1813 in UDP.

Now when pfdns receives a request for one of these domains, it will reply with the real DNS records for the FQDN instead of a response that points to the captive portal. At the same time, it will add the entry to a special ipset which will allow access to the real IP address attached the FQDN via iptables based routing.

The proxy passthroughs can be configured in Configuration→Network Configuration→Networks→Fencing→Proxy Passthroughs. Add a new FQDN (can also be a wildcard domain like *.google.com). Port specific passthroughs cannot be used as these only apply to port 80 in TCP. Then for this FQDN, pfdns will still answer with the IP address of the captive portal and when a device hits the captive portal, PacketFence will detect that this FQDN has a passthrough configured in PacketFence and will forward the traffic to mod_proxy.

This security event controls what happens when a user is detected doing parking.

Here are the main settings:

Under certain circumstances, for example to show an AUP after a successful 802.1X connection, it might be interesting to have the ability to use an "SSO emulation" in the sense that the user does not need to re-enter his credentials on the portal after having entered them during the 802.1X EAP process. The 'Reuse 802.1X credentials' connection profile option will address this purpose. The same username as the one used during the 802.1X connection will be used against the different connection profile 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 match IF an authentication source is configured for it.

ldapfilter action overrides the internal LDAP filter that PacketFence creates internally (uid=$username) so you can create a custom filter that matches your needs.

For example something like this (search for the user and check to see if it’s permitted based on some criteria):

set_role_on_not_found is a way to define a role if the rule doesn’t match, let’s take the ldapfilter example above.

If we add the action set_role_on_not_found = REJECT so it mean that the device will be rejected if the LDAP filter doesn’t return anything. (if it matches then set_role action will be applied)

role_from_source will check to see if the LDAP attribute exists and will add it in the ldap_attribute context (available in the radius filters)

So for example if you want to take the value of the LDAP attribute customRadius and add it in the RADIUS answer you need to do the following.

In the authentication rule, set an action "Role from source" to customRadius. Next create a RADIUS filter that will add the custom RADIUS attributes:

Note, this supports multiples LDAP attributes, like customRadius:Airespace-Interface-Name=internet , customRadius:Aruba-User-Vlan=666

This option will add as a & condition to the LDAP filter generated by PacketFence, So for example the ldapfilter generated by PacketFence will be the following:

and if you define a appended LDAP filter like:

Then the filter will be generated like that:

By doing that, event if you wont don’t need the "Search Attributes" feature, you will be able to store the user’s DN in the PacketFence-UserDN attribute.

This condition allow to override the default basedn in the LDAP source and it will permit to test if a 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 '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:

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 → Syslog Parsers → Add a Syslog Parser → 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:

To create the syslog regex parser you will need to go to Configuration → Integration → Syslog Parsers → Add a Syslog Parser → 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.

You will need to create a rsyslog configuration to forward all the syslog messages sent by StreamScan to the pipe file /usr/local/pf/var/cds

First you need to enable the syslog under the rsyslog configuration file located at /etc/rsyslog.conf, uncomment the two parameters:

Then create the forwarding configuration:

Put the follow configuration in it where the IP 1.2.3.4 is your syslog source server:

Restart rsyslog to apply the configuration

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.

You just have to enable WMI on each Microsoft Windows devices with a GPO from Active Directory.

First go in Configuration and Scanner Definition: Configuration → Compliance → Scan Engines

Then add a scan engine

There are common parameters for each scan engines:

Specific to Nessus:

Specific to OpenVAS:

Specific to WMI:

If you have configured a WMI scan engine then you need to define WMI Rules. WMI is a sort of database on each windows devices, to retrieve information on the device you need to know the SQL request. In order to help you to find and make a rule you can use a third party tool like WMI Explorer.

Some example rules are defined in /usr/local/pf/conf/wmi.conf.example with their description. You can browse these rules in Configuration → Compliance → WMI Rules.

It is possible to have the result of a WMI scan in the node section. To have this, go into the rule configuration and check the box On Node tab. Now configure your WMI scanner as you would usually do and you will be able to have the results in the tab WMI Rules under Node.

You need to create a new security event section and have to specify:

Using Nessus:

Using OpenVAS:

Where security event ID is either the ID of the Nessus plugin or the OID of the OpenVAS plugin to check for. Once you have finished the configuration, you need to reload the security event related database contents using:

The last step is to assign one or more scanner you configured to one or more connection profiles. Go in Configuration → Policies and Access Control → Connection Profiles → Edit a Profile → Add Scan

PacketFence also supports integration with the syslog forwarding of Rapid7 (with or without the scan engine integration) in order to receive vulnerability alerts from Rapid7.

First of all, you need to configure the SSID that your devices will use after they go through the authentication process.

In the administration interface, go in 'Configuration → Advanced Access Configuration → Provisioners'. Then select 'android' / 'ios' / 'Windows' provisioner. Enter the SSID information and roles for which the provisioner applies. Repeat for all desired provisioners. Note that the default RADIUS certificate path is /usr/local/pf/raddb/certs/server.crt.

After, you simply need to add the 'Android', 'iOS' and 'Windows' provisioners to your 'Connection Profile' configuration. If no connection profile is defined, configure the 'default' connection profile to use the provisioners created.

To add a new provisioner for another class of devices to be supported, click on the 'Add Provisioner' button, and fill out the form, choosing a different Provisioning ID per provisioner.

We also advise you to configure a SSID for provisioning, for instance: OnBoarding-PF, open with MAC Authentication, pointing to PacketFence. Create a new Portal Profile, add a filter SSID with this SSID name, add the source you want the users to authenticate from and add your provisioners to this Portal Profile. From there, users who logged in will have to follow the captive portal instruction to get provided their certificate.

Upon registration, instead of showing the default release page, the user will be showing another version of the page saying that the wireless profile has been generated with a clickable link on it. To install the profile, Apple user owner simply need to click on that link, and follow the instructions on their device. Android user owner simply click to the link and will be forwarded to Google Play to install PacketFence agent. Simply launch the application and click to configure will create the secure SSID profile. It is that simple.

First of all you will need to configure the basic functionality of MobileIron using their documentation.

Next, we will need a user that has the rights to access the MobileIron API in order to verify the state of the devices directly from PacketFence.

First go in the 'USERS & DEVICES' tab and then in 'Users' and click 'Add local user'.

Now enter the information about your user and note the user ID and password for usage in the PacketFence configuration, then hit 'Save'.

Now go in the 'ADMIN' tab, check the box next to your newly created user and then in 'Actions' select 'Assign to Space'.

Select the Global space at the top and then check API at the bottom. You should now see API in the roles list of your newly created user when viewing the users list.

To find the boarding host, add a fake device to MobileIron and at the end of the process you will see the registration instructions.

In it you will find the boarding host and port for the PacketFence configuration. In this case, the boarding host is m.mobileiron.net and the boarding port is 50291.

In PacketFence, MDM are referred to as provisioners. This will walk you through adding MobileIron as a provisioner.

Next, still in the PacketFence administration console, go in 'Fencing' in the left menu, then scroll then to 'Passthroughs'.

Check the 'Passthrough' box above the field and add the following domains to the passthrough list.

You can now test that MobileIron is mandatory after the device registration. Connect a device to your test network and register like you normally would. At the end of the registration process you will be presented a page asking you to install the MobileIron on your device. After you install the agent click 'Continue'. If your access is enabled than this means the connectivity between PacketFence and MobileIron is good.

You will first need to create an OPSWAT Metadefender Endpoint account at https://www.opswat.com/products/metadefender/endpoint/management/ and configure your account according to OPSWAT’s documentation.

Now that you have basic functionality for your OPSWAT Metadefender Endpoint account, you will need to create a Metadefender Endpoint developer account so PacketFence can access the OPSWAT Metadefender Endpoint API. You can do this here https://gears.opswat.com/developers.

From your OPSWAT Metadefender Endpoint console, click '+Devices' at the top. Then click on Enable 'Metadefender Endpoint client on another device'.

Then click 'Download or send link for guest Metadefender Endpoint clients'

Then note the URL at the bottom of the screen.

In order to configure OPSWAT Metadefender Endpoint in PacketFence you will need to generate an OAuth2 access and refresh token so PacketFence can access the OPSWAT Metadefender Endpoint API.

Next, still in the PacketFence administration console, go in 'Fencing' in the left menu, then scroll then to 'Passthroughs'. Check the 'Passthrough' box above the field and add the following domains to the passthrough list.

You can now test that the installation of the OPSWAT Metadefender Endpoint client is mandatory after the device registration. Connect a device to your test network and register like you normally would. At the end of the registration process you will be presented a page asking you to install the OPSWAT Metadefender Endpoint client on your device. After you install the client click continue. If your access is enabled than this means the connectivity between PacketFence and OPSWAT Metadefender Endpoint is good.

PacketFence polls the OPSWAT Metadefender Endpoint API in order to trigger security events on noncompliant devices.

PacketFence uses the number of critical issues the device has to determine whether or not it needs to isolate it.

You will first need to download the SentinelOne agents in order to host them on the PacketFence server.

In order to do so, in your SentinelOne management console, go in 'Settings→Updates', then download the Windows and Mac OSX agents on your computer. Once they have been download transfer them on your PacketFence server using SCP. This example will use /usr/local/pf/html/common/SentinelOne.exe as the Windows agent path and /usr/local/pf/html/common/SentinelOne.pkg as the Mac OSX agent path.

PacketFence will need a user on your SentinelOne instance in order to access the SentinelOne API. To create it, go in 'Settings→Users' and create a new user. Make sure, you note the password you put here for configuration in PacketFence.

You can now test that the installation of the SentinelOne client is mandatory after the device registration. Connect a device to your test network and register like you normally would. At the end of the registration process you will be presented a page asking you to install the SentinelOne client on your device. After you install the client click continue. If your access is enabled then this means the connectivity between PacketFence and SentinelOne is good.

PacketFence polls SentinelOne at a regular interval (30 seconds by default) to find devices that have uninstalled their agent. When it detects them as uninstalled, it automatically brings the device back to the portal so the agent is installed.

Everytime your device connects to PacketFence using RADIUS, it schedules a provisioning check to occur 2 minutes after the connection (controlled via security event 1300002). If the agent is inactive on the device or was uninstalled, PacketFence will bring the device back to the portal so the agent is installed again or brought back to an active state.

Configure the necessary policies in your SEPM before the creation of the install package. This document does not cover the policy and group configuration. Please refer to Symantec’s documentation for more information. This document will use the default policies and the default group for the package creation.

Login in your SEPM console and then go in the 'Clients' tab on the left. Select the group your clients should belong and then click 'Add a client'.

The wizard for the package creation will open. On the first page, make sure 'New Package Deployment' is selected and click 'Next'.

Now on this page, make sure you are creating the package for Windows. Then select the content options you prefer and click 'Next'.

Now on this page, select 'Save Package' and click 'Next'.

Now you will need to select the export location of your new packages. Select any location you prefer. This guide will use C:\temp\. Once you are done, click 'Next'.

On the next page, confirm the settings and click 'Next'.

Once the package is created go in the directory where you created the package and navigate your way to the 32 bit package. Then using an SCP or any other method, upload this file to /usr/local/pf/html/captive-portal/content/sep.exe on your PacketFence server. Do the same thing for the 64 bit package by uploading it to /usr/local/pf/html/captive-portal/content/sep64.exe.

In order to configure the SEPM in PacketFence you will need to generate an OAuth2 access and refresh token so PacketFence can access the SEPM API.

You can now test that the installation of the Symantec Endpoint Protection client is mandatory after the device registration.

Connect a device to your test network and register like you normally would.

At the end of the registration process you will be presented a page asking you to install the Symantec Endpoint Protection client on your device.

After you install the client click 'Continue'. If your access is enabled than this means the connectivity between PacketFence and the Symantec Endpoint Protection Manager is working.

You will first need to connect to the Azure portal and be sure that you have the Intune licenses.

You can now test that the installation of the Microsoft Intune client is mandatory after the device registration. Connect a device to your test network and register like you normally would. At the end of the registration process, you will be presented a page asking you to install the Intune client on your device. After you install the client click continue. If your access is enabled then this means the connectivity between PacketFence and Azure is good.

You will need to create a new certificate authority. Go to the PacketFence web administration under the section Configuration → Integration → PKI → Certificate Authorities and click on New Certificate Authority

Now you will need to create a certificate template that will gather all the settings for your certificate like the validity period or the certificate usage.

The PacketFence PKI hand out PKCS12 certificates, if you want to convert your certificate to PEM format, you can use the commands:

If you revoke a certificate it can’t be recovered and you would need to recreate a new one. You will need to specify a reason of the revokation.

You can hand out certificate to non-BYOD device on a captive portal.

First, you would need to create the PKI provider that will query the PacketFence PKI for new certifcate. Go to Configuration → Advanced Access Configuration → PKI provider

In our example, that gave the following output: