In a recent Technical Kemping event, LoadMaster Principal Pre-Sales Engineer Renard Schöpfel (LinkedIn Profile) ran through two practical and important topics:
During the webinar, Renard covered five access control mechanisms and walked through live demos of each. He also covered the importance of pairing LoadMaster configuration backups with separate certificate backups.
Watch the webinar recording below and read on for a written summary.
If you want to get the information directly from the event recording, you can watch it now.
Watch the Full Webinar Recording
For a summary of the topics discussed, read on.
The LoadMaster solution gives you five ways to control who can access your applications and Renard's central point throughout the session was that you can layer these tools rather than pick just one. Each does something the others don't and understanding the trade-offs matters more than memorizing the feature list.
The five tools are: the package routing filter, access control lists, content rules, Edge Security Pack and the Web Application Firewall (WAF).
The package routing filter operates globally. When enabled, the LoadMaster solution stops acting as a simple IP forwarder and begins enforcing rules based on source IP. You can build allow and block lists, and a block here applies to every virtual service hosted on the LoadMaster platform.
Renard demonstrated this live by blocking his own client IP. Every virtual service on the the LoadMaster solution stopped responding to him instantly. Reversing the rule restored access immediately. If you need to lock someone out quickly across an entire deployment, this is the tool to reach for.
Access Control Lists (ACLs) apply to each virtual service rather than to the whole machine. You get unlimited entries and a comment field, which helps when you're maintaining a long list. The trade-offs: ACLs apply only to the main virtual service, not to sub-virtual services and blocked access attempts don't appear in the standard logs. The access control check occurs before the TLS/SSL handshake, which is why sub-virtual services can't use it. The handshake terminates at the main virtual service.
Content rules give you the most flexibility of any access control tool in the LoadMaster solution. You can match on source IP, host header, URL path, HTTP method, user agent, cookies or any other header you care about. They work on both the main virtual service and sub-virtual service and you can combine them in multiple ways. Renard demonstrated two approaches:
The "soft" approach uses match rules without "fail on match" enabled. Traffic passes only if it matches at least one of your rules. Everything else gets blocked by default.
The "hard" approach uses match rules with "fail on match" enabled. Matched traffic is blocked, and everything else passes.
Most real-world deployments need a combination. Content rules cap at 1,024 in total across the system and triggered rules appear only in debug logs, not in your main logs.
Question: Combining Rules with Flags
One webinar attendee asked whether you could build an AND condition (matching a specific host name AND a specific folder). Renard demonstrated two approaches.
The first uses flags. Create a selection rule that matches the hostname and sets a flag to 1. Then create a content rule that matches the folder but only fires when the flag is 1. Selection rules always run first, so the flags get set before the second rule evaluates.
The second approach skips the flag entirely. Build a single match URL rule, leave the header field blank and tick the option to include the hostname in the match. One rule with one match of the host name and the directory together.
Use flags when multiple rules depend on the same condition. Use the combined match rule when you need the AND condition just once.
Edge Security Pack (ESP) requires an Enterprise license. It controls which hostnames and directories your application accepts. Anything outside your allow list is blocked before it reaches backend servers and these blocks are recorded directly in your security logs.
ESP also handles pre-authentication. The client authenticates with your identity provider (LDAP, RADIUS, OIDC, SAML or others) before the LoadMaster solution opens any connection to backend servers. If authentication fails, the backend never receives the request. After successful authentication, the client receives a LoadMaster data cookie that proves their identity for the rest of the session.
You can restrict access by user group or by steering group. Steering groups set an additional cookie that identifies the user's group and content rules can then route different groups to different sub-virtual services. This pairing of ESP and content rules enables role-based routing without separate services for each role.
A note about multiple cloud identity providers: LoadMaster supports only one OIDC or SAML provider per service. If you need to route users to different identity providers based on their domain, Renard recommended using RADIUS as an intermediary. RADIUS can handle the routing logic and forward to the appropriate provider.
The LoadMaster WAF operates on a per-request basis, not per session or per time window. Every incoming request gets evaluated against every active rule. Each triggered rule adds points and once the cumulative score exceeds your threshold, the request gets blocked. A single request can trigger multiple rules and all those points add up against it.
This matters because many admins assume WAFs use rate-based blocking ("X violations in Y minutes"). The LoadMaster solution doesn't. It evaluates each request on its own merits.
The WAF ships with the OWASP Top 10 core rule set, plus a frequently (often daily) updated IP block list of known bad actors and a false-positive review section that shows which rules would trigger at each blocking level. You need a support subscription to get the rule updates. You can add custom rules, reference external data files for dynamic lookups and apply rules to both the main virtual service and sub-virtual services. There is no upper limit on the number of WAF rules.
Our next Technical Kemping webinar will focus on the WAF and security.
Renard also covered backing up LoadMaster certificates and configurations during the webinar.
Certificate backup covers TLS/SSL and intermediate certificates and always requires a passphrase. The config backup covers everything else: virtual services, geo settings, TLS/SSL settings (the configuration, not the certificates themselves), ESP settings, content rules and the core configuration.
When you restore a configuration backup, you have operational-focused options. Virtual services, geo settings and TLS/SSL settings all restore without a reboot. They overwrite the existing configuration rather than merging with it.
However, a core configuration restore triggers a reboot and is subject to stricter rules: standalone backups restore only to standalone machines and HA backups restore only to HA pairs. You can move other items (virtual services, GEO, TLS/SSL) freely between standalone and HA setup backups.
A useful trick from the live session: you can open a backup archive, edit the XML to set all virtual services to off, then restore this modified backup to a new machine. Your configuration transfers across, but nothing activates until you enable them manually.
For automation, you have several options. The API supports both configuration and certificate backups, using either username/password or API key authentication. FTP auto-backups work but capture only partial configuration data. LoadMaster 360, our SaaS management solution, now stores backups automatically in the cloud.
In many circumstances, the right answer to an IT configuration problem is rarely a single feature. In the access control scenario, that's true. The package routing filter handles emergency lockouts. ACLs cover simple per-service rules. Content rules give you fine-grained traffic shaping. ESP handles authentication and authorization. The WAF protects against application-layer threats. Use them together based on what each does best.