dreadful "Connection Timed Out"

[multra 0]

Hello,

 

I've setup ADCH++ hub for my private use. TLS is enabled so I connect to it using adcs://

I am able to connect to my hub from inside and outside of my network.

However, when i try to "Browse file list" a user, i get "Connecting..." and then "Connection timed out". 

What i've tried:

 

* selected internal ip under "Bind address"

* selected "Firewall with manual port forwarding"

* specified public IP under "External / WAN IP"

* specified custom port for TCP/UDP and a separate port for TLS. Not sure what the DHT/UDP is for so i left it alone).

* forwarded these ports on my firewall (both: external location(work) and internal (home))

* tried adding above ports to Windows 7 firewall / disabled Windows 7 firewall entirely

 

 

any idea? is there a log file where i can further troubleshoot the issue? I feel like i've exhausted all usual workaround and still no luck?

Hoping its something silly:)

 

Thank you!

[Crise 26]

I assume you have not changed any of the settings under security and that UPnP is not an option.

Unless you have two (or more) active network connections, and thus actually need to set the bind address, it is advisable not to mess with the bind address at all. You can also attempt to leave the IP field blank. Try with more than one user, also try with both active and passive users to see where exactly the problem is.

Additionally if the users on your hub connect to it locally (ie. it is a LAN hub) then you should always connect locally to the hub as well obviously and same works in reverse for internet accessible hubs. Easy way to start diagnosing connectivity issues is to find a user X in active mode that you can connect to when you yourself are in passive mode. Because that means that the user is guaranteed to be connectable on his end and then try different methods of port forwarding starting from there in active mode checking against the same user.

[multra 0]

Thanks Crise,

 

I did not mess with security option and i haven't tried the UPnP option (need to read more about that)

I reverted back to 0.0.0.0 for Bind address, and left WAN blank. thanks for that info.

 

You guided in the right direction!

i tried connecting to my server using another computer from a different location (different consumer-grade router). It seems to have worked just fine.

My original tester is behind a corporate firewall which is probably blocking the dc traffic all together (in and out). I will have to go through the logs.

 

Side questions

* How would i ensure/enforce the traffic between my clients to be encrypted? Upon connecting, on the bottom right i see "DHE-RSA-AES128-SHA". I assume this is client to hub status.

After downloading a test file from one of the users, the "cipher" stated AES128, which I assume signifies encrypted traffic, is that correct?

* In the early stages of my setup I was using StongDC to test connectivity and it had "DHE-RSA-AES256-SHA" on the bottom right upon connection. Is ApexDC's standard - AES128? Is there a way to bump that up. Would it matter?

 

Many thanks for your time!

[Crise 26]

Side questions

* How would i ensure/enforce the traffic between my clients to be encrypted? Upon connecting, on the bottom right i see "DHE-RSA-AES128-SHA". I assume this is client to hub status.

After downloading a test file from one of the users, the "cipher" stated AES128, which I assume signifies encrypted traffic, is that correct?

* In the early stages of my setup I was using StongDC to test connectivity and it had "DHE-RSA-AES256-SHA" on the bottom right upon connection. Is ApexDC's standard - AES128? Is there a way to bump that up. Would it matter?

Regarding the ciphers AES-256 is in fact slightly less secure than AES-128, because one is designed better than the other the number of bits used is not everything (https://www.schneier.com/blog/archives/2009/07/another_new_aes.html#c386957).

There is no one simple way for a hub to enforce encrypted client to client connections. But typically clients in ADCS hubs use encryption if both clients support encrypted client connections. You can read more on the specifics over here: http://adc.sourceforge.net/ADC-EXT.html#_adcs_symmetrical_encryption_in_adc. In short you can check the presence of INF SU field, for support of encrypted connections but there is no way for a hub to force a client to actually make use of that support when connecting to clients. Also see SUDP extension, for active searches, the alternative to this is enforcing passive searches, that go through the hub, for everyone. However, majority of clients do not support SUDP and that there is discussion on a better version of SUDP but that has been talked about for a while now.

[multra 0]

Thank you very much for your help Crise!