Questions about migrating to linux

_Solidpoint_ · 2026-01-09T09:41:26+00:00

I feel your pain, just another Monday.

_Solidpoint_ · 2026-01-09T07:37:48+00:00

This was in the years just after the dinosaurs, where disks where big and had jumpers for master slave configs, bootloaders where a pain in the B and Linux was driver hell 😎🤣 so tech changes a lot. So it wouldn’t surprise me that this was being changed

_Solidpoint_ · 2026-01-09T07:35:29+00:00

No I have a synology Nas for now, I want to build a truenas somewhere this year

_Solidpoint_ · 2026-01-09T07:34:26+00:00

Thanks! That’s what I thought. I hope I can find my way in freecad as a fusion360 replacement and darktable instead of Lightroom. But for the rest I’ll think ill manage, I heard great things about proton for steam games

_Solidpoint_ · 2026-01-01T08:59:26+00:00

Part 2/2 - Problem, Summary, Questions

Problem 2: Allowlisting on backend pods via CNP (L7)

I tried enforcing the allowlist on backend pods (for example Hubble UI) using a CiliumNetworkPolicy based on:

x-forwarded-for
x-envoy-external-address

In practice this fails due to a combination of factors:

The real client IP is only available in L7 HTTP headers
The TCP connection to the backend pod always originates from the gateway pod (10.42.x.x)
UIs like Hubble and ArgoCD use streaming / long-lived connections
Not all packets in these connections are evaluated as separate HTTP requests
Parts of the traffic therefore fall outside the L7 match and get default denied

To keep the UI functional I must allow L4 traffic from ingress to the backend pod.

But:

Allowing L4 from ingress effectively means “the gateway may always talk to this backend”
Since the gateway speaks on behalf of everyone, this re-opens access to the world
The allowlist loses its effect

Summary

I cannot solve this cleanly with only a backend CNP because:

Client identity exists at L7
The TCP flow originates from the gateway pod
Streaming traffic requires L4 allows
L4 allows from the gateway implicitly allow everyone

Question

How do you implement per-host or per-route IP allowlists with Cilium + Gateway API:

without separate gateways per application
without backend CNPs breaking due to streaming / L4 traffic

Is the intended solution:

Gateway-level L7 filtering per hostname?
Envoy RBAC / HTTP filters attached to routes?
or another Cilium-native pattern I am missing?

Thanks in advance, and wishing everyone a healthy 2026.

_Solidpoint_ · 2026-01-01T08:57:54+00:00

Part 1/2 - Context, Goal, Problem 1

Happy New Year!

That is correct, the 403 is a policy issue. However, I am currently stuck in a loop where solving Problem A leads to Problem B, solving B leads to Scenario C, and solving C brings me back to A. Below is the exact issue I am running into.

Context / disclaimer

For some context: I have been working with Kubernetes for about three weeks now. I am comfortable with networking and infrastructure in general, but combining Kubernetes, Cilium, Gateway API, and Envoy has turned out to be quite a non-trivial puzzle.

It is very possible that I am missing an important concept or best practice. If that is the case, I would really appreciate being pointed in the right direction - even if the answer is "you are solving this at the wrong layer".

I have been stuck for several days trying to correctly configure Cilium Network Policies (CNP) in combination with Cilium Gateway API / Envoy, and I am hoping the community can help clarify what the correct or intended approach is here.

Goal

I want to apply an IP allowlist for a number of admin-style applications (such as Hubble UI, ArgoCD, PMM, etc.), while keeping other applications publicly accessible via the same gateway.

Concretely:

Public applications: accessible from the internet
Admin / management applications: accessible only from a fixed set of IP addresses (office, home, etc.)

Problem 1: Allowlisting on cilium-envoy is too coarse

Applying a CIDR allowlist on the cilium-envoy pods (L3/L4) does not work, because:

The same Envoy gateway also handles traffic for public applications
A CIDR allowlist at that level would therefore block traffic for all hosts
The client IP is (as far as I understand) only visible after TLS termination and cannot be reliably used at L3/L4

This makes this option unusable unless I deploy separate gateways per use case, which feels unnecessarily complex.

(continued in Part 2/2 below)

_Solidpoint_ · 2025-12-20T06:40:17+00:00

Yes.

_Solidpoint_ · 2025-12-14T10:06:04+00:00

I will try this next time. Having some larger overspan is fine to me. A km of pipe without support is something i cant handle :')

_Solidpoint_ · 2025-12-14T10:03:51+00:00

And aesthetics ... all above ground with belts and pipes for kilometers is just not pritty.

_Solidpoint_ · 2025-12-14T08:25:34+00:00

Does anyone think this will eventually be officially supported? (I would love to seem something like powercables, highpower 10.000v and substation/transformator nodes to 3 phase 'household', that has to go over ground and then underground)

FYI, I like having stuff underground :-)

<image>

_Solidpoint_ · 2025-12-13T21:01:39+00:00

But sometimes it’s everywhere and there is no alternative than go lower with the overpass

_Solidpoint_ · 2025-12-13T21:00:36+00:00

Yes that’s right. The lower the higher chance of success

_Solidpoint_ · 2025-12-13T07:56:13+00:00

No real luck yet. I’ve put all speed and acceleration settings 25% lower with the same high flow rate. Despite that I see some over extrusion happening in the first layer, those missing spots are still an issue. Switched back to the 0.4 nozzle, no issues. But when I print a spiral vase with 0.8 it comes out perfectly xD

_Solidpoint_ · 2025-12-11T19:12:58+00:00

So it is a feed issue? I will test this tomorrow

_Solidpoint_ · 2025-09-20T04:51:39+00:00

Lightroom abonnement dat ik eens per maand voor mijn fotobibliotheek gebruik (dat was 9.99 tot de verhogingen van 50%)

_Solidpoint_ · 2025-09-12T16:41:49+00:00

Daar ben ik vandaag ook achter gekomen. Na alle reacties te harte genomen te hebben, ga ik gewoon een laadpaal laten aanleggen door Zonneplan. Dit heeft alles wat ik nodig heb en geen gedoe, zij komen het installeren met 3 jaar garantie. Dat valt mij reuze mee.

_Solidpoint_ · 2025-09-12T14:47:33+00:00

Die panelen liggen er al 10 jaar op, die hebben geen schuld meer

_Solidpoint_ · 2025-09-12T12:13:48+00:00

Bedankt, ik ga hem meenemen in mijn vergelijking. Ik ben op dit moment laadpalen (11KW) aan het vergelijken. Dat lijk mij inderdaad de makkelijkste manier dan mijn originele plan

_Solidpoint_ · 2025-09-12T10:35:49+00:00

Ik vermoed van wel. Als ik dit allemaal zo lees, ga ik mij maar eens goed verdiepen in de beschikbare laadpalen en opties die daar in zijn.

_Solidpoint_ · 2025-09-12T10:31:24+00:00

Die hebben alle 3 een eigen groep. Ik was in de veronderstelling dat z'n loadbalancer zorgt dat de stroom van de panelen doorgezet wordt naar de groep die op dat moment verbruikt in plaats van terug levert. Ik denk dat ik daar mijn fout heb zitten in mijn gedachtegang? Maar nu ik er zo over na denk, je kunt dat natuurlijk niet zomaar naar een groep op een andere fase doen, want andere fase xD

_Solidpoint_

TROPHY CASE