@Derelict I realized today that although the LE cert syncs to the secondary just fine, it doesn't restart nginx which continues using the expired cert. On the primary router the Post-Renew Actions is run to do that. That doesn't exist on the secondary because the cert doesn't exist on the secondary. Is there a proper solution other than restarting the secondary webGUI via cron or something?

Guess I never really thought about the possibility of a failover event occurring in the middle of making configuration changes. But I guess that's as likely to happen as anything else. I'll now consider myself lucky that it never did. I've gone and updated all of my bookmarks and tooling to use the explicit primary and secondary IPs. Thanks again.

@ndemou I have what may be a related issue, but I'm hesitant try try this patch as I'm on pfSense plus 26.03.1. Although my certs are valid, when I try to setup a frontend in HAProxy,I don't get the cert dropdown, I just get an empty text box. I tried entering my cert name but then it throws a parsing error when I try to save it. [ALERT] (87716) : config : parsing [/var/etc/haproxy_test/haproxy.cfg:15] : 'bind 0.0.0.0:443' in section 'frontend': unknown keyword 'mynet.com'. [ALERT] (87716) : config : Error(s) found in configuration file : /var/etc/haproxy_test/haproxy.cfg [ALERT] (87716) : config : Fatal errors found in configuration. In the example above, unknown keyword mynet.com is my certificate name, which I entered into the textbox since there was no dropdown list.

The redmine hasn't been addressed directly. As far as I know it has not been fixed but it's possible something has fixed it indirectly. If you have a good test case for it it would be good to know.

@sgw You can run HA with pfSense CE.

@netblues Right. Thank you very much.

@Chebec Have a read through: https://docs.netgate.com/pfsense/en/latest/development/patches/custom.html and the rest of the topic. If you add a patch, it should detect whether it can be Applied and will or will not show the Apply button, as I recall. There is also a Debug button to test. Normally a patch can be reverted via that button, yes, unless the target file is later changed. (after updating pfSense you would not want to revert a patch and reintroduce a bug, just delete the custom patch) Note there's a later patch ID in that redmine: 8544b85f8c32d0f180c09a4d0986ac819919bd2b As long as patches are from Netgate developers I would have no issue installing them. For random patches in the forum I'd be a bit more cautious. In either case you can see the code being changed, in the patch details. Edit: Marcos M in the redmine is a Negate dev.

@boumacor I'm not a huge fan of floating rules if they can be set as regular rules, since the, er, rules change for floating. Just to maintain clarity. However if the rule triggers and a state is open you're through pf. Does the pfSense routing table show a route for the 192.168.1.0/24 subnet? I would still be suspicious of the switch ignoring traffic outside its own subnet unless you're sure it will allow it. You could set an IP on some other device and ping it, to check the connection through pfSense.

@stowemotion59 It is an entirely new OSPF session requiring a complete reconvergence so it should be fine.

@Barnzey90 do you have an account on https://redmine.pfsense.org/ to report the issue?

@netblues you can't really have carp failover without 3 ip's in the same subnet Depends, which is why I asked about it. We’ve set it up on Comcast/Xfinity using one shared static public IP and set the WAN IP on both routers in the default 10.1.10.x range. That works well. Docs cover only one IP but there’s no connectivity until failover: https://docs.netgate.com/pfsense/en/latest/highavailability/index.html#ip-address-requirements-for-carp If WAN2 is really only DHCP though then I don’t think there can be a shared IP.

@AlexMercer Move the webgui to 4443. Disable webConfigurator anti-lockout rule. Disable webConfigurator redirect rule. Add a specific rule for the internal interface (any LANish is good, preferrably the one which is your dedicated management LAN) to port 4443. This hardening and consistency ensures whatever goes wrong, any public WAN/443 combination won't ever reveal the webgui. Always remove excess rules- if you don't know why it is there, get rid of it.

What is the recommended method of ensuring high availability of a service running on or behind an HA cluster then? Require running the DynDNS client on a separate system (not the firewall itself?)

Been about 4 years... anyone have any thoughts on this? Syncing packages seems like it should be table stakes at least.