Looking for a "best practice" design or tips for multiple location/firewall authentication

One thing to add:

Because of the authentication differencies (SATC via AD, heartbeat via own entry) I have each user (at least the HQ users) with a second mail address/firewall user account. One corresponds to his windows UPN login (heartbeat) one corresponds to the internal AD domain which is different from any "real" mail address (SATC).

If I could get rid of this I would be very obliged.

Hi kerobra 

Try to move from policy base VPN to route base VPN try route-based VPN (any to any subnets) might help 

Regards

Unfortunately, Heartbeat and Authentication do not sync over multiple Firewalls. I never understood why this is not possible. I mean, they have Central. It would not be too much rocket science to use that to Sync User and HB all over your distributed networks.

 Heartbeat accross multiple Firewalls - somehow possible? 

Now you must decide where you want HB to happen - you have chosen the HQ firewall.

What you can do, is to bring the heartbeat IP connection from the BO to the HQ. That way only the HQ firewall will handle all authentication and HB information.So you do not want the BO Firewall to compute the heartbeat request and send it to Central, instead you want that to be forwarded to the HQ firewall and that device syncs all heartbeat sessions with Central.

As far as you do not have the need for HB-based Firewall rules at the BO, this will fulfill your need. Route based VPN with "Tunnel interface" can be used to do SD-WAN routing for heartbeat IP and Port.

Unfortunately this is no option because the DHCP scopes are managed centrally on a MS Windows DHCP server. I wanted to use tunnel interfaces first unless I stumbled over this entry in the documentation: (3rd row)

Because DHCP is generally managed by our 1st level support which absolutely would be overextended by doing this on a firewall (and apart from that I don't want them to be able to look into firewalls) it is no option to terminate DHCP on every BO firewall.

I understand. have you thought of DNAT the HB IP/Port as sugegsted by LuCar Toni in that post I linked above?

kerobra said:

Because of the authentication differencies (SATC via AD, heartbeat via own entry) I have each user (at least the HQ users)

We're using that combination and have no issues with duplicate usernames - both authentications show (when SATC even works at all) the correct username on the firewall - it is the UPN (not really the mail address).

Route system-generated authentication queries through an IPsec tunnel will clear most of the scenario 

The UPN at our customer is identical to his mail address since they need it for Entra ID synchronization.
Their classic SAMAccount name is different to the local part of the UPN.

For example: SAMAccount is "jsmith", UPN is john.smith@external-domain.tld, internal AD domain is "lan.external-domain.tld".
Because of the weird behaviour how "Synchronized user ID authentication" is working ("The domain is taken from the User Principle Name (UPN) of the users' AD record, and the username is taken from the sAMAccountName") this leads to multiple accounts at the firewall.

1st account: jsmith@external-domain.tld
2nd account: jsmith@lan.external-domain.tld.

Both firewall accounts have nothing to to with the "real UPN" or mail address and both accounts have the same mail address:
Fortunately the HQ firewall is not used for antispam services and it is not used for client VPN. If the users had to go into the Userportal it would get very confusing.

Don't hang on the underlying VPN. The whole IPSEC tunnel topic will soon die (app. 3-6 months) because of moving from local WANs to MPLS in every BO location.

I have one BO firewall that is currently connected via "Etherconnect" which is a technique similar to a RED tunnel. To cut it easy, you have a RJ45 GBit Port in HQ and a RJ45 GBit Port in BO and they share the same L2/3 like it would be with a cable between two switches.

Maybe I will use this firewall for the testing of the DNAT thing for HB as it is nearly the state that the current IPSEC connected BO firewalls will have in a few months.