If it is different - it will attempt to connect external port. If subnet in LAN is the same - it will try to connect to the local port. They know the internal (LAN) ip:port and external one. Every instance of BTSync gets information from tracker - where are other peers with the same share. Would it be correct? (sorry for mess of the phrases, I type, what's on my mind) And as a way of replies, BTsync instances from outside networks can communicate. 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.
#CONFIGURE RESILIO SYNC BEHIND FIREWALL MANUAL#
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.Īnd I'm trying to understand and avoid potential manual configurations of FW for incoming traffic, or rather block it by default. Actually there are solutions to enable UPnP configurations on firewall, but that's what I'm trying to avoid, to provide smooth BTsync operations. Yes, I'm thinking about the fact, that statefull FW is implemented.
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. Some will allow incoming packets, and some not. So it might be related.Īctual behavior depends on FW/NAT implementation. Actually just noticed, that the same happens to TCP connections too.
Q: Are there still requirements for firewall configurations and should incoming UDP traffic, including port redirection, be deployed, to allow BTsync to run flawlessly?Īppreciate your comments and insights on causes, why it's happening. I'd obviously try to escape this config, if it is not requirement, to lower burden on management and tracking. Thus it might be configured in firewall with UDP and port redirection particularly. 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. 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. 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). 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. Here are a couple of questions and assumptions: And thus, all BTsync instances can find each other, if they have to negotiate over internet. 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. Each location is protected with network based firewall (UPnP disabled for security reasons in both locations). There are multiple btsync instances (devices) in 2 distinct locations.
0 kommentar(er)
