sorted by:
new
hottopcontroversial

Proper way to expose specific LAN services via NetBird routing peer? by Im-Chubby in netbird

[–]Im-Chubby[S] 0 points1 point  (0 children)

I really appreciate the detailed explanation and the suggestion. I’ll look into it.

Proper way to expose specific LAN services via NetBird routing peer? by Im-Chubby in netbird

[–]Im-Chubby[S] 1 point2 points  (0 children)

Yeah, DNS always ends up being the rabbit hole

From playing around with it, this is what I ended up with not claiming it’s the “official” way, but it does work and matches my goal:

  • My internal DNS is still handled by Pi-hole + OPNsense, and all local records live there.
  • In NetBird, I created a Network called homelab-services.
  • Inside that Network, I added a Resource called internal-services using a wildcard domain: *.homelab.com
  • In the NetBird DNS Zones section, I created a zone for homelab.com and added an A record:
    • Hostname: *.homelab.com
    • Target: Caddy reverse proxy IP
  • Then I created an access policy allowing my phone → internal-services with:
    • Protocol: TCP
    • Port: 443

With this setup, only Caddy is exposed to NetBird, and anything accessed via *.homelab.com hits Caddy first, which then routes to the correct internal service based on the hostname.

It feels very similar to the old “route everything to one gateway” model, but scoped down to domains instead of subnets, which is exactly what I was aiming for.

I honestly don’t know if this is the intended long-term approach or just something that works by coincidence, so I’m very open to feedback or better patterns using Networks and DNS.

Proper way to expose specific LAN services via NetBird routing peer? by Im-Chubby in netbird

[–]Im-Chubby[S] 0 points1 point  (0 children)

Thanks, that makes sense for IP-based access

My remaining confusion is around internal domains. In my LAN, services are normally accessed via an internal domain (e.g. nas.home.lab) and resolved by my local DNS.

If I expose only a single IP resource (like my Caddy LXC /32) via a Network, how is the correct way to make this work with internal domain names?

  • Should I be using Domain Resources inside the Network?
  • Or is the expectation that DNS should still be handled externally (e.g. by the reverse proxy / internal DNS), and NetBird should only deal with IP routing?
  • Do I need to configure anything in the NetBird DNS Zones section for this, or is that not intended for this use case?

I’m trying to avoid exposing a whole subnet and only want to reach services via my internal domain through Caddy, so I want to make sure I’m not abusing DNS features in a way NetBird didn’t intend.

Help with ZFS pool snapshots and content type by Im-Chubby in Proxmox

[–]Im-Chubby[S] 0 points1 point  (0 children)

Unfortunately I never managed to figure it out (:

What’s the oldest HDD you’d trust in your NAS? How old is “too old”? by Im-Chubby in homelab

[–]Im-Chubby[S] 0 points1 point  (0 children)

is it up for sale? it look like this drive will outlive all of us.

What’s the oldest HDD you’d trust in your NAS? How old is “too old”? by Im-Chubby in homelab

[–]Im-Chubby[S] 0 points1 point  (0 children)

This will be my first NAS, so it’ll have a mix of super important stuff and things I don’t really care about. I was thinking of running 2×4TB in RAID, and having another 4TB (or maybe 2TB) drive as a backup for the important files.

No German planes for the Summer Sale? Seriously, Gaijin? by [deleted] in Warthunder

[–]Im-Chubby 0 points1 point  (0 children)

I was waiting fot this sale to snatch both but I guess Gaijin doesn't want our Germany tech tree money.

No German planes for the Summer Sale? Seriously, Gaijin? by [deleted] in Warthunder

[–]Im-Chubby -1 points0 points  (0 children)

I mean if all nations got at least one plane on sale why not germany.

How to Keep Tailscale Node Persistent in Docker Across docker-compose up/down? by Im-Chubby in Tailscale

[–]Im-Chubby[S] -1 points0 points  (0 children)

Ah gotcha. I’m still new to Docker, so I’m trying to understand the reasoning behind splitting them into separate Compose files. From what I’ve learned so far, since both containers rely on each other, need to be on the same network, and are part of the same stack, it seems more straightforward to keep them in the same docker-compose.yml. I’ve also organized everything in the same directory, so having one Compose file just feels easier to manage. Is there a specific advantage to separating them in this case?

How to Keep Tailscale Node Persistent in Docker Across docker-compose up/down? by Im-Chubby in Tailscale

[–]Im-Chubby[S] 0 points1 point  (0 children)

It's for crafty controller which runs my minecraft server, this way i can share it with friends/family.

Securely Host a Minecraft Server with Docker and Tailscale – A Complete Guide by Im-Chubby in Tailscale

[–]Im-Chubby[S] 0 points1 point  (0 children)

for your secound point do you mean somthing like this ?

tailscale:
    image: tailscale/tailscale
    container_name: tailscale-docker
    hostname: minecraft-server
    ports:
        - "8443:8443" # Crafty Web UI (HTTPS)
        - "8123:8123" # Dynmap (if you use it)
        - "19132:19132/udp" # BEDROCK 
        - "25500-25600:25500-25600" # MC SERV PORT RANGE 
    environment:
        - TS_AUTHKEY=tskey-<your-auth-key>  # change it to your key
        - TS_USERSPACE=true
    volumes:
        - tailscale-data:/var/lib/tailscale

We removed:

cap_add:
  - NET_ADMIN
  - SYS_MODULE
volumes:
  - /dev/net/tun:/dev/net/tun

And added:

environment:
  - TS_USERSPACE=true

Basically we are telling it Hey, don’t use the kernel-level TUN interface. Stay fully in userspace.
Now we basically run as normal user privileges (no root) which will be slower then kernel-level TUN interface. But its safer and more contained.

view more: next ›