net2wire

That fixed it. Thank you.

Ditto

Smooth update. No issues so far. Thank you.

unfortunately the update rendered my usb device unbootable....

Thanks Binhex. Thanks Pugnacious.

DEBG 'start-script' stderr output: /home/nobody/getvpnip.sh: line 12: awk: command not found

After an update I experienced the same issue. Deleting docker image and reinstalling does not correct the error.

LOL . Thanks. As per the instructions it reads that the KEY should be bond0. That's how it's read imo. It's a little confusing. But all good. I finally got it to work.

One would think so but this is the only way it works. I tried the method that was described here and it doesn't work. If in deed my setup is wrong then I would not be able to view the webgui, login to the web admin or successfully connect from any device. This will lead me to the conclusion that there is something amiss with the docker.

My setup:

My OpenVPN-AS setup to use Bond0: 1. Config Type: Variable 2. Name: Interface (I think you can name it whatever you like) 3. Key: INTERFACE 4. Value: bond0

I haven't experienced this issue before either and no matter how many times I had restarted Plex or rebooted unRAID the issue persists. Though, the host to bridge to host change did make a difference for like two minutes. Now back to same issue as master.h

Experiencing the same issues with OpenVPN-AS while testing bonded interfaces (bond0). Seems to be the only docker that is affected by bonding as far as I have experienced.

Not wanting to hijack thread either, but with Binhex's delugevpn (or sabnzbdvpn) I don't see the need for this docker really. Even if you don't use Deluge, the OpenVPN server is fairly straightforward and Binhex fully supports his App. My two cents.

I once had to give my ISP access to my modem (can't 100% remember why), and after they were done they started telling me that the admin passwords had to stay the exact same as what they set them to. Fine. ok. The minute they finished what they had to do I changed the password to an ultra hard password, then sat down and composed a very nasty email to them about that "policy" Yes this is common with some ISP's. Sadly people don't know the extent of their ISP's intentions, and some of these intentions are not for the users benefit. If the ISP has full access to modem/router: 1. Check if they updated your firmware? 2. Is your modem one of those affected by port 32764 being open? 3. Did you check for other user accounts on the router? 4. Look for any opened ports exposed to WAN side. Some interesting info to read: http://routersecurity.org/bugs.php http://routersecurity.org/othersgripeonrouters.php https://opensource.com/life/16/6/why-i-built-my-own-linux-router These are very nice indeed. Not sure how capable they are to handle multiple VPNs connections with pfSense but that wouldn't matter if OpenVPN Server plugin was installed on unRAID.

They didn't. They supplied a router that was easily hacked from the WAN side (there are plenty to choose from), and someone got into it, opened those ports, and forwarded them to IPs inside the LAN. Stands to reason that as a rule of thumb no end-user should trust the modem/router supplied by their ISP or any retail modem/router for that matter. Even if no unknown adversary hacks the router, your ISP should be treated as a known adversary. One way to mitigate these threats is to deploy your own firewall box and configure it accordingly: ex: with VPN's etc etc... and as most users here have at least one unRAID box on their LAN it would be prudent to learn about and deploy perimeter protection (firewall) in order to reduce the likelihood of an intrusion and by adding additional firewall protections reducing DPI (deep packet inspection) by the ISP. If I understand the OP's statement correctly, the fact that his unRAID logs contained adversarial intrusion attempts means his unRAID server was compromised to a lesser or greater degree, and I would err on the side of caution. Deploy a robust firewall (not the isp's router firewall) first before exposing unRAID ports on the WAN; even this needs to be monitored.

Yeah that's a good point. Although we don't know the OP's level of expertise and enthusiasm towards tech, he did manage to get unRAID installed and configured and that alone is more complicated than let's say installing Smoothwall, IPCop or pfSense. Most new users I would guess spend at least a few dozen hours of reading and configuring to get unRAID going. unRAID on it's own is just a simple server and adding Dockers and Plugins might take a while to understand and refine and apparently he seems to understand that already. An "out of the box" pfSense install provides minimum firewall protection with no open ports and very little user interaction to get on the net except to login to webgui and complete setup and reload settings. Installing Snort, Squid, Squidguard, DNSBL involves similar learning curve as installing Apps on unRAID but with pfSense there's just a lot more than can be configured and refined to suit your network environment.

Anyway, this might be the perfect excuse to build a pfsense box. +1 on the pfSense.

btw after several tries of editing as suggested I ended up removing docker+image files and instead reinstalled via CA. Several of the fields seemed different than the previous install, and I added field paths as necessary (ex: "incomplete" field) and all is well now. Logs look good. No speed issues. usermod: no changes [info] Env var PUID defined as 99 [info] Env var PGID defined as 100 [info] Permissions already set for /config and /data [info] Starting Supervisor... 2016-07-14 14:57:13,075 CRIT Set uid to user 0 2016-07-14 14:57:13,075 INFO Included extra file "/etc/supervisor/conf.d/sabnzbdvpn.conf" during parsing 2016-07-14 14:57:13,079 INFO supervisord started with pid 25 2016-07-14 14:57:14,081 INFO spawned: 'start-script' with pid 28 2016-07-14 14:57:14,082 INFO spawned: 'sabnzbd-script' with pid 29 2016-07-14 14:57:14,083 INFO spawned: 'privoxy-script' with pid 30 2016-07-14 14:57:14,091 DEBG 'sabnzbd-script' stdout output: [info] VPN is enabled, checking VPN tunnel local ip is valid 2016-07-14 14:57:14,091 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-07-14 14:57:14,091 INFO success: sabnzbd-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-07-14 14:57:14,091 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-07-14 14:57:14,091 DEBG 'privoxy-script' stdout output: [info] VPN is enabled, checking VPN tunnel local ip is valid 2016-07-14 14:57:14,094 DEBG 'start-script' stdout output: [info] VPN is enabled, beginning configuration of VPN 2016-07-14 14:57:14,105 DEBG 'start-script' stdout output: [info] VPN provider defined as pia 2016-07-14 14:57:14,107 DEBG 'start-script' stdout output: [info] VPN strong certs defined, copying to /config/openvpn/... 2016-07-14 14:57:14,110 DEBG 'start-script' stdout output: [info] VPN config file (ovpn extension) is located at /config/openvpn/openvpn.ovpn 2016-07-14 14:57:14,113 DEBG 'start-script' stdout output: [info] Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file... 2016-07-14 14:57:14,123 DEBG 'start-script' stdout output: [info] VPN provider remote gateway defined as XXX.XXXXXXXX.com [info] VPN provider remote port defined as 1197 [info] VPN provider remote protocol defined as udp 2016-07-14 14:57:14,132 DEBG 'start-script' stdout output: [info] VPN provider username defined as "username" 2016-07-14 14:57:14,139 DEBG 'start-script' stdout output: [info] VPN provider password defined as "password" 2016-07-14 14:57:14,142 DEBG 'start-script' stdout output: [warn] Password contains characters which could cause authentication issues, please consider changing this if possible 2016-07-14 14:57:14,161 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2016-07-14 14:57:14,170 DEBG 'start-script' stdout output: [info] Setting permissions recursively on /config/openvpn... 2016-07-14 14:57:14,180 DEBG 'start-script' stdout output: [info] Adding 192.168.2.0/24 as route via docker eth0 2016-07-14 14:57:14,180 DEBG 'start-script' stdout output: [info] ip route defined as follows... -------------------- 2016-07-14 14:57:14,181 DEBG 'start-script' stdout output: default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.11 192.168.2.0/24 via 172.17.0.1 dev eth0 2016-07-14 14:57:14,181 DEBG 'start-script' stdout output: -------------------- 2016-07-14 14:57:14,185 DEBG 'start-script' stdout output: [info] iptable_mangle support detected, adding fwmark for tables 2016-07-14 14:57:14,204 DEBG 'start-script' stdout output: [info] Adding additional incoming port 8087 for eth0 2016-07-14 14:57:14,232 DEBG 'start-script' stdout output: [info] Adding additional outgoing port 8087 for eth0 2016-07-14 14:57:14,241 DEBG 'start-script' stdout output: [info] iptables defined as follows... -------------------- 2016-07-14 14:57:14,242 DEBG 'start-script' stdout output: -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1197 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8080 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8090 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8090 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8087 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8087 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8118 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8118 -j ACCEPT -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1197 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8080 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8080 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8090 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8090 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8087 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8087 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8118 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8118 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT 2016-07-14 14:57:14,242 DEBG 'start-script' stdout output: -------------------- 2016-07-14 14:57:14,242 DEBG 'start-script' stdout output: [info] nameservers 2016-07-14 14:57:14,243 DEBG 'start-script' stdout output: nameserver 8.8.8.8 nameserver 8.8.4.4 2016-07-14 14:57:14,244 DEBG 'start-script' stdout output: -------------------- [info] Starting OpenVPN... 2016-07-14 14:57:14,249 DEBG 'start-script' stdout output: Thu Jul 14 14:57:14 2016 OpenVPN 2.3.11 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on May 12 2016 Thu Jul 14 14:57:14 2016 library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.09 Thu Jul 14 14:57:14 2016 WARNING: file 'credentials.conf' is group or others accessible 2016-07-14 14:57:14,285 DEBG 'start-script' stdout output: Thu Jul 14 14:57:14 2016 UDPv4 link local: [undef] Thu Jul 14 14:57:14 2016 UDPv4 link remote: [AF_INET]172.98.67.53:1197 2016-07-14 14:57:14,372 DEBG 'start-script' stdout output: Thu Jul 14 14:57:14 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2016-07-14 14:57:14,820 DEBG 'start-script' stdout output: Thu Jul 14 14:57:14 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1542' Thu Jul 14 14:57:14 2016 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC' Thu Jul 14 14:57:14 2016 WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1' Thu Jul 14 14:57:14 2016 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' 2016-07-14 14:57:14,820 DEBG 'start-script' stdout output: Thu Jul 14 14:57:14 2016 [88ayd890089d77d8fdfd788df7d8fd87] Peer Connection Initiated with [AF_INET]172.98.67.53:1197 2016-07-14 14:57:17,351 DEBG 'start-script' stdout output: Thu Jul 14 14:57:17 2016 TUN/TAP device tun0 opened Thu Jul 14 14:57:17 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Thu Jul 14 14:57:17 2016 /usr/bin/ip link set dev tun0 up mtu 1500 2016-07-14 14:57:17,352 DEBG 'start-script' stdout output: Thu Jul 14 14:57:17 2016 /usr/bin/ip addr add dev tun0 local 10.118.1.6 peer 10.118.1.5 2016-07-14 14:57:17,362 DEBG 'start-script' stdout output: Thu Jul 14 14:57:17 2016 Initialization Sequence Completed 2016-07-14 14:57:17,481 DEBG 'privoxy-script' stdout output: [info] Configuring Privoxy... 2016-07-14 14:57:17,492 DEBG 'sabnzbd-script' stdout output: [info] All checks complete, starting SABnzbd... 2016-07-14 14:57:17,533 DEBG 'privoxy-script' stdout output: [info] All checks complete, starting Privoxy... 2016-07-14 14:57:17,534 DEBG 'privoxy-script' stderr output: 2016-07-14 14:57:17.534 2b7432906dc0 Info: Privoxy version 3.0.24 2016-07-14 14:57:17.534 2b7432906dc0 Info: Program name: /usr/bin/privoxy

Thanks for the stronger encryption Binhex. I don't see very much difference in speed if any at all.

Interested.

Interested.

Curious: has anyone tried checking ssllabs.com to test the Nextcloud/Nginx install? My Nextcloud installation showed graded as B with a few vulnerability issues. If the plain vanilla install I did grades as B then I would imagine everyone else's will as well. As someone previously suggested with owncloud a while back, I went ahead and made the same changes to /nextcloud/config/nginx/config.php: server { listen 443 ssl; server_name _; ### Set Certificates ### ssl_certificate /config/keys/cert.crt; ssl_certificate_key /config/keys/cert.key; ### Add Diffie–Hellman key exchange ### ssl_dhparam /config/keys/dhparam.pem; ### Disable SSL by enforcing TLS ### ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ### Add some ciphers and reject weaker ones ### ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_verify_depth 2; # Add headers to serve security related headers add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; Hope this helps.

Thanks for your efforts BTW. As long as the tools are available within the docker(s) I think most people will be able to perform their own maintenance as needed.

I was wondering the same thing. Need to run ./occ upgrade manually to migrate from owncloud, and to do maintenance away from the GUI. I'm sure there's an easy solution?