Just started trying to figure out the containers feature, by using the pihole "app" from the catalogue - and I can't figure out how to configure it to use an ip address on the lan, instead of setting up a bunch of port forwards. I don't really want ports per container, as i find that much harder to remember and reason about than just giving each running service an address.
As an aside: I noticed when I first clicked "enable", that it was set up with an SSL certificate by a 3rd-party cloud provider to have a url (and not even a particularly memorable one at that, so the usefulness seems quite limited). This happened even though I have cloud functionality disabled - any ideas on how to truly disable cloud services so this can't accidentally happen again would be much appreciated, alongside undoing any entries that might remain on those external services, which are undocumented in the manual.
Given that the device im using is a WiFi router, and your linked article specifically advises against using this with WiFi, I’m afraid it’s not very helpful to my situation, but thanks for the link at any rate
Because my article warns you of a situation you might not have even considered, it has helped you to realize why your wish in this instance will run you into unforeseen trouble. I'd call that quite helpful indeed.
The problem is endemic in the wish, not my particular approach to the solution.
I would still try the bridged veth solution anyway. And if trouble arises you instantly know because you've been warned. And if it works against all warnings, it's even better.
You should not repeat my misuse of the word "endemic" then. "Endogenous" is better.
And, it's not that you cannot do this, just that it's liable to cause trouble, thus inadvisable.
For the curious, here is where I learned what happens in this case, first by experiencing it, then chasing it to the KB article linked, thinking it was a Parallels bug. It is possible that some WiFi implementations are smart enough to work around this intelligently, at RF rate, possibly even MT's since I originally ran into that.
Given that your reply didn’t help me achieve the result I am looking for, I’d call that unhelpful.
In fairness, my OP didn’t mention that it was a WiFi router, but after reading what you linked I came back to report that, thank you for sharing, but it’s not helpful in this scenario.
If you wanted to say “I don’t know how to achieve that” - there you go. Fewer words, and a much clearer meaning.
@tangent's link was perfectly on topic. And would be actually the solution to your question. Set the veth interface to dhcp=yes and bridge it. What other than that would be the better perfect answer to your question??
One that would work for the setup I have. As I mentioned, the router I’m running the container on is a WiFi router, and the article explicitly states “Do not attempt to apply this article’s solution over WiFi.” Not ‘this is unadvisable’ or ‘go forward with caution’. Literally ‘do not do this’.
I do acknowledge, though, that sticking only exactly to the question as originally asked, which did not include the information that there’s a WiFi network in the bridge, that the answer might be applicable, if it were an Ethernet-only setup. I have since appended that, though, so I think it’s fairly clear that that is part of the situation by this point, isn’t it?
I’ve come here, to admit my ignorance in an area of knowledge, and ask for input from the ostensibly more knowledgeable / experienced. Wouldn’t it be pretty arrogant of me to look at a warning such as that, shrug, and go ‘guess I’m gonna do it anyway’?
"Using this with WiFi" and "On a WiFi router", as I read it, are two different things . . .
Unless this router is using a wireless station bridge for access as opposed to a cable, I don't think that statement is relevant, and the presence of WiFi in the hardware is not significant.
Myself, I'd try the VETH on the bridge . . . I run an AdGuard container that way, and it's been flawless.
Do you think you could help clarify? I thought, from the article, that the issue would be having the veth participating in a bridge where a WiFi ap also participated, because the ap would not be able to handle passing packets for multiple MACs upstream to the router and container. How are you reading it differently? (for the sake of improving my understanding)
PiHole (much like AdGuard) is a pretty low traffic app, so unless you are doing this on a really low end device, I doubt the load would be relevant. After all, WiFi or not, to the bridge, it's just ehternet packet traffic . . .
The hw offload issue might make me want to follow the recommendation of using a second bridge, though.
At the end of the day, there is little to lose by trying it. If something isn't right, just drop the config.
If you have an ARM64 (or X86) router, you can use the /app feature. /app feature does have pihole app specifically, but it's allows a custom app that does all the /container .../veth .../firewall/nat things automatically for other that are not a built-in app - so you don't have to worry about manually maintaining port forwarding since /app can manage that for you.
As @tangent try to note, it's a choice to bridge VETH with potential tradeoffs. The main issue is you can "slow down" your bridge by forcing it through the CPU on some (perhaps most) common routers.
Now there might be a better case if the container did expose a lot of ports. But PiHole is essentially 1-3 ports (port 53, web admin, maybe 443 for DoH), and you keep pihole off your main network... Anyway there are case for bridging a VETH to a LAN/VLAN bridge, but I'm not sure PiHole be a good one, and at most three NAT rules avoid unwinding how VETH react on your router on your network.
Perhaps I did something odd . . . I did my AdGuard (tried PiHole as well) as a manually configured container, with a VETH to a second bridge, albeit on a different internal subnet. I simply put that bridge in the LAN group, and traffic flows internally with no other intervention, and it is protected from external access by the existing fw rules, and can get to upstream DNS via the existing masquerade NAT rule.
It's been working for months, and no performance issues . . . Was/is this a bad idea?
I think "bad" may be overstated. But you can break hardware offloading be my concern when bridging VETH. It does work fine, that's not the issue. And there are also other subtle issue around this too. Like, for example, the VETH can become the bridge MAC with auto-mac=yes, which then potentially have some complex side-effects.
In terms of security, firewall is fine. But you can easily make a mistake and have a linux box you downloaded from the internet running on the LAN with access to all hosts on same LAN it's bridge. By running a container on its own bridge and/or "standalone" VETH (not bridge to anything, just a plain interface). Not saying the PiHole folks are doing bad things, but there is always potential for supply-chain attacks since PiHole does have a lot of dependencies... so if one of those had some vulnerability, it have opening to the LAN-side of your network.
Anyway, I don't think it's end of world issue - especially since you say it's been working fine. If bridge goes via CPU and you're not maxing out network, it really isn't an issue even if it did break hardware offload.
But I do think /app's scheme to automate the port mapping is the "right" approach, if you have a ARM64 router, since it started isolated from LAN (granted with access to other containers), and only what is needed is "punched"/NAT'ed to the /app container, its a bit easier than mucking with your firewall/etc config when /app can manage this all in a reasonable way.
Considering the multiple IP blocks I have locally, I guess I figured that a lot of this traffic was CPU bound anyhow, so am not really concerned about the trivial addition of DNS needing to route. AdGuard does need to reach out some to maintain it's lists, the there is the need for the NAT out, although the upstream DNS is my own domain server, not an ISP (although external DNS is configured as a fallback). IP is static, and yes, it does look like the bridge took the MAC of the VETH, but not sure that matters since it is the only thing on this bridge at this time. AdGuard does not appear to auto-update, so seemingly zero risk there letting it see out (well, no more than any other system.)
Oh, and primary bridge hw offload seems to be working well . . . pulling about a full GB across the bridge to the outside world.
Call me old-school, but I prefer to build most things by hand, so I know what I have . . . My entire server environment for the domain is source built . . . (heck, running AdGuard as a Docker image chaps me a bit . ... but the gain exceeds the risks).
It can manage the setup for me, it can't manage the memorisation. I'm used to being able to just assign an address in my network where I can access a given resource. I want to do that with the virtualised services provided by containers in much the same way as one would with a pihole running on a physical server. 192.168.pihole.address/admin and... in. No per-service port memorisation because they're all sharing the same external ip and need everything set up with forwards.
Pihole is just the thing I was configuring at the time, as an example. It's not the only service that is / will be running on my network, some of which will be containers on my MT. Whether we agree on how many port forwards to manage is "many" is besides the point though. For me, it is, which is why I am seeking a solution in this form of having the container reachable by its own internal IP, so that I don't need to also memorise the ports.
TL;DR It was less about not configuring / maintaining the ports manually, and more about not having to use them once deployed.
to say "you can't do that", I might re-use this if you don't mind.