@filosofixit Now it's clear. The radios have to be configured to use pfSense (192.168.0.1) as default gateway. On pfSense you have to remove the check at "Block private networks" in the WAN interface settings. Then add a firewall rule to WAN allowing traffic from the radios subnet (maybe 192.168.0.0/24) to whatever you need. For accessing the radios from LAN you should disabling the NAT on these connections. Go into the outbound NAT settings. If it's in automatic mode, select the hybrid mode and save it. Than add a rule: Do not NAT: checked Interface: WAN source: LAN network (or an alias for all your internal networks or RFC1918) destination: the radios subnet (192.168.0.0/24?)

@daddygo I've updated to the latest version. I still do get issues with the carp IP syncs. I don't get why it's doing a splitbrain master config all the time. Additionaly it does shift the IPs in the list. I don't get why. Is there any way, I can dig deeper log level wise to figure out what actually might be the reason?

@maartenv FOUND IT! My hostname was wrong. I forgot to set the right hostname in the "General Setup"

@clumbo The docker didnt listen yet? ( https://forum.netgate.com/topic/159331/haproxy-and-websockets?_=1608750100359 ) or different issue here?

@viragomann Good luck with that. It might work for some things but if you do something like create a new CARP VIP with an advskew of 100 (the default on the secondary) I would expect it will not sync to the primary correctly.

@derelict it is a physical setup, not virtual. I have the core network setup with BGP routing working via FRR. The 2 BGP legs are on separate subnets, so CARP multicast isn't working... I've been working hard on this setup and have (via a lot of reading and fustration over the CARP functionality not beinging configurable to something else eg simple ping's and then sync the state over the SYNC interface) have ended up with something like the following: The two BGP routes are connected to two switches (which are stacked for failover and LAGG/LACP) and then setup LACP on the WAN interfaces on the XG-7100's so they are connected to each BGP and then have a network specialist (I'm dumb when it comes to network equipment) configure the switches for me so LAGG/LACP is isolated to 3 ports and multicast is kept on the ports the WAN ports are located in to avoid network spam. I hope this will work, but I need to read up on the XG-7100 to setup WAN LACP and find a way to test it without the actual switch(es) to avoid downtime. For some reason Netgate likes to use switches and obscure non ethX naming schemes for everything and not expose information about the physical layer before actually configured PFSense makeing i difficult for a (PFSense/FreeBSD) noob to get up 2 speed. There is a first time for everything. Thanks for your updates and sorry for the very long delay in the update - I had to get moving on this project faster than expected and have just finised to the above state where WAN LACP and stacking switch configuration is needed (even our hosting partner had issues with BGP due to PFSense not being Cisco and for some reason FRR had issues with the BGP password causing weired issues and one of the BGP CPE's fail on ARP refresh from time to time, so it has been a fustrating and slow process).

@rivest1000 That should be fine. Sounds like you need to simultaneously capture an interesting connection on all three inside interfaces and see what there is to see. Sorry but it's something unique to your environment based on what I have so far. Are the missing FIN/SYN packets being sent to the primary while the secondary is MASTER? You're POSITIVE the zabbix hosts have the correct default gateways for the necessary traffic?

@rivest1000 Need a better description of exactly what you are saying. You should also probably start a new thread. It doesn't sound like you are talking about the well-known need to NAT from the primary when talking to the secondary over a VPN.

@piba Thanks for the reply! I will try the suggestion for Letsencrypt The Apache2 server has been configured to capture the X-Forward-For in the log file but only the gateway IP address is donut in the log file. I think it has to do with the SSL part...

@noplan yes its set for another port. My thoughts regarding this issue I have other https Server running on the other public IP's - so could it be something in this ( Allthough the DNS just point to a IP ) but it'll look like some of those settings are conflicting or something. The internal Proxy are running great and like the view of the green certificate

Flushing the State Table solved this.

@Piba So the actually solution was stopping HAproxy - issuing the missing certificates - and the create the frontends - and start the HAproxy again So the prxy answering for both insa.dk and www.insa.dk Thanks for the replys and solutions