theGrok Posted January 21, 2018 Share Posted January 21, 2018 I recently upgrade to 6.4. One of the features that I wanted to try was assigning containers their individual IP addresses. Once I started moving containers to their own IPs, they could no longer talk to each other. 6.3.5: unRaid IP 192.168.2.34 Sonarr 192.168.3.34:8989 NZBGET. 192.168.2.34:6789 6.4 unRaid IP 192.168.2.34 Sonarr 192.168.3.200:8989 NZBGET. 192.168.2.201:6789 in 6.3.5 Sonarr could talk to nzbget. when I switch the containers to individual IPs, they no longer can talk to each other. I did update the config in sonarr with nzbget's new IP. I also have another container, rtorrent-VPN that I cannot have access to the webui when it is on it's own IP. The container starts without problems and runs, but I don't have access to it's webui. I went to the routing table in network settings and noticed a bunch of entries that I have no idea what they do. Namely as0t0 ... 15. I have some friends who run the same containers I do and have none of these entries. Could it be some kind of routing issue? I am completely stumped. If I switch all of the containers back to the unRaid IP, everything starts to work again. Any suggestions are welcomed. Thanks. Link to comment
saarg Posted January 21, 2018 Share Posted January 21, 2018 This is how it works with macvlan. It's a security feature. Not sure if it's possible, but maybe with some clever routing in the router. There are a couple of threads about it already. Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 54 minutes ago, theGrok said: Once I started moving containers to their own IPs, they could no longer talk to each other. Go to the command line of the container and ping another container. E.g. docker exec -it Nginx /bin/bash root@4e8de03cca86:/$ ping 10.0.105.81 PING 10.0.105.81 (10.0.105.81): 56 data bytes 64 bytes from 10.0.105.81: seq=0 ttl=64 time=0.129 ms 64 bytes from 10.0.105.81: seq=1 ttl=64 time=0.084 ms 64 bytes from 10.0.105.81: seq=2 ttl=64 time=0.078 ms 64 bytes from 10.0.105.81: seq=3 ttl=64 time=0.080 ms Next check settings in the applications themselves, which may need to be changed. Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 33 minutes ago, saarg said: This is how it works with macvlan. It's a security feature. Not sure if it's possible, but maybe with some clever routing in the router. There are a couple of threads about it already. No, containers can always talk to each other. The restriction is the host (unRAID) itself. Link to comment
saarg Posted January 21, 2018 Share Posted January 21, 2018 34 minutes ago, bonienl said: No, containers can always talk to each other. The restriction is the host (unRAID) itself. That was what I meant, but I didn't read the thread well enough to see it was talking to each other he said... Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 35 minutes ago, bonienl said: Go to the command line of the container and ping another container. E.g. docker exec -it Nginx /bin/bash root@4e8de03cca86:/$ ping 10.0.105.81 PING 10.0.105.81 (10.0.105.81): 56 data bytes 64 bytes from 10.0.105.81: seq=0 ttl=64 time=0.129 ms 64 bytes from 10.0.105.81: seq=1 ttl=64 time=0.084 ms 64 bytes from 10.0.105.81: seq=2 ttl=64 time=0.078 ms 64 bytes from 10.0.105.81: seq=3 ttl=64 time=0.080 ms Next check settings in the applications themselves, which may need to be changed. Some of my containers don't have the ping command to test this. The ones that do I get no reply. Do you see anything that should not be there in the routing table I posted. What are all of those entires as0tx entries? Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 How did you configure the containers? They all should be in the same network 192.168.2.X (br0), they can not be in different networks. Link to comment
JonathanM Posted January 21, 2018 Share Posted January 21, 2018 2 hours ago, theGrok said: unRaid IP 192.168.2.34 Sonarr 192.168.3.200:8989 NZBGET. 192.168.2.201:6789 Is the 192.168.3 what you are trying to use or a typo? Is it actually 192.168.2.200 for Sonarr? .3 won't work. Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 Your bridge interface br0 is in 192.168.2.0/24, your containers should be in the same network. I don't understand where all these 172.27.xxx.yyy networks (as0tx) come from. Never seen that before. Link to comment
CHBMB Posted January 21, 2018 Share Posted January 21, 2018 Isn't 172.*.*.* docker container native network? No idea how it made it into the Unraid webui though...... Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 46 minutes ago, jonathanm said: Is the 192.168.3 what you are trying to use or a typo? Is it actually 192.168.2.200 for Sonarr? .3 won't work. it is in fact a typo. sorry about that. everything is 192.168.2.x Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 4 minutes ago, CHBMB said: Isn't 172.*.*.* docker container native network? No idea how it made it into the Unraid webui though...... seems like it. If I disable Docker in unRaid, all of those entries go away in the routing table Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 Docker is 172.17.xxx.yyy Link to comment
CHBMB Posted January 21, 2018 Share Posted January 21, 2018 1 minute ago, bonienl said: Docker is 172.17.xxx.yyy It's kinda close.... Link to comment
ken-ji Posted January 21, 2018 Share Posted January 21, 2018 as0tX interfaces seem to be OpenVPN-AS interfaces... Link to comment
CHBMB Posted January 21, 2018 Share Posted January 21, 2018 Not to state the obvious, but would diagnostics be of any help here? @bonienl Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 21 minutes ago, theGrok said: it is in fact a typo. sorry about that. everything is 192.168.2.x Make sure your containers don't do port translation, that is host port must be set as container port. 6 minutes ago, CHBMB said: Not to state the obvious, but would diagnostics be of any help here? @bonienl Normally would ask, but I have a gut feeling it is the configuration of the containers needs to be checked. Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 Ok, I am going to take a clean look at all of the container configs and report back. Thank you Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 22 minutes ago, ken-ji said: as0tX interfaces seem to be OpenVPN-AS interfaces... I do have this installed. Thank you. Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 I have solved a few of my problems. I can get sonarr and nzbget etc to talk to each other. The only problem I seem to have left is that I am using binhex's rtorrentvpn container. When I give it it's own IP using br0, I cannot get into it's webui. If but it back to bridge, I can get into the webui. I don't see anything strange in the container logs (nginx is started etc). I left a message in the container's support thread. I even installed a fresh copy in a new appdata folder in case. Same issue. Link to comment
bonienl Posted January 21, 2018 Share Posted January 21, 2018 Turn on the advanced view when you edit a container and check the setting of webUI, it should look something like http://[IP]:[PORT:8080] Link to comment
theGrok Posted January 21, 2018 Author Share Posted January 21, 2018 1 hour ago, bonienl said: Turn on the advanced view when you edit a container and check the setting of webUI, it should look something like http://[IP]:[PORT:8080] It does look like that. But no cigar. Even when I type the ip manually, there is no response. Anything I could attach that might help figure it out? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.