Docker-transmission-openvpn: RTNETLINK answers: Invalid argument, on Ubuntu Disco, due to quotes in ip route add command

[markdchurchill]

I think this line causes issues on some systems, the command succeeds without the quotes, and the issues disappear. I'm not sure if they need to be there for other reasons.
/sbin/ip r a "${localNet}" via "${GW}" dev "${INT}"

With quotes, on my system, this causes in the log:

RTNETLINK answers: Invalid argument
adding route to local network 192.168.69.0/24 via 172.19.0.1 dev eth0

Without this route, the symptom is that the container is accessible from other containers (eg: transmission:9091), accessible from the host (localhost:9091), but not accessible from the host's network (192.168.69.20:9091).

Snip from docker-compose

transmission:
container_name: transmission
image: haugene/transmission-openvpn
cap_add:
- NET_ADMIN
dns: 8.8.8.8
environment:
- OPENVPN_PROVIDER=...
- OPENVPN_CONFIG=...
- OPENVPN_USERNAME=...
- OPENVPN_PASSWORD=...
- LOCAL_NETWORK=192.168.69.0/24
- CREATE_TUN_DEVICE=true
- ENABLE_UFW=true
- UFW_ALLOW_GW_NET=true
- PUID=1000
- PGUID=100
volumes:
- /etc/localtime:/etc/localtime:ro
- incomingdownloads:/data
ports:
- 9091:9091
restart: on-failure

Host system:
Server Version: 18.09.5
Kernel Version: 5.0.0-13-generic
Operating System: Ubuntu 19.04
OSType: linux
Architecture: x86_64

Pretty clean install, hardware is vm in esxi.

[mbabauer]

@markdchurchill Did you ever fix this issue? I am getting this on Ubuntu 18.04.3 LTS as well.

[markdchurchill]

Seems to be working for me now, but I'm not sure if I put in some hack to fix it or not. My compose file for that stack doesn't have anything different, but I can browse directly to it from the lan..

[mbabauer]

@markdchurchill Thanks for the feedback. The first problem I found was that it did not like when I set the LOCAL_NETWORK to 10.0.0.1/24. Not sure why, but I switched to 10.0.0.1/32 and that seemed to work. But even after that change I am unable to get connected to the local 9091 port on the container. I'll have to mess around as I have time.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Note: The stale bot was recently added to this project to help weed out outdated issues. This will help us to focus time and energy on issues that are important and move the others out of the way. There could however be many issues that are still relevant but have gotten old without ever being fixed. As this is the first round of cleaning it might have been too eager. Feel free to re-open this issue if you think it deserves another look.

[jt196]

@haugene - weirdly I had these same errors (RTNETLINK) coming up when my container auto-updated to 3.0. Downgraded to 2.14, no problems, all working. The change to LOCAL_NETWORK=192.168.1.77/32 (from /24) seemed to fix it. I have some dependent containers working behind the Transmission VPN and they broke from this too. 32 fixed it, but I can't say why it worked, sorry! Basic set up is Synology (installed using the instructions) and PIA.

[haugene]

@jt196 When you say /24, you mean LOCAL_NETWORK=192.168.1.0/24? Would be nice to get the complete config you were trying to run. Basically it seems that alpine is stricter when it comes to checking validity on the CIDR ranges. Previously 192.168.1.1/16 would be allowed for example, but now it has to be 192.168.0.0/16.

But create a new issue if you want me to have a look at it. This one is closed. And provide logs and the configuration you use.

[jt196]

@haugene I did mean the local network. I did mention this in another thread but I've switched to a QbT + AirVPN container due to all the PIA port forwarding issues.