vocoder

Well, food for thought: A docker healthcheck that determines if WG is up could be made. In any case, I personally would love such a feature. If you implemented this, a reasonable docker compose file would prevent the situation in the linked issue (as any linked container service could have defined within the docker-compose.yaml : `depends_on: arch-privoxyvpn service healthy) and perhaps there could be a override to let it work 'the old way' with this caveat DNS wise at the beginning, or some kind of adaptation to let it work? In all honestly, I do this with most every other container with dependencies and it feels like the right way to go instead of a footrace. Docker does a great job at making sure containers respect their dependencies. It will start/restart/stop stuff if it needs to. But again, I guess you'd be solving my issue, and maybe some other edge cases. But in reality, most people should have dependency chains for something like this anyway. The fact that it works without it, is cool, but it leads to stuff starting with errors that refresh themselves away. (e.g. maybe .arr programs trying to connect to something too quickly)

Any chance there could be a ENV var for a DNS server used only to resolve the wireguard endpoint? I know that's asking a lot... Maybe resolve & cache, then flush & launch container? Is it even possible? Going to study that issue now. Yep that's most certainly what caused it. There has to be a way to cache DNS though with nslookup or dig then use whatever DNS you want after you're happy with the endpoint IP. (it can cache the PIA VPN endpoint to IP to /etc/hosts), then if it fails to connect it could remove it from /etc/hosts to try and re-resolve. But alas, I appreciate all of your continued efforts on this project, and well, it's not a simple issue and I understand your stance so if you can't fix it, thanks anyhow! Edit #2, nevermind, I see. thinking now.

I had this exact same thought, lol. According to my internal DNS logs, it looks like the container is reaching out to my DNS servers properly in the previous build, but cannot in this new one. Specifically, it can resolve `us-newjersey.privacy.network` and let itself move on. I know for a fact it doesn't use my DNS after that, because I block everything internally DNS wise I use on the VPN but that all works on the container network after wg is up. I assume (in previous builds) it knows where to go based on the host container base settings, then once it does the iptables or whatever, it rewrites the resolv.conf. My hypothesis on why it worked before. Now it might start with a modified resolv.conf and never work; if that makes sense. But it might be something totally different, hope that helps.

1. I could do that, but like I said, it worked better in the old version (wish I knew what changed), so unfortunately I'm sticking with that for now. I have no desire to let clients on my network go to cloudflare directly to resolve DNS. 2. VPN_NAMESERVERS is just what I called NAME_SERVERS in my `docker-compose.yaml > .env`. Sorry for the confusion. The variable is not being transposed or declared wrong, its just redeclared in my .env. (NAME_SERVERS: ${VPN_NAMESERVERS}) 3. I'm not saying I know how this whole thing works, I'm trying to provide you useful debugging information. Before, `:latest` I am able to bring up any of your containers without changing my firewall rules. Thanks again.

[root@eff812cdf72f /]# iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT Couple notes if they help: 1. I'm not running UNRAID, I could move this to github if it's more appropriate. `6.7.9-amd64` Debian on a generic Desktop build via docker compose. 2. I'm using pihole as a DNS sink, and queries that aren't to my internal DNS over port 53 get blocked. With 3.0.34-3-02 and before, this combo played well with `VPN_NAMESERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1` Even though my router will only allow port 53 traffic to 10.2.10.10/10.2.10.20. Seeing the iptables, had me thinking I could use the internal DNS to my network on the NAME_SERVERS env. Well, that worked (VPN_NAMESERVERS=10.2.10.10,...) better but some services still don't reverse proxy as expected, but wg went up in the privoxyVPN container. I don't know what's different between the 2 containers, this also happens with your others. I'd prefer not to use my internal DNS for any of this if possible explicitly.

Same result log.txt

Here it is. log.txt

Hello, something in the new image has completely changed the ability to reverse proxy internally. For example, if I had a service running port 3000, with `network_mode: service:arch-privoxyvpn` , I could tell nginx, which is on the same docker network as arch-privoxyvpn to go through upstream arch-privoxyvpn:3000 to get to that service directly, and nowhere is port 3000 accounted for in the config, it would just work because it's on the same internal docker network. You didn't need to use `VPN_INPUT/OUTPUT` ports (thankfully) Now it looks to not work. Curiously I got an error about `SHARED_NETWORK` not being configured, thus defaulting to 'no'. It sounded interesting, I tried 'yes', didn't help. I couldn't find any documentation about this. Either way, that didn't help with this either. This also impacts the other images. I'm also getting an IPv6 error (I explicitly disable IPv6 everywhere, host, container, compose). ``` modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/6.7.9-amd64 ip6tables v1.8.10 (legacy): can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?) Perhaps ip6tables or your kernel needs to be upgraded. 2024-07-02 09:39:44.104593 [warn] ip6tables default policies not available, skipping ip6tables drops Error: error sending query: Could not send or receive, because of network error ``` 3.0.34-3-02 has no issues. Just wondering how to go around this if it's intended, or if that's possible. For now the old versions work, so no worries. Thanks for the great VPN container.