Tarsnap communicates with the Tarsnap server via an outgoing TCP connection to port 9279. Most desktop computers do not filter their outgoing connections, allowing tarsnap to work without any special tweaking.

Default-deny-out firewalls

In some environments it may be necessary to add a firewall rule to allow outgoing TCP connections on port 9279.

• For IPv4, at the present time (March 2016), there is only one address for the tarsnap server:

  75.101.135.185

  In tarsnap 1.0.37 and up, the binaries perform a DNS lookup for:

  v1-0-0-server.tarsnap.com

  Particularly paranoid network administrators may hard-code that destination address, rather than relying on DNS servers to provide the correct IP address.
• For IPv6, there are several addresses in use.

Here are some sample firewall rules which allow Tarsnap to work with default-deny-out firewalls:

• FreeBSD ipfw

  allow tcp from me to any 9279 out setup keep-state

• Linux iptables:

  -A INPUT  -i eth0 -p tcp --sport 9279 -m state --state ESTABLISHED,RELATED     -j ACCEPT
  -A OUTPUT -o eth0 -p tcp --dport 9279 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Detecting Tarsnap traffic

Communication between the Tarsnap client and server is mostly indistinguishable from random noise (otherwise your data wouldn't be properly compressed and encrypted!), with a few exceptions:

• The initial handshake is recognizable: Protocol versions are exchanged, and the client sends its version number. The server then responds with an RSA-PSS signed DH parameter.
• Some requests and responses have fixed sizes. For example, the response to "store this block of data" is always 135 bytes, so Tarsnap network traffic may be recognizable from the sizes of TCP segments.

As a result of these exceptions, network administrators can identify Tarsnap network traffic. Tarsnap is not a tool designed to hide its usage, even if you direct its traffic to a different system on a different TCP port.

Even if your personal computer allows outgoing connections on port 9279, there may be another firewall between your computer and the Tarsnap server, such as a university campus or company-wide firewall.

The first thing to test is whether you can ping the server:

ping v1-0-0-server.tarsnap.com
PING v1-0-0-server.tarsnap.com (75.101.135.185) 56(84) bytes of data.
64 bytes from ec2-75-101-135-185.compute-1.amazonaws.com (75.101.135.185): icmp_seq=1 ttl=29 time=88.7 ms

Some particularly annoying firewalls block ping requests, so it may also be good to test telnet:

telnet v1-0-0-server.tarsnap.com 9279
Trying 75.101.135.185...
Connected to v1-0-0-server.tarsnap.com.
Escape character is '^]'.

If those commands fail, check the logs of any firewall software you are using, and/or try running those commands in a different location (i.e. try from home, instead of your office or university). If problems persist, please contact us.

Obscure problems

In the vast majority of cases, adjusting the firewall(s) will fix any network problems. However, there are some rare cases where other action is needed:

• tarsnap --list-archives works, but -t, -d, -r, and -x fail.

  Cause: This means that there's a network tunnel (usually PPPoE on ADSL links) with broken MTU discovery; this results in small TCP segments getting through but 1500-byte segments being dropped.

  Solution: Reduce your MTU (and complain to your ISP).

• Tarsnap dies with 'network protocol violation by server' errors.

  Cause: This means that either someone is being simultaneously very sneaky and very clumsy about it (unlikely) or your network is corrupting packets. Common culprits are cheap network switches and (wired) ethernet interfaces; wifi is usually not at fault since it has extra checksums to handle routine signal mangling.

  Solution: Find and replace the faulty hardware. Your network performance should improve dramatically for all applications.