binhex

OK so i have put in a fix for the authentication as the path to the generated password file has changed and thus for me (and others) authentication was failing, you weirdly seem to have the opposite problem!, so are you saying authentication was working for you up until the latest build?.

So you did not set any password in the syncthing web ui and yet its prompting for username and password?. This is what i see on first startup, did you set authentication and then forget what you set it to?:- If i click on OK from the above screenshot and do nothing else and then restart the container i get no prompt for credentials.

OK im out of ideas then :-(, all i can say is this is working for the majority of users including myself, so there must be something odd going on with your configuration somewhere.

OK cool, so i did have a bug related to this several weeks ago, lets ensure you are running latest:- 1. go to unraid webui/docker left click docker container and select 'edit' then click on 'advanced view' top right and check the repository is set to binhex/arch-qbittorrentvpn with NO tags specified, if all good then cancel out. 2. go to unraid/docker main screen, toggle 'advanced view' and click on 'force update' for the container.

Check the dns for the delugevpn container, i have seen slow response from DNS watch NS's so try removing 84.200.xxx.xxx from NAME_SERVERS, also ensure you stop all containers running through delugevpn before doing this or unraid gets it's knickers in a twist.

OK go to the 'terminal' of your unraid server (not the container) and type the following:- dig @1.1.1.1 www.google.com this will prove if you can resolve names from your host, i expect it to fail, if it passes (resolved to an ip address) then set NAME_SERVERS to 1.1.1.1 only (remove all other entries) and apply and monitor the log.

you have something blocking dns on your lan, from your log:- Error: error sending query: Could not send or receive, because of network error 2024-08-07 19:08:04.695421 [debug] Having issues resolving name 'sanjose.privacy.network', sleeping before retry... running pihole, opnsense, pfsense?, check for blocks on port 53.

That is a good catch!, but ultimately the list of endpoints should of been shown, so something else was going on here - unless you removed them from the log file?.

mangle is still checked for and it CAN be dynamically loaded so generally that can be ignored, i may remove that from being logged. The real weird issue here is that the list of port forward enabled endpoints is not being generated, which is leading to a false detection of the endpoint NOT being in the list, i need to account for that in the code, but the strange thing is i literally just restarted my container now and i got the list of port forward enabled endpoints no issue, so maybe it is a transitory issue, from @jermcel log:- 2024-08-08 12:46:41,868 DEBG 'start-script' stdout output: [info] PIA endpoint 'ca-toronto.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:- 2024-08-08 12:46:42,607 DEBG 'start-script' stdout output: [info] List of PIA endpoints that support port forwarding:- 2024-08-08 12:46:42,608 DEBG 'start-script' stdout output: [info] Script finished to assign incoming port

set STRICT_PORT_FORWARD to 'no' if you do not want an incoming port or switch to one of the endpoints listed in the log that does support port forwarding.

i will be fixing the doc deficiencies in the future, but for now in a nutshell the shared docker volume is used to store the assigned incoming port, this info can then be used by the end user to configure applications running through a single vpn connection, of note there is currently no mechanism to auto update applications based on this information, and as any application could theoretically be sharing the vpn network it would be up to the end user to script this.

one way is to restrict the ram usage for the container, you can do this by clicking on edit of the container, then toggle advanced view and in extra parameters define your max ram usage, e.g. to allocate 2GB of RAM enter --memory=2G

That all sounds correct to me, not sure why you are suffering low ul rates, just double check the incoming port is visible from the outside, Please see Q9 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

thats odd, i have just checked and the image is definitely up to date, set the tag back to latest then go to docker web ui toggle advanced view and click on 'force update'.

Sorry just tried it again, clean config, no previous image and it came straight up!, what version of unraid are you using? for ref im using 6.12.10

That's because i am still in the process of updating all the templates to include it, and do note that template changes are not pushed out to users, you would need to refresh your template by deleting the container and reinstalling from CA. Its a docker volume that includes a simple file that contains the assigned incoming port, the end user would then need to work out how to use that port number to configure the application, some apps are harder than others to configure. It is not a host path, its a docker volume so you will not be able to see it or browse it from your host, its only visible from containers that have the docker volume mounted, if you want to see the contents of the docker volume then drop to the 'console' of a container and do 'ls -al /shared' That is a bug in that plugin, it looks like it does not support docker volumes and is assuming (incorrectly) that its a docker bind mount and thus is trying to find the host path 'binhex-shared' which does not exist - ignore it.

its difficult, as wireguard does not natively support this so it would require some additional bash coding to get this working, its not a nno i won't ever do this but it does require a fair bit of effort, i will put it on my ever growing list of to-do's.

that's your problem, your pc is on a different network to your container, append your computers vlan to the list using a comma for LAN_NETWORK, so it ends up looking like:- '192.168.100.0/24,192.168.102.0/24'

ok that all looks fine, your log shows nothing wrong and your LAN_NETWORK is defined correctly, try access from another browser, if not try another machine, there maybe anti virus or similar blocking access to port 8080 perhaps.

what is the ip address of the machine running the web browser?

sorry no, what is 'magic dns'?

PIA are still doing OK in my opinion, cheap and more importantly have a track record for 0 logging, their latest transparency report is out:-

just tested and it works for me, i can see the web ui, so i can only conclude that your config is causing the issue, try renaming your host path for /config so that the container re-creates it then reconfigure the app.

you need to delete your user template from unraid:- go main docker tab in unraid web ui click on 'add container' (yes its non intuitive) click on select a template and ensure you are under 'user templates' section and select the template you want to delete click on the X to the right of the template name and confirm deletion go to CA and install the app and reconfigure.

try this, open your openvpn config file, change this line:- cipher aes-256-gcm to:- data-ciphers AES-256-GCM taken from here:- https://discuss.freedombox.org/t/solved-openvpn-depreciated-cipher/2625