Potential Bug in Captive Portal pfSense 2.2 when used with CARP
-
Dear All,
Similar to this thread: https://forum.pfsense.org/index.php?topic=87991.0 I feel that there might be a bug in captive portal from pfSense 2.2 when used with CARP.
With pfSense 2.1.5, I had the following working setup for two firewalls: Aside from the LAN, the GUEST network is 192.168.4.x In that GUEST network, the two pfSense machines are 192.168.4.78 and 192.168.4.79 sharing a CARP VIP of 192.168.4.1. The DHCP server provided 192.168.4.1 as DNS and Gateway to guests. Prior to authentication that address was available to guests. It did produce the portal page. To do so, I did use https and unbound (then as a package) to resolve portal.x.x to 192.168.4.1 This did work in best HA manner, i.e., if one machine was off, the other took over.
After upgrading to 2.2, this does no longer work. Guests can reach anything in 192.168.4.x except for 192.168.4.1. Thus, the classical portal page is not available to enter authentication credentials. The only workaround I could find is the following:
- The DHCP server provides 192.168.4.1 as a gateway but a list of DNS: 192.168.4.1 plus 192.168.4.78 and 192.168.4.79 (without 192.168.4.1 would work also).
- Unbound resolves portal.x.x to 192.168.4.78 on the one machine and to 192.168.4.79 on the other machine. Turn of HA sync for DNS resolver to keep both machines apart in terms of unbound local data.
The workaround does work, but with one exception: There has to be an order of DNS servers. Obviously one will put the intended primary firewall first. A problem occurs if the primary firewall becomes backup, e.g., because the WAN is unplugged, while still being reachable on the LAN. Then, the DHCP server of the secondary (unless one will give up DHCP server sync also, leading to other issues) will provide a list of DNS containing the primary firewall in backup mode ahead of the secondary firewall now in master mode. Then, the portal.x.x domain will resolve to the primary firewall in backup mode. The guest user will enter credentials at the portal page of the primary firewall in backup mode while the gateway IP (CARP VIP 192.168.4.1) leads to the secondary firewall now in master mode. Thus, the authentication will not have had any effect.
Such workarounds with limitations in functionality and/or the need to limit syncing firewalls were unnecessary prior to 2.2. Thus, I suspect that the changed behavior is a bug.
Can anyone suggest a better configuration please? If not, I will file a bug report.
Regards,
Michael
-
I can confirm this issue, I upgraded to 2.2.1 and then 2.2.2 and had this issue.
my CARP IP of 10.5.5.1 with real router IP's of 10.5.5.2 and 10.5.5.3.
my DNS was set to 10.5.5.1, once I switched 10.5.5.2 it started working again.
Would it be possible to create a firewall rule to fix this?
-
Add the CARP VIP to the Allowed IP addresses tab for the portal.
-
Dear Jim,
adding the IP to the allowed addresses does solve the problem - thank you very much! I wonder why I did not find this based on intuition, but the answer is also somewhat obvious: This was not required in the previous version and thus, one does not think about it.
Regards,
Michael
