I'd get an ISP that is willing to do things right. Just sayin'.

I'd pcap and see exactly what's happening. Maybe they have something silly like an inability to ARP for more than X IP addresses per MAC address or something.

It is almost certainly NOT the pfSense software.

@jimp said in DHCP Server wrong IP CARP:
On the primary, add the secondary interface address in each active DHCP server tab.

Yup, did that! Thanks both of you - I didn't realize it was supposed to be that way, and although I've read the HA docs a number of times I guess I missed the part where DHCP server address would show as the actual IP of the box, not the VIP.

Thank you!
Cheers
Tiwing

OK forget it. I was messing around and disabled, then re-enabled guest interface on both primary and secondary and problem is now gone. I can't explain why, but ..... woohooo!

mods, you can close or outright delete this thread!

cheers

We are having L3 switches and I can't find anything about that... I'm thinking more and more that our pfSense appliance is having a hard time with the traffic!

Thank you, I'm going to look at all this documentation and I'll come back to tell you the solution to the problem or more specific questions for more specific help.

CARP is designed for a router failing or router interface going down, so the IP addresses will switch to the backup router. The CARP IP on WAN isn't going to work on both ISPs without some sort of SD-WAN arrangement.

@PiBa said in HAProxy forwarding to NGINX Seafile:

How to do it, basically still follow the instructions and don't do what do you don't need.?

If you don't want to offload, leave the ssl checkbox on the frontend 'off' and choose for mode 'ssl/https'..
As your then not using offloading, also leave the 'Encrypt-SSL' checkbox on the backend server 'off', (but do check the SSL-Checks checkbox..).

Should be pretty easy.. give it a try, and if it doesn't work show the config as you have made, and tell what the stats page looks like, is the server green and if not what does lastchk column say?.
I'm not inclined to write a step-by-step guide tailored to a specific user. As that would be more work for me, and less of a learning experience for you.. Really.. if it doesn't work first time you can try again for no additional fee

Thank you with your help I got it done. Unfortunately I don't understand most of it because it is completely new territory for me. here it is difficult to say what you need and what you don't. the side can be reached from the outside and everything should go :) THANKS again

It might be your switch doing it and not the firewall, check for and disable things like multicast storm control to rule that out.

Also you could set advbase higher on the VIPs so that it takes longer to trigger a failover. If you increase advbase to 1 that would take 1 second + skew to switch. Or use QoS to limit the initial burst to a lower speed.

Nobody?!?

@cmcologne said in Only VIP no Interface IP:

Why is it not possible to only assign a CARP-IP to a Interface?

Cause the interfaces which are sharing a CARP VIP must be able to communicate over Layer 3. So they need to have a unique IP each within a common subnet.

It's possible to assign IPs out of a private subnet to the interfaces with some drawbacks.
You may find threads discussing that topic here in this forum when you search for "CARP with only one public IP".

@jimp Brilliant. Thank you for clarifying that.

@jimp said in Sync error with packages since today:

That's just one possibility, but something to consider.

Absolutely, thanks. As this was some elevated by my boss because of the constant nagging ;) I can report, that Paighton from Support has found it out. To my surprise our old FreeRadius configuration (since the FR2 package times) contained a manual sync setting instead of using the systems sync (which would be the right way but I can remember it sometimes being bugged in the beginning). So as we switched UI Port a few weeks ago we never had any problem until there was a request for a new customer VPN server and Radius User. Didn't see that coming and perhaps would have found it in the end after debugging hours, but happy to say that support got it faster :) So always check your packages that allow syncing to the cluster peer and make sure the sync is using the right ip/port/credentials or is using the system ones in the first place :)

Should have found that myself, but sometimes especially in your own setup environments you get stuck in a rut... In a customer setup I'm fairly certain we would've found that ;)

I created a new vm, assigned the offending IP to that VM, let it hang out for a day, deleted the VM and the DNS records in Infoblox. Finally, after the weekend the record has cleared in Infoblox and presumably the switch.

Switch weirdness in the end, I suppose.

Thanks to Derelict for the suggestions in trying to track this down.

That's called out in the documentation in several places

https://docs.netgate.com/pfsense/en/latest/book/highavailability/high-availability-troubleshooting.html#issues-inside-of-virtual-machines-esx

https://docs.netgate.com/pfsense/en/latest/highavailability/configuring-high-availability.html#vmware-esx-users

https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-high-availability-clusters.html#hypervisor-users-especially-vmware-esx-esxi

[...]

As long as the L1/L2 between them is clean and fast that should be OK. You can adjust advbase if it isn't. With a higher advbase it won't fail over as fast, but it is more tolerate of latency between the nodes. Having them in different places in the same building is not unheard of, or even separate buildings on the same campus. It's not ideal but it can work. I think we even had someone try to use CARP for HA to a node in a DC as some attempt at DR, but I can't remember if that ended up working in the end.

When working with skew and base values for CARP VIPs, Skew values are 1/256th of a second, and base values add whole seconds. So if you set advbase to 1, then it would wait 1 second + skew, rather than only the skew time.