In short

Problem: After I switched on Traefik GeoBlock, Claude’s connector to Home Assistant stopped working, while Home Assistant itself was fine for everyone at home.

Solution: The connector calls from Anthropic’s servers in the US, and GeoBlock only allowed my own countries. One allowedIPAddresses entry with the provider’s published IP range fixed it.

Tested with: Traefik 3, GeoBlock plugin (PascalMinder) 0.3.8, Home Assistant with an MCP server for Claude

In Hardening Traefik I put GeoBlock in front of every service: only visitors from the countries my family lives in get through, everyone else gets a 403. It worked exactly as planned. A bit too well, as it turned out: it also locked out a visitor I wanted, my own AI assistant.

This is a short story about a security measure that does its job, breaks something you need, and how to find out which one it was.

1. The symptom

I use Claude with a connector to Home Assistant, so I can ask about sensors, automations and logs in plain language. Shortly after the hardening, the connector couldn’t reach Home Assistant anymore. Every attempt failed.

At the same time, Home Assistant was perfectly fine: the dashboard loaded at home, the app on my phone worked, automations ran. Only this one client was affected.

2. What I checked first (and why it misled me)

A connector that signs in with OAuth has plenty of parts that can break, so that’s where you look first:

• Sign-in and tokens: an expired token or a broken OAuth setup would explain a failing client. But reconnecting doesn’t help when the requests are blocked before they arrive.
• Home Assistant logs: nothing. No failed login, no error from the MCP integration, not even a request.
• The URL: it opens fine in the browser.

The empty Home Assistant log was the real clue, and it’s easy to read it the wrong way. “No errors” sounded like “nothing wrong in Home Assistant”. It actually meant: the requests never arrived. Something in front of Home Assistant was answering them. And “it works in my browser” proved nothing, because my browser comes from an allowed country.

3. The real cause: Traefik GeoBlock did its job

Claude’s connectors don’t run in my browser or on my phone. They call my server from Anthropic’s infrastructure, which sits in the US. For GeoBlock that’s just another request from a country that isn’t on the list.

Two logs show it. GeoBlock writes every denied request to its own file. A line looks like this (example address):

INFO: GeoBlock: 2026/10/16 09:14:52 geoblock@docker: request denied [203.0.113.17] for country [US] due to: country is not allowed

And the Traefik access log shows the 403 with an empty backend ("-" after the router name). That dash means the request never reached the service (again an example line):

203.0.113.17 - - [16/Oct/2026:09:14:52 +0000] "POST /api/webhook/… HTTP/1.1" 403 0 "-" "-" 4711 "homeassistant@docker" "-" 1ms

The log is full of scanners from all over the world, so the connector’s requests don’t stand out by themselves. Compare the denied addresses with the range Anthropic publishes for its outgoing traffic, and they do.

4. The fix: allow the published IP range

GeoBlock has an option for exactly this: allowedIPAddresses. Addresses in this list are let through no matter which country they come from. One more label on the Traefik container:

      # Claude connectors call from Anthropic's published outbound range
      # source: https://platform.claude.com/docs/en/api/ip-addresses
      - "traefik.http.middlewares.geoblock.plugin.geoblock.allowedIPAddresses[0]=160.79.104.0/21"

Then recreate the container so Traefik reads the new labels:

docker compose up -d traefik

The range above is the one Anthropic lists at the time of writing. Check Anthropic’s IP address page for the current one before you copy it. The same approach works for any other service that has to reach you from abroad, as long as its provider publishes its IP ranges.

5. How to verify

1. Check that Traefik picked up the label:
   docker inspect traefik --format '{{ index .Config.Labels "traefik.http.middlewares.geoblock.plugin.geoblock.allowedIPAddresses[0]" }}'
2. Use the connector once (in my case: ask Claude for a sensor value).
3. Make sure the range no longer shows up as denied:
   grep -E '\[160\.79\.1(0[4-9]|1[01])\.' traefik-logs/geoblock.log | tail
   No new lines after the restart means GeoBlock lets the connector through.

What I learned

• “Works in my browser” is no test for a geo-block. Ask where the failing client really calls from.
• An empty application log is a finding, not a dead end: the request was stopped earlier.
• Before switching on an allow list, write down every service that calls in from outside: AI connectors, webhooks, monitoring, push services. Each one needs a deliberate exception or a different path.

The full GeoBlock and CrowdSec setup is in Hardening Traefik: geo-blocking, CrowdSec and single sign-on.

In short

Problem: Every login through a new Authentik OAuth2/OpenID provider fails with invalid_request: “The request is otherwise malformed”.

Solution: The provider was created through the API, and its grant_types list was empty. Set it to authorization_code and refresh_token, then test the authorize URL with curl.

Tested with: Authentik 2026.8, WordPress with the OpenID Connect Generic plugin 3.11

I add most apps to Authentik through the admin interface. For this blog I wanted to script it, so I created the OAuth2 provider with a single API call. The call succeeded, the application showed up, the WordPress plugin was configured with the right client ID, secret and endpoints. And then not a single login worked.

The fix turned out to be one field. Finding it took longer than it should have, because the error message points in the wrong direction.

1. The symptom: “request is otherwise malformed”

Clicking “Login with OpenID Connect” in WordPress sent me to Authentik, and Authentik sent me straight back with an error page instead of a login form:

invalid_request
The request is otherwise malformed

No username prompt, no password prompt. Authentik refused the request before the login flow even started.

2. What I checked first (and why it misled me)

“Malformed request” sounds like the client sent something wrong. So I went through the usual suspects on the WordPress side:

• Redirect URI: character by character against the provider. Authentik uses strict matching, so a missing slash or a different query string is enough to break it. It matched.
• Client ID: copied again, no stray spaces.
• Scopes: openid email profile, all three available in the provider.
• Endpoints: taken from the provider’s .well-known/openid-configuration.

Everything was correct. The request from WordPress was fine. The problem was on the Authentik side, and the browser error doesn’t tell you that.

3. The real cause: an empty grant_types list

The Authentik server log had the more useful message. With Docker Compose:

docker compose logs server --since 10m | grep -i grant

It said “Invalid grant_type for provider”. Every OAuth2 provider in Authentik has a list of allowed grant types. When you create a provider in the admin interface, the form fills in sensible defaults. The API doesn’t: grant_types is an optional field, and if you leave it out, the provider is saved with an empty list. An empty list means no grant type is allowed, so not even the normal authorization code flow works.

My API call looked roughly like this (shortened):

curl -X POST https://id.example.com/api/v3/providers/oauth2/ \
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Provider for My Blog",
    "client_type": "confidential",
    "authorization_flow": "<flow uuid>",
    "invalidation_flow": "<flow uuid>",
    "redirect_uris": [
      {"matching_mode": "strict",
       "url": "https://blog.example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize"}
    ],
    "signing_key": "<certificate uuid>",
    "property_mappings": ["<openid>", "<email>", "<profile>"]
  }'

Every required field is there, so the API accepts it without a warning. The one field that decides whether anyone can log in is the one that’s missing.

4. The fix

Set the grant types on the existing provider. A login flow for a website needs authorization_code, and refresh_token if the app renews its tokens:

curl -X PATCH https://id.example.com/api/v3/providers/oauth2/<provider id>/ \
  -H "Authorization: Bearer $AUTHENTIK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"grant_types": ["authorization_code", "refresh_token"]}'

You can also open the provider in the admin interface and save it there with both grant types ticked. For new providers, add the line straight to the create call:

    "grant_types": ["authorization_code", "refresh_token"],

While you’re at it, compare the token lifetimes too (access_token_validity, refresh_token_threshold) with a provider you created in the interface. API-created providers don’t always get the same values, and it’s easier to keep all providers alike.

5. How to verify (without a browser)

You don’t need to click through the login to test a provider. Call the authorize endpoint with curl and look at where Authentik sends you:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  "https://id.example.com/application/o/authorize/?client_id=<client id>&response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fblog.example.com%2Fwp-admin%2Fadmin-ajax.php%3Faction%3Dopenid-connect-authorize"

• Working: a 302 to Authentik’s own login flow, for example /if/flow/default-authentication-flow/….
• Broken: a 302 back to your app’s redirect URI with error=… in the URL. The error name tells you what Authentik didn’t like.

What I learned

• “Malformed request” in the browser doesn’t mean the client is wrong. Read the identity provider’s server log before you change anything in the app.
• The admin interface and the API don’t create the same object. The interface fills in defaults, the API stores exactly what you send.
• A curl test of the authorize URL checks a provider in seconds, without logging in.

How the blog login is set up end to end is in Single sign-on for WordPress with Authentik. All provider fields are described in the official Authentik documentation.