That all makes sense and tried setting it up that way but could not get it to work. I am not sure if it was an issue with my network, k3s, Kube-VIP, or Traefik (or some combination of them). I will try getting it to work again.

Even if I do though, I would run into an issue if I publicly exposed these services (I understand there are security implications of doing so). How would I route traffic received externally/publicly on port 22 to more than one IP address? I think I would only be able to do this for local/internal traffic by managing the local DNS.

I guess I need to dig in a little deeper. I am currently only using Kube-VIP to provide a single IP address for the control plane. I think I may have it configured wrong though since that same IP address is the single load balancer IP used by Traefik.

I have struggled finding good documentation, hints, tutorials, etc. setting up Kube-VIP with Virtual IPs. Is there anything that you are aware of that might provide some assistant in setting that up correctly?

The steps below are high level, but should provide an outline of how to accomplish what you’re asking for without having to associate your IP address to any domains nor publicly exposing your reverse proxy and the services behind the reverse proxy. I assume since you’re running Proxmox that you already have all necessary hardware and would be capable of completing each of the steps. There are more thorough guides available online for most of the steps if you get stuck on any of them.

1. Purchase a domain name from a domain name registrar
2. Configure the domain to use a DNS provider (eg: Cloudflare, Duck DNS, GoDaddy, Hetzner, DigitalOcean, etc.) that supports wild card domain challenges
3. Use NginxProxyManager, Traefik, or some other reverse proxy that supports automatic certificate renewals and wildcard certificates
4. Configure both the DNS provider and the reverse proxy to use the wildcard domain challenge
5. Setup a local DNS server (eg: PiHole, AdGuardHome, Blocky, etc.) and configure your firewall/router to use the DNS server as your DNS resolver
6. Configure your reverse proxy to serve your services via domains with a subdomain (eg: service1.domain.com, service2.domain.com, etc.) and turn on http (port 80) to https (port 443) redirects as necessary
7. Configure your DNS server to point your services’ subdomains to the IP address of your reverse proxy
8. Access to your services from anywhere on your network using the domain name and https when applicable
9. (Optional) Setup a VPN (eg: OpenVPN, WireGuard, Tailscale, Netbird, etc.) within your network and connect your devices to your VPN whenever you are away from your network so you can still securely access your services remotely without directly exposing any of the services to the internet

I feel silly for not realizing that the SSH config would be used by Git!

I thought if Forgejo’s SSH service listened to a non-standard port that you would have to do commands with the port in the command similar to below (following your example). I guess I assumed Git did not directly use the client’s SSH service.

git pull git@git.mysite.com:1234:user/project.git

people often seem to have a misinformed idea that the first item on your dns server list would be preferred and that is very much not the case

I did not know that. TIL that I am people!

Do you know if it’s always this way? For example, you mentioned this is how it works for DNS on a laptop, but would it behave differently if DNS is configured at the network firewall/router? I tried searching for more info confirming this, but did not find information indicating how accurate this is.

I think I can avoid using metallb since I’m already using Kube-VIP.

I do not think that I am using Virtual IPs correctly as I tried setting it up, but it did not work. I assume the Virtual IP would just become the Load Balancer IP and I would need to configure Traefik and Kube-VIP (as well as my network) to use the Virtual IPs?

Depending on the network’s setup, having Pihole fail or unavailable could leave the network completely broken until Pihole becomes available again. Configuring the network to have at least one backup DNS server is therefore extremely important.

I also recommend having redundant and/or highly available Pihole instances running on different hardware if possible. It may also be a good idea to have an additional external DNS server (eg: 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) configured as a last resort backup in the event that all the Pihole instances are unavailable (or misconfigured).

The thing that makes casting so appealing for me is how ubiquitous it is. It eliminates situations with guests where they would recommend a show/movie only to find out that I can’t easily play the content because it’s only available on a streaming service that the guest pays for and I do not. As long as the guest brought a device and connected it to my WiFi, it more than likely could be casted without having to install another app and/or sign up for a new service (or have the guest login with their account).

I am becoming less optimistic about it though. I just do not think that the level of ubiquity that Chromecast reached even 10 years ago will be matched with a FOSS alternative. Developers would need to incorporate it into their apps, websites, etc. or it would need to be compatible with existing solutions. I doubt Google will open Chromecast up enough so other options can be fully compatible with it. Additionally, without the backing of a major corporation, I do not see developers taking the time to make their content compatible with another casting option.

This would only work if there is no other traffic on the port being used (eg: port 22). If both the host SSH service and Forgejo SSH service expect traffic on port 22, then this would not work since server name indication (SNI) is not provided with SSH traffic and Caddy would not be able to identify the appropriate destination for multiple SSH services traffic.

I do not think what I would want as a replacement exists (yet). My main requirements are:

• Only FOSS software and firmware
• Similar level of “casting” compatibility/ubiquity as the discontinued Chromecast
• Easy navigation and/or great UI/UX
• Can be controlled with a stand alone remote control, phone/tablet/laptop, and remote services like Home Assistant
• As portable and low powered as the discontinued Chromecast (or no less portable than a small mini-pc)
• Ability to turn on/off the TV, switch inputs, and control the volume
• Ability to install apps/plugins to directly on the device (maybe even things like Lutris, Moonlight, or something similar for gaming)
  • Ideally, the apps would be as well maintained and provide similar levels of quality as something like an Android TV or Apple TV
• (bonus) Ability to store media locally for offline playback

I think the closest I have seen is LibreELEC + Kodi on a RaspberryPi or mini-pc. It’s still not quite there for my tastes though. Hopefully the recent Chromecast announcement will lead to more/better alternatives in the coming months!