Firewall Configuration Requirements, Multiple Btsync Instances Behind

[j2b]

There are multiple btsync instances (devices) in 2 distinct locations. Each location is protected with network based firewall (UPnP disabled for security reasons in both locations).

 

If I understand correctly, upon device boot (if btsync starts automatically), btsync connects to Tracker server, to inform about device, hashes, current IP and port it's listening. (that's why it is FW friendly). Please correct me if I'm wrong. And thus, all BTsync instances can find each other, if they have to negotiate over internet.

 

Here are a couple of questions and assumptions:

 

- Because BTsync is FW friendly (see above my understanding), it should not be a requirement to introduce any particular firewall settings allowing UDP traffic to come in, and all other instances should get acknowledged on new ports/ip addresses.

 

Q: Why there are btsync instances, which try to hit firewall on particular UDP ports (44943), obviously getting blocked, to get connection, if they should not? (the sync is working correctly any way).

 

- If still, some firewall configurations should be deployed, allowing incoming UDP traffic and port redirection, then there might be a conflict with listening ports, if configured manually. This means, that each btinstance behind teh firewall should be configured manually, looking to not place 2 or more instances on the same listening ports. Thus it might be configured in firewall with UDP and port redirection particularly. I'd obviously try to escape this config, if it is not requirement, to lower burden on management and tracking.

 

Q: Are there still requirements for firewall configurations and should incoming UDP traffic, including port redirection, be deployed, to allow BTsync to run flawlessly?

 

Appreciate your comments and insights on causes, why it's happening.

 

P.S. Actually just noticed, that the same happens to TCP connections too. So it might be related.

[RomanZ]

@j2b

 

If I understand correctly, upon device boot (if btsync starts automatically), btsync connects to Tracker server, to inform about device, hashes, current IP and port it's listening. (that's why it is FW friendly). Please correct me if I'm wrong. And thus, all BTsync instances can find each other, if they have to negotiate over internet.

That's correct. BTSync also distinguishes between LAN ip:port and external ip:port, so it lets tracker server know both. Not sure what do you mean under term "Firewall friendly" here, as it does not talk to any 3rd party firewall explicitly (only to built-in Windows FW).

 

- Because BTsync is FW friendly (see above my understanding), it should not be a requirement to introduce any particular firewall settings allowing UDP traffic to come in, and all other instances should get acknowledged on new ports/ip addresses.

I suggest that you are talking about statefullness of the FW and the fact that FW should let incoming packets in because some packets were out from particular IP:port.

 

Actual behavior depends on FW/NAT implementation. Some will allow incoming packets, and some not. If FW/NAT smart enough to track and compare the destination of outgoing and source of returning packets - it might block packets if IPs differ.

 

In such case it's always safer to make port forwarding.

 

Q: Why there are btsync instances, which try to hit firewall on particular UDP ports (44943), obviously getting blocked, to get connection, if they should not? (the sync is working correctly any way).

Sorry, did not understand the question. Every instance of BTSync gets information from tracker - where are other peers with the same share. They know the internal (LAN) ip:port and external one. If subnet in LAN is the same - it will try to connect to the local port. If it is different - it will attempt to connect external port. If external port is blocked by FW or NAT - well, no direct connection is possible.

 

- If still, some firewall configurations should be deployed, allowing incoming UDP traffic and port redirection, then there might be a conflict with listening ports, if configured manually. This means, that each btinstance behind teh firewall should be configured manually, looking to not place 2 or more instances on the same listening ports. Thus it might be configured in firewall with UDP and port redirection particularly. I'd obviously try to escape this config, if it is not requirement, to lower burden on management and tracking.

Yep. Conflicts are possible as with any port forwarding. Actually, FW won't let you map same ports to 2 computers.

 

Q: Are there still requirements for firewall configurations and should incoming UDP traffic, including port redirection, be deployed, to allow BTsync to run flawlessly?

Yes. Every instance of BTSync needs to be able to send outgoing connections / packets over TCP/UDP port 3000 (contacting tracker and relay server), port 80 (getting addresses of tracker and relay), get incoming connections to the "Listening port" (see preferences).

 

For LAN discovery you can also add UDP port 3838.

[j2b]

RomanZ, thank you for reply.

 

...Not sure what do you mean under term "Firewall friendly" here...

 

A NOTE: In initial description of situation, I indicated, that network firewall (not host-based FW) solution is deployed in both locations. This means, that, there are edge firewalls/router in each location, protecting whole internal networks. So this would not be related to host based FW solution, as noted at the end of paragraph (Windows FW).

 

By phrase - 'firewall friendly', I meant, that each btsync user, who installs it on own computer, should not bother about any firewall settings, as in most cases, outgoing traffic (and initiation) is allowed (not filtered out by network FW). So - 'firewall friendly', would mean, that user installs btsync on his/her computer, and it's ready to go, without any additional requests to IT helpdesk for special configuration on network FW. (this does not relate to corporate networks, where ITs struggle to filter out or at least lower the amount of p2p traffic )

 

I suggest that you are talking about statefullness of the FW and the fact that FW should let incoming packets in because some packets were out from particular IP:port.

 

I'd assume, that btsync instance running in one or the other location, is pinging tracker or other nodes for connectivity, thus providing actually opened channel to the internet for sync operations. In such a way, BTsync instance, which is behind corporate network based firewall, initiate connection to internet from within the internal network, and keep it open. So it shouldn't be a problem for statefull firewalls to allow communications (inflows on the same ip:port) afterwards. (If only a node, which is outside corporate network change IP due to roaming or other conditions. But that's another story.)

 

Actual behavior depends on FW/NAT implementation. Some will allow incoming packets, and some not. If FW/NAT smart enough to track and compare the destination of outgoing and source of returning packets - it might block packets if IPs differ.

 

Yes, I'm thinking about the fact, that statefull FW is implemented. Actually there are solutions to enable UPnP configurations on firewall, but that's what I'm trying to avoid, to provide smooth BTsync operations. It's like with FTP, to tighten FW as much as you can, and do not open ports, or allow systems automatically to open such.

 

And I'm trying to understand and avoid potential manual configurations of FW for incoming traffic, or rather block it by default. As I assume, that BTsync instance for local/internet communications in any other ways is useless, if it does not initiate first connections at least to Tracker server, than it might be considered, that first Tracker connection initiation from BTsync instance from internal network would open connection in network firewall as legitime. And as a way of replies, BTsync instances from outside networks can communicate. Would it be correct? (sorry for mess of the phrases, I type, what's on my mind)

 

Sorry, did not understand the question...

 

Sorry for lack of clear description. I've spotted the following:

 

Location A:

1x btsync instance, listening on port (say) 44000, and firewall port 44000 is opened and redirected to this instance.

 

Location B:

3x btsync devices are active, and one of these instances (spotted by swithcing them off one by one) is trying to connect to Location A btsync instance on port 44943 and gets blocked by FW. (no other sync instances in location A are present nor listening on 44943 TCP/UDP)

 

The question is: Why particular (spotted) btsync instance in location B is trying to connect to location A instance on different port, if there are no hashes/instances listening/indicating on such port?

 

...Every instance of BTSync gets information from tracker - where are other peers with the same share. They know the internal (LAN) ip:port and external one. If subnet in LAN is the same - it will try to connect to the local port. If it is different - it will attempt to connect external port. If external port is blocked by FW or NAT - well, no direct connection is possible.

 

Hm (regarding last statement)!?! Such a situation would make BTSync inoperational in most cases, but it's not so. I'm going to test this in a couple of days. Only within the same network or subnet, there might be a situation, where there are no firewalls between BTsync instances, or in other case, on each firewall that would require opening relevant ports, if a user from this network decides to install btsync. I can not give more details on this assumption, but will come back after tests. By now, I still assume, that the benefit of P2P and BTsync is in fact, that connections are opened from within LAN to outside, thus overcomming necessity to configure FW to operate, and such channels are used for data transfer. But this statement obviously then rise a question - why there is such a thing for listening port, configured in btsync, for outside LAN communications purposes? If BTsync initiate connection from LAN to internet, this connection gets random FW port, about which Tracker is informed (as you mention external IP:port), and that would be sufficient to run connection. Listening port might be as additional option to finegrain communications, but it's rather useless for inter LAN communications for basic purposes.

 

Yes. Every instance of BTSync needs to be able to send outgoing connections / packets over TCP/UDP port 3000 (contacting tracker and relay server), port 80 (getting addresses of tracker and relay), get incoming connections to the "Listening port" (see preferences).

 

Thank you for clarification. This would obviously require network FW configuration in cases, when outgoing traffic is filtered by firewall too.

[RomanZ]

And I'm trying to understand and avoid potential manual configurations of FW for incoming traffic, or rather block it by default. As I assume, that BTsync instance for local/internet communications in any other ways is useless, if it does not initiate first connections at least to Tracker server, than it might be considered, that first Tracker connection initiation from BTsync instance from internal network would open connection in network firewall as legitime. And as a way of replies, BTsync instances from outside networks can communicate. Would it be correct? (sorry for mess of the phrases, I type, what's on my mind)

The technique you are describing called "Hole punching". BTSync uses it, but as I mentioned - some firewalls/NATs actually track destination address and do not allow it.

 

Location A:

1x btsync instance, listening on port (say) 44000, and firewall port 44000 is opened and redirected to this instance.

Location B:

3x btsync devices are active, and one of these instances (spotted by swithcing them off one by one) is trying to connect to Location A btsync instance on port 44943 and gets blocked by FW. (no other sync instances in location A are present nor listening on 44943 TCP/UDP)

The question is: Why particular (spotted) btsync instance in location B is trying to connect to location A instance on different port, if there are no hashes/instances listening/indicating on such port?

 

The most probable reason is because connection from Location A came from port 44943. Is location A covered by firewall or NAT? Some NATs are actually changing ports when they substitute source IP:port.

 

Hm (regarding last statement)!?! Such a situation would make BTSync inoperational in most cases, but it's not so. I'm going to test this in a couple of days. Only within the same network or subnet, there might be a situation, where there are no firewalls between BTsync instances, or in other case, on each firewall that would require opening relevant ports, if a user from this network decides to install btsync. I can not give more details on this assumption, but will come back after tests. By now, I still assume, that the benefit of P2P and BTsync is in fact, that connections are opened from within LAN to outside, thus overcomming necessity to configure FW to operate, and such channels are used for data transfer. But this statement obviously then rise a question - why there is such a thing for listening port, configured in btsync, for outside LAN communications purposes? If BTsync initiate connection from LAN to internet, this connection gets random FW port, about which Tracker is informed (as you mention external IP:port), and that would be sufficient to run connection. Listening port might be as additional option to finegrain communications, but it's rather useless for inter LAN communications for basic purposes.

You forget about:

1) UPnP + NAT-PMP

2) Hole punching

Again, both technologies can be blocked by NAT/Firewall. If they are - then connection goes thru relay server, or user has to explicitly allow / forward ports.