Can't wrap my head around this issue!


Dro

Recommended Posts

I'm not even sure where to post this question. But here goes with the best way I can try to explain what is going on. Maybe someone knows what is the missing part of this. I've been at trying to resolve this issue for almost 2 weeks now, working on it everyday.

 

unRAID version 6.6

Unifi USG pro4 Firewall 24 port USG switch 4 port NIC bond just using 802.ad/RSTP

 

Myself and a buddy of mine have been trying to setup onlyoffice communityserver and documentserver with nextcloud and letsencrypt etc.. We set it up properly as his works and mine doesn't. We have identical mirrored setups as it pertains to how the containers are setup, certs, public dns , configured, routing etc.. so I know as far as the backend configuration of the dockers, things are capable of working based on our setup and his setup working. of course our hardware is very different.

 

Here is where things get a bit interesting that I can't figure out.

Currently my unifi is passing port 443 > 444 which is the letsencrypt container so all HTTPS traffic is routed through LE using /subfolders or subdomains.. I run a ton of other dockers and they all work fine.. so it does appear my firewall is routing traffic properly. Doing a tcpdump on 443 appears to confirm that as well.

 

When I go to test nextcloud connectivity to the documentserver which is on port 4433 HTTPS (LE is using subdomain so its doing 443 >  Internal IP 4433) all i get is a "loading" or "connecting" 

Running wget commands from nextcloud for example gets the below attachments.

 

Nextcloud to DS > just shows connecting, no resolve like it doesn't even see the port being available.

DS > nextcloud > resolves but then gets stuck on connecting and never goes any further.

Also if i randomly pick any other container lets say Plex for example and try to wget to DS i get the same results so its not exclusive to just those two containers.

 

To try and eliminate the obvious I've disabled LE Container, Mapped 443 direct to the DS docker to try and eliminate anything in the middle > removed certs from the containers (thinking wget wasn't working due to a cert issue) but exact same result.. no matter what I try to disable or remove from the equation I am seeing the exact same results..

 

My firewall logs are showing sucessful ACK of the packets but I'm also seeng IPV4 Martian errors from 172.17.0.10 > my Public IP That is the Docker Bridged network for the Documentserver Container. 

 

We are both baffled by what is occurring here and i'm not sure wherelese to look to try and get some answers.. It seems as if something is blocking something but I have no idea what (common sense would say the firewall) but everything else is being routed the exact same way through LE/443 and works fine.. Im talking another 10 or so dockers.. My next step was to try a DMZ setup or just pickup a cheap router/firewall toss it in there and see if the results are the same.. 

 

What on unRAID could possibly cause something like this? Bad Docker network etc? even if everything else is working fine? I've probably removed/reinstalled these dockers 15 times, same results every time!

 

all the URLs work fine with the proper certs on HTTPS. I will try to provide some more logging but I am really not seeing anything.

 

Thanks for any direction provided.

 

wgetissues.PNG

Edited by Trembler
Link to comment
56 minutes ago, 1812 said:

short of a configuration error in your switch, have you watched this vid?

 

 

 

Thanks for the reply. I am pretty familiar with the reverse proxy setup as I have it working with tons of other things. My friend has the exact same code setup and it's working and as a matter of fact i am routing it through orginzr so I know even on my end the code works. You can connect to the URLs just fine from the outside and inside the network as well. Its just went i try to connect these two services to each other they do not connect. wget is my way to test the connectivity and I should be getting a response with wget not a "loading" or "connecting" and then a timeout. I don't know why that is occurring! Even from other dockers to these ones they do the same.

 

if i eliminate the reverse proxy it's the same result. I took my firewall and mapped 443 direct to the document server and still have the same issue. 

 

You are thinking a switch issue? All my other dockers are on the same switch and same port Bond0 and are working fine. I did have have some flood issues before with round Robin and the STP but I since fixed that with 802.ad and a RSTP. Still hasn't made a difference. 

Edited by Trembler
Link to comment
12 minutes ago, Trembler said:

Thanks for the reply. I am pretty familiar with the reverse proxy setup as I have it working with tons of other things. My friend has the exact same code setup and it's working and as a matter of fact i am routing it through orginzr so I know even on my end the code works. You can connect to the URLs just fine from the outside and inside the network as well. Its just went i try to connect these two services to each other they do not connect. wget is my way to test the connectivity and I should be getting a response with wget not a "loading" or "connecting" and then a timeout. I don't know why that is occurring! Even from other dockers to these ones they do the same.

 

if i eliminate the reverse proxy it's the same result. I took my firewall and mapped 443 direct to the document server and still have the same issue. 

 

You are thinking a switch issue? All my other dockers are on the same switch and same port Bond0 and are working fine. I did have have some flood issues before with round Robin and the STP but I since fixed that with 802.ad and a RSTP. Still hasn't made a difference. 

 

Try simplifying the network setup, remove round robin settings. Also, watch the vid in regards to creating a special docket net for dns resolution between containers. 

 

Thats where id try as next steps.

Link to comment
16 minutes ago, 1812 said:

 

Try simplifying the network setup, remove round robin settings. Also, watch the vid in regards to creating a special docket net for dns resolution between containers. 

 

Thats where id try as next steps.

Thanks, I've already tried the network aspect of it with the same results as far as RR, single port, bond etc. The odd thing is no matter what i change I'm getting no difference in the result so it's obviously something else I haven't tried.

 

Let me try a separate docker network for these dockers and see if that helps with DNS resolution. Although DNS resolution itself is working fine as these URLs are accessible from inside and outside with the same name but maybe something within the docker itself. 

Link to comment

So that was the issue! Now you can see proper connection! Awesome! now the fun begins to change all my stuff over to the custom docker network which I am not even sure some of the stuff I run behind proxy can be set to a custom bridge that it must stay as a host! but at least I know what the fix is! I've actually had the custom docker network setup before but must have never fully implemented it! Now I understand about the proper dns resolution between the containers. Never realized by default the bridge didn't do it. Thank You for pointing me in the right direction!

 

image.thumb.png.d6193d9076bafd83b925150bbecc99f8.png

Edited by Trembler
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.