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 and sharing a CARP VIP of The DHCP server provided 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 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 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 as a gateway but a list of DNS: plus and (without would work also).
    • Unbound resolves portal.x.x to on the one machine and to 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 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.



  • I can confirm this issue, I upgraded to 2.2.1 and then 2.2.2 and had this issue.

    my CARP IP of with real router IP's of and

    my DNS was set to, once I switched it started working again.

    Would it be possible to create a firewall rule to fix this?

  • Rebel Alliance Developer Netgate

    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.



Log in to reply