view the rest of the comments
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I don't think I know the reason for the issue you've described. I don't have enough information for that.
First thing would be: Is the routing and firewalling OK? Later: DNS. Even later: services reachable?
The Opnsense instance has configured multiple VLANs and zones too? With one server interface in each? The packets between the vlans take a path via the router?
I tried to give my server multiple interfaces on different VLANs once, but ran into problems with that approach. I then added one bridge interface per VLAN to the server and gave it just one IP on one vlan. That way the server isn't tempted to route things itself or deliver packets on a wrong interface. An entire class of possible errors was removed that way. Docker containers and VMs still can have IPs in their respective VLANs/ nets.
It is worth noting that docker firewalling and ufw don't play well together, which could be the reason for unreachable services. Moving the docker host into a LXC abstracts the issue away. Incus can run OCI containers itself and may be an alternative to docker (but not docker compose).
I can't say anything about over-engeering. It is a hobby after all and you decide what is important and how much complexity you need. :)
This. It took me a little fiddling to get it right
Answer to your first question, he dockers successfully resolve and access internet
I actually was having the same issue with the routing of server. How did you setup your bridge exactly? Do you mind sharing your netplan?
Netplan config? Sure:
I'm not sure if the version-property is still required. The only interface with an IP is br0.101. Opnsense provides DHCP (v4).
You can attach multiple ethernet-devices to a bridge (which I did not):
I'm not sure if you can attach the docker bridge via netplan - it has to exist at boot time, I think. My docker containers run inside a VM (kvm) with one interface, which sits in one of the VLANs. The VM's interface is a bridge device (br0.100). The VM ethernet device is attached to the bridge, it receives its IP from the router and behaves like a real server.
Thanks for sharing this, I'll give it a try and see how it goes
Bridge? There's your problem I think. Bridge doesn't allow ingress to individual IPs. In bridge, you tell each container what port it listens on, then access it from the IP of the host.
User defined bridges act differently from the default one as well. May not be relevant to your issue, but https://docs.docker.com/engine/network/drivers/bridge/#differences-between-user-defined-bridges-and-the-default-bridge
I mean at the moment I don't have any bridges setup (other than the dockers own bridge) I thought maybe I could solve my issue with bridging
Oh, hmm. How are you telling which service to be on which IP then? Could you safely post your compose file?
I will post it when I get my hands on it, but basically I made a macvlan which is using the server vlan, and then in the compose I set the network to that macvlan, which seems to be functional at least