binhex

Overview: Support for Docker image arch-fleet in the binhex repo. Application: Fleet - https://www.jetbrains.com/fleet/ Docker Hub: https://hub.docker.com/r/binhex/arch-fleet/ GitHub: https://github.com/binhex/arch-fleet Documentation: https://github.com/binhex/documentation If you appreciate my work, then please consider buying me a beer 😁 For other Docker support threads and requests, news and Docker template support for the binhex repository please use the "General" thread here

correct again

Just in time for Friday night, aaaaaaaaaaand relax! 🙂

can you explain what you mean by VPN tunnel? do you mean unraid wireguard tunnel, or sharing a vpn network with another container, or something else?

i think you are 'EDIT'ing the container, its one step up from that, the main docker screen showing all the containers:-

Ok guys a new image has been produced, for anybody with the name resolution issue please do the following:- login to unraid web ui go to docker tab toggle switch top right to 'advanced view' click on 'force update' for the container check logs for errors.

Ok guys a new image has been produced, for anybody with the name resolution issue please do the following:- login to unraid web ui go to docker tab toggle switch top right to 'advanced view' click on 'force update' for the container check logs for errors.

Ok guys a new image has been produced, for anybody with the name resolution issue please do the following:- login to unraid web ui go to docker tab toggle switch top right to 'advanced view' click on 'force update' for the container check logs for errors.

I'm awaiting feedback from users on github, in the meantime can anybody with the name server issue try out tagged `latest` or `4.6.5-1-07` and let me know if it fixes the issue. Note: This is for qbittorrentvpn ONLY.

i'm aware of the issue guys and i think i have a fix, i shall post back when i have built a fixed image.

i'm aware of the issue guys and i think i have a fix, i shall post back when i have built a fixed image.

i'm aware of the issue guys and i think i have a fix, i shall post back when i have built a fixed image.

lol, it won't have, that is not maintained any more. i'm aware of the issue guys and i think i have a fix, i shall post back when i have built a fixed image.

I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

pull latest image, either 'check for updates' and apply or click on 'force update'.

please link to both so i can fix that. no built in web browser, nope, if creation of the config file for the cloud provider requires a web browser then i would advise running through the creation of the config first on a machine that has rclone and a web browser installed, maybe i need to reword Q1/A1 to be clearer:- https://github.com/binhex/documentation/blob/master/docker/faq/rclone.md

OK firstly a disclaimer, there is a ton of different network types you can use in Docker, i do not know all of them, and special edge cases such as bonding i have no knowledge of, but I do know that a 'network type' of 'bridge' will allow you to perform port mapping, whereas running the container in 'network type' 'host' does not permit this as there is no bridge to translate the ports, so you 'disabling bridging and enabling Host access' could be the cause of the loss of visibility of the ports. FYI - If you want to get up to speed with docker networking I would highly recommend watching an awesome video by Network Chuck, stick with it and concentrate, it starts off slow and easy and gets more in depth:-

Hey no rush!, i hope it all goes well for ya. I am pleased about that, but i can understand you may not be 🙂 if it makes you feel any better i have done this change for a good reason, honest, thus my recommendation NOT to rollback.

Local name servers will be able to resolve the endpoints but when a name resolution is triggered after the vpn tunnel is up you should find that name resolution fails and a /tmp/dnsfailure file will be created to indicate this, this will then result in the tear down and re-creation of the tunnel, which will cycle again doing the same, if this is not happening then i would be interested in seeing the output of your supervisord.log file with debug set to true. OK so the previous image allowed a small window on startup where name resolution for the endpoints would be done by whatever the host is set to use, in your case most probably local name server, it would then wipe the resolv.conf and re-create it with the defined NAME_SERVERS, this process of wiping out the resolv.conf has been brought forward and thus the window no longer exists (security reasons), forcing name resolution to only be done by the defined NAME_SERVERS, so that's how it previously did work and now does not. So the fix - permit outbound name resolution on OPNSense, or roll back to the previous image (not recommended).

Please see Q35 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

no probs, if you are thinking 'why would i want port forwarding in any case for a proxy server?' then the answer is that people do share networking from other container with vpn enabled containers such as this, and these other containers may require a working incoming port, e.g. torrent client, soulseek, etc

port forwarding support has been added to all vpn images, if you don't want to have to connect to a port forward enabled endpoint then set STRICT_PORT_FORWARD to 'no'

That is an interesting idea and would explain it, i have had to be more aggressive with blocking due to this issue, and thus the name resolution is now forced straight away and will only use the defined NAME_SERVERS (a good thing in my opinon), whereas before that code was further down the chain and thus a potential name lookup could happen using the hosts define name servers before the re-write of resolv.conf, so yeah I think this probably is the case, sadly though for you I will not be reversing this change due to the linked issue.

i have no idea how the previous version worked for you, if you are blocking port 53 then name resolution should only happen by your pihole, which will be blocked once the vpn tunnel is established. Ahh fair enough!. i appreciate the info!, I'm just letting you know that local name resolution will not work.

Isn't this your issue then?, remove this block and you should then be able to use public NS. what is this?, VPN_NAMESERVERS is an env var not defined for any of my images so it will do nothing, the correct name is NAME_SERVERS. No you can't, i actively block internal DNS to prevent ip leakage.