Docker-transmission-openvpn: Setup problem with rpi OMV docker armhf

[cihat1]

Hi,
I have a Rpi 3b+ with OMV 4. I installed the transmission-openvpn container with armhf tag through docker, and used the guide on the OMV forum to set it up. Even tough i added LOCAL_NETWORK=192.168.1.0/24 parameter, as soon as i start the container it stucks on loading in the omv docker ui, and i lost connection to my rpi. I cant connect through OMV gui or putty even after reboot. (I guess that have smth to do with setting restart policy as always). I installed OMV from start like 5 times since i cant connect to my RPI after starting the container. I d like any help. Thanks in advance.

[h45rd]

[...] and i lost connection to my rpi. I cant connect through OMV gui or putty even after reboot.

So no shell access via SSH? Via local terminal (monitor & keyboard)?
Does the rpi still give a ping response in this scenario?

Since the rpi is pretty starved for resources to begin with, a failing and constantly restarting container might push it over the edge.

For further diagnosis you will have to start by posting the container logs.

The easiest way to extract them if the rpi is caught in a bootloop, would be to access the SD card directly. Alternatively you could set the container restart policy to manual and access them after a hard-reset.
A third option would be to set up remote logging.

[cihat1]

As soon as i start the container i cant access via SSH or OMV web interface. I didnt try connecting via HDMI because i dont have a cable. When i reboot the pi i have a 10 sec window that i can connect via SSH but after that the connection is lost and i cant access again. I dont have logs because i cant connect via ssh. Since i cant access i dont know whats going on. When that happens i reinstall OMV on the sd card from start and try again.

[h45rd]

For getting to the logs, see the last paragraph of my last post.
E.g.: Fresh install. Create container as always, but omit automatic restart policy. Hard-reset rpi a couple of minutes after the manual container start freezes the system. Extract logs. Post logs.

Without them, any debugging would have to be done via crystal balls and tea leaves :)

[haugene]

Holy shit that sound frustrating. And don't take this the wrong way but I had to laugh a bit as well 😆 I've been in the situation where I need to race my computer to get something done before "X happens" and it's a steep uphill battle.

Anyways. I'll try to be of help :) First of all, don't start the container with --restart=always. This is what triggers it to start together with the Docker daemon on startup and also the things that is giving you the 10 seconds (I guess). Then the logs will be easier to get to after a reboot.

Could you post your docker run command? I have a feeling that you've started it with --network=host? That would explain it at least. That would put the complete host networking under VPN and even your SSH traffic would not get out. I agree that the LOCAL_NETWORK parameter should have fixed this, but there could be some "alternative routing" here making that parameter tougher to get right.

PS: Just saw @h45rd's answer pop up here, but I'll just post as it was written. You can merge them mentally ;)

[cihat1]

Don't worry i also started laughing to it after 5 formats :) Yes i started with "network mode=host". I am following the guide from the OMV forum that is why i do that. I tried with "restart=none" and i can at least connect after a reboot, that's a good start :)

I started the container, it freezes, then i got a reboot. Then in SSH console i wrote
"docker container logs transmissionopenvpn" nothing happens. So i cant manage to get any logs. Did i forget smth?

I extract the container details from OMV docker ui and attach below.
deleted

[haugene]

@cihat1 This looks correct. OpenVPN is connected and Transmission is starting.

I'm still pretty sure the --network=host needs to go. Are you still using that?
One of the major points of this image is to be able to run VPN containerised so that you don't affect the host. Setting that parameter effectively removes the containerised networking.

If you then exec into the container and run curl localhost:9091 you should get a response from Transmission. And if you can't reach it from outside the OMV you need to look more at the local network stuff.

But first. Run it without network=host

--

There's also a couple of minor stuff showing up in the logs. None of these are blockers for now. But I'll comment on it anyways.

The first thing is this line:

{"log":"Sat Mar  9 01:26:11 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.130.0.1,comp-lzo no,route 10.130.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.130.0.146 10.130.0.145,peer-id 13,cipher AES-256-GCM'\n","stream":"stdout","time":"2019-03-08T22:26:11.716552663Z"}

Just note that your provider is overriding the ping-exit option if you've set it. There is something about pull-filters in the README. Have a look.

The second issue is that tinyproxy config isn't set correctly. But that can be followed up in #681, a fix seems to be on the way.

[haugene]

Oh yeah. And for getting container logs:

docker logs transmissionopenvpn

Not

docker container logs transmissionopenvpn

[cihat1]

Yes i guessed it is working as intended. All the guides i saw sets network=host thats why i insisted on that and actually i dont know which option i should choose instead and how to set it.

From ppls logs i saw that their container routes to dockers interface like 172.x.x.x which makes sense. But according to my logs, my container routes to default gw 192.168.1.1. I guess thats why this happens but i m no expert.

What is the other option to network=host and how can i do that?

[haugene]

You will get 172.x.x.x as long as you're not doing network=host. You're getting your host networking 192.168.x.x because of it.

You don't need to set anything else. Just remove it. It will go with the default bridge mode. https://docs.docker.com/engine/reference/run/#network-settings

[cihat1]

Ok i ll try that tonight. Why the guides selecting host mode then. What is the difference between host and brigde? Just being curious :)

[cihat1]

The whole point of your container is to seperate the whole traffic from transmission for vpn. So why would anyone select host mode for this container.

[haugene]

Exactly. I don't know why anyone would do that.

There have been requests for allowing the container to run without VPN. People have found the Transmission functionality with alternate web ui and other stuff interesting, but they're running on a host with VPN and don't need the VPN functionality. Maybe in such a scenario one could use VPN on the host, but run in this container just to get the other stuff. I'm not sure.

In any case I don't recommend it. All the reasons I can think of for doing it that way sounds like a hack for something else. Would be interesting to hear if someone has a good reason for it.

[cihat1]

I tried bridge mode, it started normal and i did not lose connection to rpi, but now i cant connect to transmission webui. I wrote 192.168.1.30:9091 , 192.168.1.30:9091/transmission/ , 192.168.1.30:9091/transmission/rpc/ all failed. 192.168.1.30 is my rpi's ip address.

my container setup :
containerDetails.txt

container log:
containerLogs.txt

[haugene]

Well. This looks good I think. The container is probably running as it should by now. You can verify this by exec'in into the container and running curl localhost:9091.

I think your current problem with connecting to the web ui is the same issue as you had before when running network=host and couldn't connect to the host at all. Are you sure there are not more subnets at play here? That there isn't a virtual network in OMV or something?

LOCAL_NETWORK is setting up a route in iptables to allow traffic to that range. The probable reason traffic is not being returned is that it doesn't see you as a remote address within the range you've given.

LOCAL_NETWORK is a neat way to get access to the web ui, but different network setups can cause different issues. Try running the proxy that is described in the README, that should work.

[cihat1]

Ok i found a solution again with trial/errors->hairloss risk :)
I set to bridge mode and used port forwarding, host ip is my RPI's IP.
At least i reached to transmission webUI. Lets see if everything works now. I ll give updates.

[cihat1]

I tested many things (manual dl, auto dl for sonarr, radarr etc.), it works as intended. Thanks for the good work and help.

[haugene]

Glad to hear it! You're welcome.

Just to make sure. Did you end up using LOCAL_NETWORK or the proxy to access the WebUI? And if you went for LOCAL_NETWORK, what value did you set? I've seen people put values that efficiently disables the VPN, like 0.0.0.0/0 (TO OTHERS: DON'T!), and just want to make sure you didn't ;)

[cihat1]

I used LOCAL_NETWORK=192.168.1.0/24, did not use proxy.
I just used bridge mode and port forwarding as i told in previous post. The rest is all same with the guide on OMV forum. The guide tells to set host for network mode that is why it did not work for me.

I checked my IP with docker exec curl ifconfig.co and it is my vpn IP which is different than my external IP.

[haugene]

I see. Then it all sounds good! You should post a correction to that saying that you should not use network=host. There's been several cases of people having issues because they set that parameter.

[cihat1]

Yea, i dont know why they choose the host mode. I am new to rpi, dockers and stuff thats why i struggled :) and i put a lot of detail in this topic here so that may help those who struggled.