pfSense

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 on the other machine and 192.168.4.79 on the other machine (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 two exceptions:
- The primary firewall may become backup, e.g., because the WAN is unplugged, while still being reachable on the LAN. 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.
- Two DHCP servers which are not in HA sync because the on purpose should provide different (i.e., their own) DNS addresses are not a good idea in general. I have seen situations, where the backup firewall did seem to provide the DHCP answer and/or where DHCP answers may have been cached. That leads to the guest being authenticated at the secondary firewall while the primary firewall is active as such.

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.