PF11.2 - Unable to get access to logon page for /Status /Device-Registration

[RHDHV-simon-sutcliffe]

Describe the bug With the new PF 11.2 update we are no longer able to get to the login window for the management portals. /status /Device-Registration

This is when a device is also registered in the DB

To Reproduce Steps to reproduce the behavior:

1. Navigate to https://{packetfence-URL}/status
2. See error

Logging Feb 25 10:58:38 packetfence packetfence_httpd.portal[45936]: httpd.portal(45936) WARN: [mac:unknown] Unable to match MAC address to IP '10.251.40.173' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[45936]: httpd.portal(45936) WARN: [mac:unknown] Unable to match MAC address to IP '10.251.56.15' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[45936]: httpd.portal(45936) WARN: [mac:0] Unable to match MAC address to IP '10.251.40.173' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[45936]: httpd.portal(45936) WARN: [mac:0] Unable to match MAC address to IP '10.251.56.15' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence pfqueue[46256]: pfqueue(46256) ERROR: [mac:unknown] Unable to fetch query arguments for Fingerbank query. Aborting. (pf::fingerbank::process) Feb 25 10:58:38 packetfence packetfence_httpd.portal[46516]: httpd.portal(46516) WARN: [mac:unknown] Unable to match MAC address to IP '10.251.40.173' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[46516]: httpd.portal(46516) WARN: [mac:unknown] Unable to match MAC address to IP '10.251.56.15' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[46516]: httpd.portal(46516) WARN: [mac:0] Unable to match MAC address to IP '10.251.40.173' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence packetfence_httpd.portal[46516]: httpd.portal(46516) WARN: [mac:0] Unable to match MAC address to IP '10.251.56.15' (pf::ip4log::ip2mac) Feb 25 10:58:38 packetfence pfqueue[45647]: pfqueue(45647) ERROR: [mac:unknown] Unable to fetch query arguments for Fingerbank query. Aborting. (pf::fingerbank::process)

Expected behavior Able to see the logon window.

Additional context This is with an update Debian 11.1 -> 11.2 + latest patch pull commit 871d7e61d210d7d1bcce2df11b3839d9c38fc027

[julsemaan]

I'll check that, it did pass in the 11.2 QA so it's surprising to see this regression in the release

[julsemaan]

I installed a fresh 11.2 and I was able to access both pages

Make sure you use the right domain name in your URL (defined in "System Configuration->General Configuration"), otherwise you get redirected to the captive portal because its not a registered domain name. You can add more domains/IPs to that list in "Advanced Access Configuration->Captive Portal->Other domain name"

[RHDHV-simon-sutcliffe]

@julsemaan Thanks for the input but both of these are correctly configured.

This is the redirected URL from the input https://nac-test.corporateroot.net/device-registration

Please be aware this works fine if we roll back the snapshot to 11.1 and stops working after the update to 11.2 So there is an issue somewhere in the new code base. Happy to pick this up on the user list but I do feel this is a bug and should not be closed quite yet.

[julsemaan]

Tried to replicate this once again and got the same result on 11.2 so I highly doubt it's a bug but let's see what we can find together

Can you post:

/usr/local/pf/conf/pf.conf
/usr/local/pf/conf/profiles.conf
/usr/local/pf/conf/self_service.conf

Please make sure you obfuscate the credentials and other private info in these files before posting

[RHDHV-simon-sutcliffe]

Good Morning @julsemaan Thanks for looking into this looking.

pf.conf

# Copyright (C) Inverse inc.
[general]
#
# general.domain
#
# Domain name of PacketFence system.
domain=corporateroot.net
#
# general.hostname
#
# Hostname of PacketFence system.  This is concatenated with the domain in Apache rewriting rules and therefore must be resolvable by clients.
hostname=nac-test
#
# general.timezone
#
# System's timezone in string format. List generated from Perl library DateTime::TimeZone
# When left empty, it will use the timezone of the server
timezone=Europe/Amsterdam

[guests_admin_registration]
#
# guests_admin_registration.access_duration_choices
#
# These are all the choices offered in the guest management interface as 
# possible access duration values for a given registration.
access_duration_choices=1h,3h,12h,1D,2D,3D,5D,7DR+1h

[alerting]
#
# alerting.emailaddr
#
# Comma-delimited list of email addresses to which notifications of rogue DHCP servers, security_events with an action of "email", or any other
# PacketFence-related message goes to.
emailaddr=sz1-301571-adm@corporateroot.net,sz1-905490-adm@corporateroot.net,sz1-906284-adm@corporateroot.net
#
# alerting.fromaddr
#
# Source email address for email notifications. Empty means root@<server-domain-name>.
fromaddr=packetfencetest@nac.corporateroot.net
#
# alerting.smtpserver
#
# Server through which to send messages to the above emailaddr.  The default is localhost - be sure you're running an SMTP 
# host locally if you don't change it!
smtpserver=smtp.sendgrid.net
#
# alerting.smtp_encryption
#
# Encryption style when connecting to the SMTP server.
smtp_encryption=starttls
#
# alerting.smtp_username
#
# The username used to connect to the SMTP server
smtp_username=apikey
#
# alerting.smtp_password
#
# The password used to connect to the SMTP server
smtp_password=xxxxxx

[database]
#
# database.pass
#
# Password for the mysql database used by PacketFence. Changing this parameter after the initial configuration will *not* change it in the database it self, only in the configuration.
pass=xxxxxx

[captive_portal]
#
# captive_portal.status_only_on_production
#
# If status_only_on_production is enabled, the /status page will only be available on the
# production network. This is disabled by default
status_only_on_production=enabled
#
# captive_portal.other_domain_names
#
# Other domain names under which the captive portal responds
other_domain_names=nac-test.corporateroot.net

[advanced]
# advanced.configurator
#
# Enable the Configurator and the Configurator API
configurator=disabled
# advanced.openid_attributes
#
# List of known OpenID Attributes
openid_attributes=

[webservices]
#
# webservices.user
#
# username to use to connect to the webAPI
user=WebService_SA
#
# webservices.pass
#
# password of the username
pass=xxxxxxx

[fingerbank_device_change]
# 
# fingerbank_device_change.enable
#
# Whether or not the Fingerbank device change feature is enabled
enable=enabled

[interface eth0.10]
type=management,portal
ip=10.202.1.126
mask=255.255.255.0

[interface eth0.191]
type=other,dns,dhcp,portal
mask=255.255.255.0
ip=10.202.5.250

profiles.conf

# Copyright (C) Inverse inc.
#
#
#
# See the enclosed file COPYING for license information (GPL).
# If you did not receive this file, see
# http://www.fsf.org/licensing/licenses/gpl.html
[default]
description=Wired
logo=/common/RHDHV.png
redirecturl=https://royalhaskoningdhv.com
dot1x_recompute_role_from_portal=disabled
mac_auth_recompute_role_from_portal=enabled
sources=RHDHV-Guest

[EAP-TLS]
advanced_filter=
sources=corporateroot-TLS
description=All EAP-TLS Connections
filter=connection_sub_type:EAP-TLS
locale=
autoregister=enabled
mac_auth_recompute_role_from_portal=disabled
dot1x_recompute_role_from_portal=enabled

[IPSK]
advanced_filter=
dpsk=enabled
default_psk_key=xxxxxxx
filter=ssid:RHDHV-SECURE
locale=
description=RHDHV-SECURE
sources=
access_registration_when_registered=enabled

[RHDHV-OPEN]
filter=ssid:RHDHV-OPEN
advanced_filter=
description=RHDHV-OPEN
provisioners=Staff-DPSK
sources=RHDHV-Guest,AzureAD_Corporateroot_OpenID
dot1x_recompute_role_from_portal=disabled

[SelfServicePortalAccess]
description=Access to the self service portal
advanced_filter=
locale=
sources=CorporaterootAuth
filter=fqdn:nac-test.corporateroot.net
self_service=default
dot1x_recompute_role_from_portal=disabled
# Copyright (C) Inverse inc.
#
#
#
# See the enclosed file COPYING for license information (GPL).
# If you did not receive this file, see
# http://www.fsf.org/licensing/licenses/gpl.html

self_service.conf

# Copyright (C) Inverse inc.
[default]
device_registration_access_duration=3M
device_registration_roles=Staff

[julsemaan]

The configuration looks valid but maybe you're not hitting the connection profile you think you are so we'd need /usr/local/pf/logs/packetfence.log while you're making a full try (RADIUS request + when it accesses the portal)

[RHDHV-simon-sutcliffe]

Good Afternoon @julsemaan

OK for this test I used a lab machine that has an EAP-TLS setup. Connection to the RHDHV-CORP Wi-Fi was connected and the user VLAN was assigned. VLAN IP was handed out to the device from the switch. Internet was tested and working as expected after connection. PF server with the portal was reachable.

Then I browsed to https://nac-test.corporateroot.net/status using MS Edge Chromium and received this screen:-

This is the network card info. You will see that the IP matches that within the browser screenshot. but it no longer shows a MAC address, I am sure this did always before so maybe that is the clue we need.

This is the node information from the admin console after connection showing the node is known to PF.

The information from the packetfence.log file whilst this activity was happening

Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] handling radius autz request: from switch_ip => (10.7.239.241), connection_type => Wireless-802.11-EAP,switch_mac => (dc:8c:37:8c:2e:a0), mac => [7c:2a:31:d1:bd:f2], port => 1, username => "L14211.corporateroot.net", ssid => RHDHV-CORP (pf::radius::authorize) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Instantiate profile EAP-TLS (pf::Connection::ProfileFactory::_from_profile) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Found authentication source(s) : 'corporateroot-TLS' for realm 'corporateroot.net' (pf::config::util::filter_authentication_sources) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Using sources corporateroot-TLS for matching (pf::authentication::match2) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Matched rule (Catchall) in source corporateroot-TLS, returning actions. (pf::Authentication::Source::match_rule) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Matched rule (Catchall) in source corporateroot-TLS, returning actions. (pf::Authentication::Source::match) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Found authentication source(s) : 'corporateroot-TLS' for realm 'corporateroot.net' (pf::config::util::filter_authentication_sources) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Role has already been computed and we don't want to recompute it. Getting role from node_info (pf::role::getRegisteredRole) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Username was defined "L14211.corporateroot.net" - returning role 'User' (pf::role::getRegisteredRole) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] PID: "L14211.corporateroot.net", Status: reg Returned VLAN: (undefined), Role: User (pf::role::fetchRoleForNode) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] (10.7.239.241) Added VLAN 82 to the returned RADIUS Access-Accept (pf::Switch::returnRadiusAccessAccept) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] (10.7.239.241) Added role Authorize_User to the returned RADIUS Access-Accept (pf::Switch::returnRadiusAccessAccept) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] security_event 1300003 force-closed for 7c:2a:31:d1:bd:f2 (pf::security_event::security_event_force_close) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255918]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Instantiate profile EAP-TLS (pf::Connection::ProfileFactory::_from_profile) Mar 1 14:46:04 packetfence packetfence_httpd.aaa[255925]: httpd.aaa(1460) INFO: [mac:7c:2a:31:d1:bd:f2] Updating locationlog from accounting request (pf::api::handle_accounting_metadata) Mar 1 14:46:21 packetfence packetfence_httpd.portal[254867]: httpd.portal(254867) WARN: [mac:unknown] Unable to match MAC address to IP '10.207.137.1' (pf::ip4log::ip2mac) Mar 1 14:46:21 packetfence packetfence_httpd.portal[254867]: httpd.portal(254867) WARN: [mac:unknown] Unable to match MAC address to IP '10.207.137.1' (pf::ip4log::ip2mac) Mar 1 14:46:21 packetfence packetfence_httpd.portal[254867]: httpd.portal(254867) WARN: [mac:0] Unable to match MAC address to IP '10.207.137.1' (pf::ip4log::ip2mac) Mar 1 14:46:21 packetfence packetfence_httpd.portal[254867]: httpd.portal(254867) WARN: [mac:0] Unable to match MAC address to IP '10.207.137.1' (pf::ip4log::ip2mac) Mar 1 14:46:21 packetfence pfqueue[255936]: pfqueue(255936) ERROR: [mac:unknown] Unable to fetch query arguments for Fingerbank query. Aborting. (pf::fingerbank::process)

Hope this gives some clues.

[julsemaan]

Try disabling status_only_on_production and see if it helps

[RHDHV-simon-sutcliffe]

@julsemaan no difference at all disabled in the GUI, restarted the haproxy as requested and checked the pf.conf and those lines were gone.

[julsemaan]

This one needs httpd.portal I believe.

[RHDHV-simon-sutcliffe]

Good Morning @julsemaan

Again, thanks for persevering with this topic for us.

Manually restarting the httpd.potral with pfcmd service https.portal restart brought back the logon screen. However, we double checked the 11.1 server, and this was also enabled in the 11.1 pre update. Was something fixed \ broken in that logic to cause this change in behaviour?

Also, the captive portal page only mentions when saving the following to restart

This would be better like in other pages to include the information to also restart the https.portal too.

The toggle in this case would have been on a "Production" network as unless I am mistaken this is coming from the status of the switch module. In the case I demonstrated it was the WLC and this is for sure "Production" in our settings.

I also a little confused as to why after the EAP-TLS authentication was successful that the MAC address is still not showing on to the user when at the login page.

I am not sure we are at the root cause of the issue but seeing a side effect. But I will leave it to your much more knowledgeable decision process to decide if this needs further investigation to the cause.

We are more than happy to help and provide time to supporting the development teams make the product better even if we are not able to write the code ourselves.

Thanks again for your support in trying to get to the bottom of this topic

[julsemaan]

My guess is that on 11.1 you access the status page via the management interface while on 11.2 you access it via the second interface that isn't management (eth0.191). The feature you enabled makes the status page exclusively available on the management interface.

Having your WLC set to production doesn't have the same meaning as this and that becomes more of a comprehension of how PF works and potentially better documentation.

As for the MAC being set to 0 on the status page, that's because PF doesn't see the DHCP of your production network but that doesn't stop the status page from working

Actions items:

• Clarify in the admin that status_only_on_production means the status page will exclusively be accessible via the management interface
• Add a restart of httpd.portal in the 'Captive portal' configuration section since that's necessary

[RHDHV-simon-sutcliffe]

@julsemaan thanks for the feedback here.

nac-test.corporateroot.net only resolves internally to 10.202.1.126 this is the eth0.10 and is defined as management. This did not change with 11.2 as it was an unplace upgrade.

eth0.191 is our interface within the registration VLAN.

However clearly there is someone adrift with the status_only_on_production setting as in our case enabling it stops the /status and /device-registration been able to be reached on the eth0.10 interface.

You are bang on the money tracking it down, but when we enable it in our setting on11.2, thinking about your explanation, should we not expect since our internal resolution of nac-test.corporateroot.net is to 10.202.1.126 and this is the management interface it should be reachable and was with the same setting in 11.1?

Just thinking about this. Could the logic be wrong in the code to assume that the management interface is eth0 and in our case there is nothing on that and we only have VLAN's in use.

[julsemaan]

You can bring these issues to the list but given the advanced workflows you're configuring, getting a support contract is advised so you can get hands-on help from our team.

[RHDHV-simon-sutcliffe]

@julsemaan, yes, we are working on that. At RHDHV we have a project backlog, the NAC project is identified and waiting for resources (Once it becomes an active project, within the PID I have allocated the funds for the Gold Support package, but getting funds outside of a project is exceedingly difficult for us). We are not in the business of a free lunch with nothing back to those that must feed their families.

As I explained to Ludovic in our original telco a couple of months ago, currently this is within the R&D team and we are trying to get as much knowledge on the product as we can, our focus is on replacing the current Wi-Fi access solutions with a global unified way of working, then we will move onto the wire network.

But as we have gone along, we find items that we think are bugs or areas that the product would benefit from a feature or improvement, so we try to help by raising feature or bug requests in GitHub for you and the dev team to review.

We have seen you all act on some of those raised issues, so we fully understand you are listening, so we understand there is limited time, and this is not a support zone. I do feel this is a bug somewhere, but we can if needed tackle it with support when the contract is in place.

I know we both share the same goal; make PF a solid well-functioning NAC solution. So thank you for your patience with me and your consideration on the other open tickets I have raised.

[danrik1983]

RHDHV-simon-sutcliffe

Did you manage to solve this problem? I'm going through a big difficulty with this error and I can't get around it.