search

binhex / arch-delugevpn

Docker build script for Arch Linux base with Deluge, Privoxy and OpenVPN
GNU General Public License v3.0
696 stars 112 forks source link

Options error: Maximum number of 'remote' options (64) exceeded #259

Closed c-hri-s closed 3 years ago

c-hri-s commented 3 years ago

Using the latest when I start I get the following two errors continually scrolling in the logs and the VPN doesn't start:

2021-03-01 08:56:32,161 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2021-03-01 08:56:32,173 DEBG 'start-script' stdout output:
Options error: Maximum number of 'remote' options (64) exceeded
Use --help for more information.

Reverting to binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01 solves the issue and the errors don't appear using the same config files.

My custom config file has three remote entries, not >64:

remote openvpn.njalla.no 1194
remote openvpn.njalla.in 1194
remote openvpn.njalla.fo 1194

I'm running on a Synology NAS.

Nelinski commented 3 years ago

I've got the same issue. Restarting the docker (in my case rtorrent) a few times works sometimes but can't seem to find a proper fix for it.

binhex commented 3 years ago

ok guys, so i got around to looking at this, the error being spat out by openvpn is 100% correct, if you look at the log you will see the number of 'remote' lines appended to the command line when starting openvpn = 64+ and thus the error. Now the reason why its happening all of a sudden is that i spotted a bug and fixed this in the last release, what this means is that all remote lines are now resolved to ip addresses and appended to the command line correctly, whereas this was not happening and some of the remote ip addresses where not getting appended and therefore no error was raised.

so you might be wondering why the remote line is resolved to ip, why not just append hostname right?, well the reason is i want to prevent any potential dns leaks, and therefore before the tunnel is established all dns queries are done and stored in a variable and then supplied to openvpn as 'remote' entries, once the tunnel is established all dns queries are subsequently blocked for the LAN and dns queries can only happen down the tunnel.

so the fix, simply drop one of your remote lines in the ovpn file and you should be good to go, if your vpn provider has a LOT of A records for each hostname then you may even need to drop this to a single remote host in the ovpn file. i could look at limiting the number of ip's returned for each hostname, thus giving a better mix of ip's for different hosts, but right now this is not the case.

Nelinski commented 3 years ago

Fixed for me, thanks!

c-hri-s commented 3 years ago

Thanks for the explanation - I can confirm njalla has a crazy amount of A records and was forcing the error.

blah@infinity:~$ dig openvpn.njalla.no

; <<>> DiG 9.10.3-P4-Lettuce <<>> openvpn.njalla.no
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2208
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 28, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;openvpn.njalla.no.             IN      A

;; ANSWER SECTION:
openvpn.njalla.no.      900     IN      A       198.167.192.1
openvpn.njalla.no.      900     IN      A       198.167.192.3
openvpn.njalla.no.      900     IN      A       198.167.192.5
openvpn.njalla.no.      900     IN      A       198.167.192.7
openvpn.njalla.no.      900     IN      A       198.167.192.9
openvpn.njalla.no.      900     IN      A       198.167.192.11
openvpn.njalla.no.      900     IN      A       198.167.192.13
openvpn.njalla.no.      900     IN      A       198.167.192.15
openvpn.njalla.no.      900     IN      A       198.167.192.17
openvpn.njalla.no.      900     IN      A       198.167.192.19
openvpn.njalla.no.      900     IN      A       198.167.192.21
openvpn.njalla.no.      900     IN      A       198.167.192.23
openvpn.njalla.no.      900     IN      A       198.167.192.25
openvpn.njalla.no.      900     IN      A       198.167.192.27
openvpn.njalla.no.      900     IN      A       198.167.192.29
openvpn.njalla.no.      900     IN      A       198.167.192.31
openvpn.njalla.no.      900     IN      A       198.167.192.33
openvpn.njalla.no.      900     IN      A       198.167.192.35
openvpn.njalla.no.      900     IN      A       198.167.192.37
openvpn.njalla.no.      900     IN      A       198.167.192.39
openvpn.njalla.no.      900     IN      A       198.167.192.41
openvpn.njalla.no.      900     IN      A       198.167.192.43
openvpn.njalla.no.      900     IN      A       198.167.192.45
openvpn.njalla.no.      900     IN      A       198.167.192.47
openvpn.njalla.no.      900     IN      A       198.167.192.49
openvpn.njalla.no.      900     IN      A       198.167.192.51
openvpn.njalla.no.      900     IN      A       198.167.192.53
openvpn.njalla.no.      900     IN      A       198.167.192.55

;; Query time: 175 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; MSG SIZE  rcvd: 494

I confirm your suggested workaround worked for me too, thanks.