Peer-to-Peer Applications include NetVault.
In the peer-to-peer communication model, peers can act as either the client or the server and communicate by sending packets directly to each other. If a peer is behind a NAT, there are two addresses associated with it, the private address and the public address.
Let’s examine a simple configuration in which NATs can cause problems for peer-to-peer applications. The following figure shows a private network with a NAT at its edge.
For a peer-to-peer application running on all peers, Peer 1 can initiate a session with Peer 2 (directly reachable on its subnet) and with Peer 3. However, Peer 1 cannot inform Peer 3 of the public address of Peer 2 because Peer 1 does not know it. Also, Peer 3 cannot initiate a session with either Peer 1 or Peer 2 without manually configuring the NAT with a static translation table entry to translate the inbound connection request packets to Peer 1 or Peer 2’s private address and port. Even with the static translation table entry, Peer 3 cannot initiate a session with both Peer 1 and Peer 2 because both hosts use the same public IPv4 address and application port number.
To make matters worse, it is a more common situation to have Internet peers behind two different NATs. For example, in the previous figure, Peer 3 is also located behind a NAT.
Do not route NetVault communication through a communication device that uses NAT. This is confirmed on a note in the Configuring client's chapter of the NetVault Backup Administrators Guide with the following statement:
"NetVault does not support firewalls using NAT (Network Address Translation)/IP Masquerading."
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center