PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) solution. Boasting an impressive feature set including a captive-portal for registration and remediation, centralized wired and wireless management, powerful BYOD management options, 802.1X support, layer-2 isolation of problematic devices; PacketFence can be used to effectively secure networks small to very large heterogeneous networks.
Describe the bug
When using a cluster and a pfconnector-remote, the source IP of the RADIUS packet that is tunneled out on PacketFence is the IP of the PacketFence server.
When FreeRADIUS searches the shared secret for that packet, it will always take the cluster local secret because these are defined in the configuration of FreeRADIUS in the generated config.
This means you must use the local_secret when using a cluster + pfconnector-remote and cannot base the local secret on NAS-IP-Address in the dynamic-clients (it never gets to the dynamic clients because it hits in the config)
There is no easy way to address this in 12.0 and it was discussed that a limitation of the pfconnector-remote could be that the RADIUS shared secret would need to be the local_secret until we complete a RADIUS termination handler in the pfconnector-server. For this reason, 12.0 will have this as a limitation. It doesn't prevent anything from working, just limits the flexibility on defining your own RADIUS secret.
To Reproduce
Use a pfconnector-remote and a PacketFence cluster
Expected behavior
Should be able to use any RADIUS secret you want when going through a pfconnector-remote when there is a NAS-IP-Address that can match in PacketFence
julsemaan
commented
2 years ago
Describe the bug When using a cluster and a pfconnector-remote, the source IP of the RADIUS packet that is tunneled out on PacketFence is the IP of the PacketFence server. When FreeRADIUS searches the shared secret for that packet, it will always take the cluster local secret because these are defined in the configuration of FreeRADIUS in the generated config. This means you must use the local_secret when using a cluster + pfconnector-remote and cannot base the local secret on NAS-IP-Address in the dynamic-clients (it never gets to the dynamic clients because it hits in the config)
There is no easy way to address this in 12.0 and it was discussed that a limitation of the pfconnector-remote could be that the RADIUS shared secret would need to be the local_secret until we complete a RADIUS termination handler in the pfconnector-server. For this reason, 12.0 will have this as a limitation. It doesn't prevent anything from working, just limits the flexibility on defining your own RADIUS secret.
To Reproduce
Expected behavior Should be able to use any RADIUS secret you want when going through a pfconnector-remote when there is a NAS-IP-Address that can match in PacketFence