Jump to content


Become a part of the community today! Registration is quick and easy and will enable you to post, send personal messages, and join in on the chat! It's as simple as clicking on the links above.

BTsync not syncing at work


  • Please log in to reply
15 replies to this topic

#1 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 15 May 2013 - 08:14 AM

Hi,

I'm just discovering btsync, and it is definitely the missing sync software I was looking for for the past two years! So thank you for your work.
Now, here is my problem. I have a configuration with 3 machines : 2 mac (at work) + 1 NAS from Synology (at home). I would like to sync multiple folders between them.
- The 2 mac sync, since they are on the same local LAN (at work);
- If I bring my laptop at home, my NAS sync with it;
- but no success in syncing the NAS with the 2 computers at work. Actually, it seems that my company's firewall is blocking the connection between the NAS and the 2 computers.
- if I connect my laptop to the web by sharing my phone connection, sync works greats, so the configuration on the NAS (and my personnal router) is OK.

So, is there any way to connect my computers to my NAS? Tracker and DHT network are activated in the sharing properties, NAT UPnP is not activated (not working), but it still does not work.

Here is a part of the (anonymized) log file on the mac side :
[20130414 11:43:31] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:43:31] Got 3 tracker ips
[20130414 11:43:31] Tracker ip 54.225.100.8:3000
[20130414 11:43:31] Tracker ip 54.225.196.38:3000
[20130414 11:43:31] Tracker ip 54.225.92.50:3000
[20130414 11:43:31] Got 2 relay ips
[20130414 11:43:31] Server ip 67.215.229.106:3000
[20130414 11:43:31] Server ip 67.215.231.242:3000
[20130414 11:43:32] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:43:32] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130414 11:43:32] ping NAS_IP:port directly
[20130414 11:43:32] Requesting peers from server
[20130414 11:43:33] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:43:33] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130414 11:43:33] ping NAS_IP:port directly
...
[20130414 11:43:42] Requesting peers from server
[20130414 11:43:42] NAT-PMP: Unable to map port with NAT-PMP.
...
[20130414 11:44:31] ping NAS_IP:port directly
[20130414 11:44:31] Got 3 tracker ips
[20130414 11:44:31] Tracker ip 54.225.92.50:3000
[20130414 11:44:31] Tracker ip 54.225.100.8:3000
[20130414 11:44:31] Tracker ip 54.225.196.38:3000
[20130414 11:44:31] Got 2 relay ips
[20130414 11:44:31] Server ip 67.215.231.242:3000
[20130414 11:44:31] Server ip 67.215.229.106:3000
[20130414 11:44:32] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:32] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130414 11:44:32] ping NAS_IP:port directly
[20130414 11:44:32] Requesting peers from server
[20130414 11:44:33] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:33] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130414 11:44:33] ping NAS_IP:port directly
[20130414 11:44:34] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:35] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:36] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:37] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130414 11:44:52] Shutdown. Saving config sync.dat

Thanks for your help !

#2 Harold Feit

Harold Feit

    Community Manager

  • Administrators
  • 5,202 posts

Posted 15 May 2013 - 11:53 AM

Is "Use relay server when required" enabled?

#3 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 15 May 2013 - 01:17 PM

Yep. But work and home do still not manage to see each other ...
I guess this is what appears in the log:
[20130414 11:43:31] Got 2 relay ips
[20130414 11:43:31] Server ip 67.215.229.106:3000
[20130414 11:43:31] Server ip 67.215.231.242:3000

But what happens if UDP port 3000 is blocked on my company's firewall?

#4 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 15 May 2013 - 07:08 PM

But what happens if UDP port 3000 is blocked on my company's firewall?

It doesn't work.

You could see how far a UDP traceroute gets ... http://forum.bittorr...dpost&pid=45652

NB: The "Got 2 relay IPs" is a DNS lookup, not being able to contact them.

Assuming UDP is blocked (and you can't a port or two opened) you'll probably have to wrap the UDP in a TCP/IP connection. Perhaps even in a port 443 TCP/IP connection.

But first you might try putting your NAS on port 123 or port 53. Some company firewalls let those ports through even if they block others. You'll have to add the NAS as a known peer though because you still won't be able to connect to the tracker. NB: http://www.dnsdynamic.org/ will help you find the peer if it's on a dynamic IP.

If you need to wrap the connection tools you can use include Zebedee, OpenVPN and udptunnel.

PS: That traceroute is windows. You should be able to run a traditional traceroute on a Mac.

#5 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 15 May 2013 - 08:11 PM

Thank you very much or your response. I wiil try a UDP traceroute tomorrow from work.

BTW, I have already tried port 123 on my NAS:
- if I'm right, the NAS was still not visible. But I will try again;
- I don't know why, but the btsync process is running with 100% CPU on my NAS when using this port (and some other ones I have tested). So I am using port 1234 right now on the Synolgy, and no problem so far. May be a bug?

I have also tested through a VPN connection, and it works great. But before envisaging such a solution, I just want to be sure that any other solutions don't work.

#6 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 16 May 2013 - 08:33 AM

Hi,

I have just ran some tests, and I must confess I don't understand what is happening. But I don't know the filtering rules on my company's firewall, and this might explain the following ... And I'm definitely not an expert in networks!

1/ I have made some nmap tests to check if UDP port 1234 was open for connections from work to home (1234 is the port number bor BTsync on my NAS) :

~% sudo nmap -sU MY_NAS_IP -p1234
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-16 09:36 CEST
Nmap scan report for MY_NAS_IP (XX.XX.XX.XX)
Host is up (0.024s latency).
rDNS record for XX.XX.XX.XX: myadslbox.titi.toto.net
PORT	 STATE		 SERVICE
1234/udp open|filtered search-agent
Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds
So port 1234 is filtered. But this is not so informative ...

2/ I have made the same scan on UDP port 1194 (openVPN port), since I can can connect trough VPN to my NAS. So this should indicate that UDP 1194 is allowed four outbound connections.

sudo nmap -sU MY_NAS_IP -p1194
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-16 09:36 CEST
Nmap scan report for MY_NAS_IP (XX.XX.XX.XX)
Host is up (0.024s latency).
rDNS record for XX.XX.XX.XX: myadslbox.titi.toto.net
PORT	 STATE		 SERVICE
1194/udp open|filtered openvpn
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

Still indicated as filtered ... but again, VPN connections from work to home are OK.

3/ Just to be sure, I have made a last scan on TCP port 99, on which is running my SSH server.

sudo nmap MY_NAS_IP -p 99
Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-16 09:36 CEST
Nmap scan report for MY_NAS_IP (XX.XX.XX.XX)
Host is up (0.024s latency).
rDNS record for XX.XX.XX.XX: myadslbox.titi.toto.net
PORT	 STATE		 SERVICE
99/tcp open metagram
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

Port open ;)

4/ Since it seems that UDP port 1194 was allowed for VPN, I stopped the VPN server on my NAS, and have run BTsync on port 1194. But still no success, the NAS is not seen by the client. Log are similar:

[20130416 09:49:16] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130416 09:49:16] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130416 09:49:16] ping MY_NAS_IP:1194 directly
[20130416 09:49:16] Requesting peers from server
[20130416 09:49:17] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130416 09:49:17] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130416 09:49:17] ping MY_NAS_IP:1194 directly
[20130416 09:49:18] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130416 09:49:18] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130416 09:49:18] ping MY_NAS_IP:1194 directly

So, as a conclusion, do I have any chance to make BTsync working at work?
Thank you again for your help.

#7 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 16 May 2013 - 07:25 PM

You need the logs from both ends.

To date for me, BTSync connects just like OpenVPN when you turn off everything except the "predefined hosts".

It copes with port remapping firewalls (on one end) or double NAT punching when the port numbers are preserved but can't work though both double NATs and port remapping; just like OpenVPN. But the relay helps in the last case.

BTW: UDP is more difficult to scan for, a closed port will respond with an ICMP error packet but both an open and a filtered port will give nmap no response whatsoever (unless it's the echo service). That's why you have to do a traceroute, so you can get ICMP time exceeded packets from everything except the last hop.

Also BTSync does seem to make distinctions between "lan" and "other" so, what range of IPs does your work use for their internal network? 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or something else ?

Oh, except for one last thing; OpenVPN will give up after a little while, snooze and try something different. BTSync tends to be rather aggressive about trying to punch through firewalls and NATs. This means that sometimes it will get a broken connection into a firewall's table and keep it alive even though it does nothing. So try turning both ends off for 10 minutes at the same time to clear this.

#8 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 17 May 2013 - 03:52 PM

You need the logs from both ends.


I have just made some tests and have the log files from the NAS and my mac@work. I will provide them ASAP.

To date for me, BTSync connects just like OpenVPN when you turn off everything except the "predefined hosts".

It copes with port remapping firewalls (on one end) or double NAT punching when the port numbers are preserved but can't work though both double NATs and port remapping; just like OpenVPN. But the relay helps in the last case.

BTW: UDP is more difficult to scan for, a closed port will respond with an ICMP error packet but both an open and a filtered port will give nmap no response whatsoever (unless it's the echo service). That's why you have to do a traceroute, so you can get ICMP time exceeded packets from everything except the last hop.


I'm not an expert in traceroute, but whatever the options on the command line, whatever the port, I just get ... nothing:

> traceroute -e -P UDP -p 1234 MY_NAS_IP
traceroute to myhome.toto (MY_NAS_IP), 64 hops max, 52 byte packets
1 * * *
2 * * *

I have tried with TCP, on other classical ports (80, 443), but ... nothing.
But maybe I am making a mistake in how to use traceroute?

Also BTSync does seem to make distinctions between "lan" and "other" so, what range of IPs does your work use for their internal network? 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or something else ?


Actually, I have a public IP (134.15*.*****)! So I'm not really on a LAN...

Oh, except for one last thing; OpenVPN will give up after a little while, snooze and try something different. BTSync tends to be rather aggressive about trying to punch through firewalls and NATs. This means that sometimes it will get a broken connection into a firewall's table and keep it alive even though it does nothing. So try turning both ends off for 10 minutes at the same time to clear this.


I have shutted down all the softwares during a few hours. No change ...

#9 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 19 May 2013 - 03:03 PM

And here are are the log files.

1st case: mac@work and nas@home, with the mac connected to the work network. In this case, nothing happens, the NAS in not seen by my Mac (firewall problem, probably).

On the mac:
[20130417 17:29:20] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:20] Got 2 relay ips
[20130417 17:29:20] Server ip 67.215.231.242:3000
[20130417 17:29:20] Server ip 67.215.229.106:3000
[20130417 17:29:20] Got 3 tracker ips
[20130417 17:29:20] Tracker ip 54.225.100.8:3000
[20130417 17:29:20] Tracker ip 54.225.196.38:3000
[20130417 17:29:20] Tracker ip 54.225.92.50:3000
[20130417 17:29:21] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:21] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:21] ping MY_NAS_IP:1234 directly
[20130417 17:29:21] Requesting peers from server
[20130417 17:29:22] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:22] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:22] ping MY_NAS_IP:1234 directly
[20130417 17:29:23] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:23] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:23] ping MY_NAS_IP:1234 directly
[20130417 17:29:24] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:24] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:31] Requesting peers from server
[20130417 17:29:31] NAT-PMP: Unable to map port with NAT-PMP.
...
etc.

On the NAS:
[20130417 17:29:50] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:50] Got 2 relay ips
[20130417 17:29:50] Server ip 67.215.231.242:3000
[20130417 17:29:50] Server ip 67.215.229.106:3000
[20130417 17:29:50] Got 3 tracker ips
[20130417 17:29:50] Tracker ip 54.225.100.8:3000
[20130417 17:29:50] Tracker ip 54.225.196.38:3000
[20130417 17:29:50] Tracker ip 54.225.92.50:3000
[20130417 17:29:50] Adding DHT peer MY_MAC_IP:1234 for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:51] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:51] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:51] ping MY_MAC_IP:1234 directly
[20130417 17:29:51] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:51] ping MY_MAC_IP:1234 directly
[20130417 17:29:51] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:51] ping MY_MAC_IP:1234 directly
[20130417 17:29:51] Requesting peers from server
[20130417 17:29:51] Got list of 1 peers from 54.225.196.38:3000
[20130417 17:29:52] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:29:52] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:52] ping MY_NAS_IP:1234 directly
[20130417 17:29:52] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:52] ping MY_MAC_IP:1234 directly
[20130417 17:29:52] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:29:52] ping MY_MAC_IP:1234 directly
... etc.

2nd case: mac@work and NAS@home, but with the mac beeing connected through my phone ;) In this case, sync works great. 92.90.21.4 is the IP I got from my phone

On the mac:
[20130417 17:36:42] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:42] Got 3 tracker ips
[20130417 17:36:42] Tracker ip 54.225.100.8:3000
[20130417 17:36:42] Tracker ip 54.225.196.38:3000
[20130417 17:36:42] Tracker ip 54.225.92.50:3000
[20130417 17:36:42] Got 2 relay ips
[20130417 17:36:42] Server ip 67.215.229.106:3000
[20130417 17:36:42] Server ip 67.215.231.242:3000
[20130417 17:36:43] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:43] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:36:43] ping MY_NAS_IP:1234 directly
[20130417 17:36:43] Requesting peers from server
[20130417 17:36:44] Incoming connection from MY_NAS_IP:1234
[20130417 17:36:44] Got ping (broadcast: 0) from peer MY_NAS_IP:1234 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] Found peer for folder /Users/sylar/Documents/Administration/Enseignement/Master/M1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX MY_NAS_IP:1234 direct:1
[20130417 17:36:44] Lost peer for folder /Users/sylar/Documents/Administration/Enseignement/Master/M1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] Got id message from peer synok (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) 1.0.134
[20130417 17:36:44] Got state sync request from peer XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] Merge: processing get_root message, my hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] Merge: processing get_availability message, my hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, prev hash: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:36:44] State sync finished for folder /Users/sylar/Documents/Administration/Enseignement/Master/M1

And on the NAS:
[20130417 17:37:15] ping MY_MAC_IP:1234 directly
[20130417 17:37:16] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:37:16] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:16] ping MY_NAS_IP:1234 directly
[20130417 17:37:16] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:16] ping MY_MAC_IP:1234 directly
[20130417 17:37:16] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:16] ping MY_MAC_IP:1234 directly
[20130417 17:37:16] Got ping (broadcast: 0) from peer 92.90.21.4:11931 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:37:16] Found peer for folder /volume1/homes/sylar/M1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 92.90.21.4:11931 direct:1
[20130417 17:37:17] Going to sync state with peer 92.90.21.4:11931 (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)
[20130417 17:37:17] Merge: generating intial request with root XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:37:17] Sending broadcast ping for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[20130417 17:37:17] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:17] ping MY_NAS_IP:1234 directly
[20130417 17:37:17] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:17] ping MY_MAC_IP:1234 directly
[20130417 17:37:17] Send ping to peer () for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:17] ping MY_MAC_IP:1234 directly
[20130417 17:37:17] Send ping to peer (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX) for share XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[20130417 17:37:17] ping 92.90.21.4:11931 directly
Notice the port 11931. Where does it come from?

Thanks for you help.

#10 moriturimax

moriturimax

    Member

  • Members
  • PipPip
  • 21 posts

Posted 19 May 2013 - 05:32 PM

If you can't (or won't) talk with your companies IT department to get them to work with you on forwarding your connection then there may be a good reason not to sync a folder from home with a folder behind the company firewall.

I work for an Army Contractor who locks down most access to the internet. I am frankly surprised that I can even access any websites at all from work, but that being said, IT at your company might not react favorably at all. The company I work for would 95% likely fire me if they found me forwarding connections and/or syncing folders between home and the workplace.

Heh, course yours might be a bit more friendly toward you and even treat you like a human being, but your best chance is probably talking to them and opening that port if it's possible at all.

#11 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 20 May 2013 - 06:53 AM

The NAS is in communication with the outside world.
The MAC is not.
Please confirm that your OpenVPN connection is NOT configured to use TCP as it appears that your company firewall is blocking all UDP.

It also appears that you have some sort of NAT on the phone connection despite the IP address.

Many small company IT departments don't seem to be able to cope with UDP, basically, it gets left at default and for many Cisco routers UDP defaults to blocked. Also this IT department appear to be blocking ICMP time exceeded messages; this is a BAD idea and frequently means the firewall admin doesn't understand what they're doing.

#12 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 20 May 2013 - 07:54 AM

The NAS is in communication with the outside world.
The MAC is not.
Please confirm that your OpenVPN connection is NOT configured to use TCP as it appears that your company firewall is blocking all UDP.


Here is my openvpn configuration (very standard one):
dev tun
tls-client
remote MY_NAS_IP 1194
pull
proto udp
script-security 2
ca ca.crt
comp-lzo
reneg-sec 0
auth-user-pass

So yes, it's using UDP. And I'm able to use this VPN connection.
And BTsync *on the same UDP port* (1194) does not work. Can a firewall detect and block a specific kind of data traffic (I mean, here, bittorrent)?

It also appears that you have some sort of NAT on the phone connection despite the IP address.

Many small company IT departments don't seem to be able to cope with UDP, basically, it gets left at default and for many Cisco routers UDP defaults to blocked. Also this IT department appear to be blocking ICMP time exceeded messages; this is a BAD idea and frequently means the firewall admin doesn't understand what they're doing.


You're probably true ... And if I ask them to open a port for a sync based on a bittorrent protocl, they will probably:
1/ never answer;
2/ tell me to go to hell ;)
  • moriturimax likes this

#13 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 23 May 2013 - 08:35 AM

It is possible to detect traffic types, but if BTSync's traffic is detected as bittorrent it's a false positive, they are rather different.

OTOH, OpenVPN traffic is almost impossible to identify, best you can really do is "It's UDP and looks very random, if it's on port 1194 it must be OpenVPN".

I suppose you now have two main problems, why does OpenVPN work and why does BTSync fail.

As it is working, a "verb 1" log from the NAS end of the OpenVPN connection should give you the IP and port number that the connection seems to be coming from ("Peer Connection Initiated" line). The matching port numbers from the MAC end would also be needed to see if the firewall thinks it's a NAT despite the public IPs. (Your faked DNS names are still fine for the IPs)

If OpenVPN isn't on it's default port does it still work? If not someone has specifically opened the port and you're probably SOL unless you find a nice IT person.

Then we have what are the differences between the OpenVPN's use of UDP and BTSync.
  • You have OpenVPN in tls-server mode, this means that the NAS never sends a packet before the MAC. Turning off all peer discovery methods on the NAS would make BTSync act in the same way. You would have to add the NAS as a known peer to the MAC config.
  • The other thing is MTU (packet sizes), I'm not sure exactly what OpenVPN does by default, but as the firewall is blocking ICMP it's probably breaking MTU negotiation. However, this shouldn't stop the initial BTSync "pings".
Other than that, BTSync and OpenVPN traffic shouldn't be distinguishable. They're both heavily encrypted streams of UDP packets.


Actually, that's not 100% true; it is possible to identify a TLS OpenVPN connection based on a signature for the TLS authentication unless you use the "tls-auth" option, then it's truly random, and a tiny bit more secure.

Re; Port 123 on the NAS. Do you have NTPd running on the NAS? If so it'll already be using that port, plus BTSync will have to run as root to use port 123.

#14 sylar

sylar

    Member

  • Members
  • PipPip
  • 25 posts

Posted 23 May 2013 - 11:16 AM

Thanks for your help rdebath. I will try all your suggestions as soon as possible.
And by the way, you are right concerning the NTPd running on port 123 on my NAS. I will shut it down first and try again in the first place.

#15 Lightning

Lightning

    Advanced Member

  • Members
  • PipPipPip
  • 301 posts

Posted 23 May 2013 - 11:29 AM

Other than that, BTSync and OpenVPN traffic shouldn't be distinguishable. They're both heavily encrypted streams of UDP packets.

Except there are close to a hundred connections periodically opened for DHT even if none of your shares has DHT enabled. These are initiated from the same source port so I think it's possible that an IDPS or a firewall policy could block it.

#16 rdebath

rdebath

    Advanced Member

  • Members
  • PipPipPip
  • 290 posts

Posted 23 May 2013 - 07:44 PM

Except there are close to a hundred connections periodically opened for DHT even if none of your shares has DHT enabled.


Um, nope, this config is completely silent (except for the occasional DNS lookup and a www connection to www.usyncapp.com), until poked by a host that knows where it is.

{
"device_name": "Ghost",
"listening_port" : 8080,
"storage_path" : "/home/btsync/syncstate",
"check_for_updates" : false,
"use_upnp" : false,
"download_limit" : 0,
"upload_limit" : 0

,"lan_use_tcp" : false

,"shared_folders" :[{
"secret" : "IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII", // * required field
"dir" : "/home/btsync/data", // * required field
"use_relay_server" : false,
"use_tracker" : false,
"use_dht" : false,
"search_lan" : false,
"use_sync_trash" : false
}]
}

Perhaps, there's a bug in that dht will work in exactly the same way; ie if you poke it it'll wake up?
Do we need a global flag to disable DHT completely?

BTW: The dns lookups are unnecessary (and so technically a bug) because it's not using the tracker or the relay.