bumpkin

Hey, just a follow-up on this. Adding a variable for VPNPORT for the relevant port fixed this. Yes, port forwarding through openvpn-client is explained at your github page. I just totally overlooked it. My apologies.

I really appreciate your persistence here. Well, I can't get his container to see devices on my lan (the ROUTE variable doesn't seem to work the same way) and it seems to be super laggy with slow pings on the order of seconds (using the very same ovpn file). Oh well. I can VPN into my LAN and use your container. That works well. It just doesn't work for things like an Apple TV which needs to authenticate in the manner described. Thanks again for all the help.

Well, the ChannelsDVR container needs to be able to see an HDHomeRun tuner on my LAN (sitting at 192.168.1.63). Adding ROUTE to 192.168.1.0/24 in openvpn-client fixed that. I was thinking the reason openvpn-client wasn't forwarding the port to my container is because it wasn't communicating through to 172.17.0.0/16. But it's probably just a port forwarding issue through the container. I'm stumped.

I don't think it's blacklisted because it works using the same .opvn config file with binhex-delugevpn. Can I add a second subnet using ROUTE? Do I just separate the two using a comma?

Thanks so much for helping with stuff like this. I set a variable for ROUTE to my local subnet (192.168.1.0/24) which allows my application container to see other devices on my LAN (thanks for that help). I'm using an application called ChannelsDVR (which is awesome). It has an external authentication mechanism through my.channelsdvr.net. When sitting behind VPN using openvpn-client, mychannelsdvr.net can't authenticate. I have opened the relevant port with my VPN provider. It works using binhex-delugevpn if I set VPN_INPUT_PORTS and VPN_OUTPUT_PORTS to the Channels port (8089), but there are other problems using that container. I have everything working the way I want, but my.channelsdvr.net can't see through openvpn-client, and it has to be because it's not forwarding my port through to the container. So close! Is it also possible to add a route for my Docker subnet (172.17.0.0/16)? I tried comma separated after the ROUTE variable, but didn't work. Alternatively, do I need to affirmatively forward the port in openvpn-client? As mentioned, I tried VPNPORT but it didn't seem to work.

Crazy. I definitely get faster speeds with that download link. It does seem speedtest-cli is crap. Unfortunately, when routing another container through binhex-delugevpn, the ping and bandwidth is still a mess. Something is wrong. Probably on my end. Thanks again for the help.

I have another (hopefully) simple one. I'm routing a container through OpenVPN-Client with Network Type: None and Extra Parameters: --net=container:OpenVPN-Client. I've added a port to OpenVPN-Client for my container, and I've opened the relevant port in my firewall directed at my Unraid server). It's working nicely. However, I can't seem to port forward through the tunnel to my container. If I hit my WAN IP and the relevant port, then I can make it in, but it's not forwarding connections from the VPN tunnel. I tried just a variable for VPNPORT with the same port number, but then I can't access the container at all. Any thoughts? I tried setting my router to forward to the container subnet IP (instead of my Unraid server IP), but it wouldn't let me add an IP from that subnet.

I do wish it were one of those. In both containers (with identical .ovpn files) I'm using speedtest-cli to test performance. In binhex-delugevpn, I'm getting a ping of like 3700. With openvpn-client, I'm getting a ping of ~30.

Any chance it's some sysctl command in the OpenVPN-Client container?

I'm routing a container's (Channels) traffic through the OpenVPN-Client container connected to a VPN. It works very well. However, I need Channels to be able to see a device on my LAN (HDHomeRun). When connected through OpenVPN-Client (--net:container:OpenVPN-Client), the Channels container cannot see devices on my LAN (i.e., the HDHomeRun). Any idea how I fix that?

I am using the exact same .ovpn configuration for binhex-delugevpn (PureVPN) as I am for openvpn-client. For binhex-delugevpn, I'm getting like 2Mbit/s up and down. For openvpn--client I'm getting like 500 down and 40 up (which is closer to what I would expect). Ping speeds for binhex-delugevpn are also ridiculously slow. Any thoughts on this? There's certain functionality that I like for binhex-delugevpn (e.g., auto-setting forwarding port), but the speeds are super slow.

I saw that guide. It seems to anticipate that I put my entire Docker stack on the second NIC. I'm not sure what happens then. Would all of those containers be on a new IP address? I'll have to make a lot of changes to my Swag configuration files if that's true (the container names never worked for me). I was kind of hoping that I could just put this one container on a new IP (192.168.1.301), and leave everything else where it is (various ports on 192.168.1.300).

My firewall (Firewalla Purple) very elegantly lets me put devices on my network behind VPN. I'd like to do that with a specific container on my Unraid server that requires port forwarding (Channels DVR). The Firewalla seems to get confused when two IP addresses share the same MAC addresses. I've purchased a second NIC, but my first run at enabling it screwed things up. How would I assign that NIC/interface to a specific container with its own IP and MAC addresses? Should I be doing this with macvlan (something I've never setup)? Yes, I accomplished something similar with binhex-delugevpn, including port forwarding through the VPN provider, but for some odd reason it was very slow and flaky.

Interesting that this was mentioned. For the first time in years of running Plex, I randomly had the mkv h264 codec take a dump. Couldn't figure out what the problem was. Just wouldn't stream some shows. Finally figured out it was mkv files, and all h264. After an hour of poking around, deleting the contents of the codecs folder in appdata fixed it for me.

Started happening to me a few days ago. Suck. Restarting the server sorts things out, but cannot otherwise find the cause, and it keeps coming back. Filling the log repeating the following: Aug 1 00:10:53 BigChief nginx: 2023/08/01 00:10:53 [crit] 7226#7226: ngx_slab_alloc() failed: no memory Aug 1 00:10:53 BigChief nginx: 2023/08/01 00:10:53 [error] 7226#7226: shpool alloc failed Aug 1 00:10:53 BigChief nginx: 2023/08/01 00:10:53 [error] 7226#7226: nchan: Out of shared memory while allocating message of size 15979. Increase nchan_max_reserved_memory. Aug 1 00:10:53 BigChief nginx: 2023/08/01 00:10:53 [error] 7226#7226: *895289 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Aug 1 00:10:53 BigChief nginx: 2023/08/01 00:10:53 [error] 7226#7226: MEMSTORE:00: can't create shared message for channel /disks