Backup fails through Router, DMZ, or Firewall


This article applies to backup problems or partial connection errors when attempting a backup across a DMZ or firewall, or when the Unitrends appliance and protected assets need to use specific ports.


Officially Unitrends does not support backup through firewalls.   

When attempting a backup across a DMZ or firewall, we experience backup failures or partial connection errors. The error "partial connection - check IP filters/firewall” may be returned.

In some cases this specific error may not be returned, but instead a backup will be marked failed and in the backup summary information it may indicate "inline verify mismatch."  In this case it will be noted that one of the two checksum values in the log summary is blank.  

SSL handshake errors may also be presented.  

The intent of this article is to cover situations where the backup appliance and protect asset are located at the same site but are separated by a security barrier like a DMZ network segment.  



NOTE: Backups leveraging Secure Agent Pairing, which is required to be used where agent support exists, are not supported through firewalls or gateway hops.  To resolve an issue or protect systems across a firewall boundary, the Unitrends Appliance must be deployed with an additional network adapter in the required VLAN, or, an additional Unitrends appliance must be used.  For DMZ networks use of VMs protected by host-level backups where the host can be in a production network and guest in a DMZ may be recommended to avoid spanning a single Unitrends system into a DMZ network segment. 

The instructions below will only apply to legacy agents and cannot be used for Windows and or linux agents that require SAP.  


To resolve partial connection - check IP filters/firewall error for legacy agents:


  1. On the protected asset, edit the master.ini configuration file (located in \PCBP\ or /usr/bp/bpinit/).
  2. Find the [BProfessional] section.
  3. Edit the data field line from:
This changes the port which the protected asset uses to connect out.
  1. Add the following line just below the data field line: 
    where "" is the IP address of your Unitrends appliance.    
  2. Save the master.ini file.
  3. Ensure there is a DNS lookup for this IP relating to the Unitrends appliance at the protected asset's location or manually modify the protected asset's hosts file to include the appropriate IP and short DNS name of the unitrends appliance.
  4. Now, change the data port the Unitrends appliance receives the connection.  Navigate in the Unitrends appliances' UI to Configure > <select your Unitrends appliance> > Edit > Advanced > General Configuration.
  5. Type 'data' in the Name field and change the data value from 1744 to 1745 as pictured below.

To resolve the "inline verify mismatch" error:

Because the backup begins, and transfers data, but is reaching a point where communication is cut off during processing, then this is not a simple port communication issue, and no setting on the Unitrends appliance itself or the protect asset will likely resolve this issue.  The resolution to this error will typically require assessment by the firewall vendor to determine which rule series is causing disconnection of active communication between our ports.  Common settings to review are the "idle port timeout" value.  It may also be necessary to ensure Deep Packet Inspection or other security inspection protocols in some advanced firewalls are eliminated for communication to and from the IP of the backup appliance.   In many cases, master backups that take longer than 20 minutes to complete will routinely fail however shorter incremental backups will succeed.  Your firewall vendor should be able to trace this communication and determine the impacting rule and make suggestions to resolve such issues.  Unitrends Support cannot provide direct assistance for managing 3rd party firewalls, but we will be happy to be present on calls with your firewall vendor to explain the nature of our protocols to them which may speed resolution of your issue.   Caution should be used when making firewall changes as increasing idle timeouts may put undue strain on firewall memory use or cause intermittent crash or reboot of some firewalls.  Few firewalls are designed for backup traffic to pass through them, it is typically expected backup traffic would be isolated to a management network bypassing the firewall itself.  

In some cases, moving the protected asset temporarily inside the network to complete a master backup, then performing incremental forever backups only across the firewall may yield success.  



When a backup is attempted across a DMZ or firewall, the agent may respond to the requesting IP address.  The agent may see the DMZ or firewall address rather than the requesting backup appliance, preventing connectivity from being established.  Unitrends protocol uses a bidirectional handshake and identity confirmation for the selected protected asset, in some cases the protected asset can reached but cannot return communication properly due to IP routing or firewall rules blocking some ports.  By default we use dynamic ports, but we can change settings to use specific ports instead for data transfer.

Further issues may occur because there may not be a DNS entry in the DMZ segment valid to respond with a proper IP for the Unitrends appliance causing a routing issue.  The protect asset must be able to resolve the Unitrends appliance by name or have a hosts file entry to do that where DNS cannot.  

A final issue which can cause what appear to be checksum verification failures or inline verify failures is related to firewall timeout values.  During a backup the Unitrends agent application uses port 1745 for data communication, but 1743 for operational management.  If a firewall terminates the idle socket 1743 during a backup, we will receive all data and the end result will be a backup failure because the backup job is unable to communicate the final backup summary across port 1743. 

When a unitrends appliance and a protected asset are separated by a firewall, the best practice is to bypass the firewall using a management VLAN.  Security experts consider such a process generally more secure than punching holes in a firewall, and this process will also increase backup speed and reliability as well as limit load on a firewall that in some cases could cause network disruptions.  Few firewalls are designed to support the load of a backup at gigabit speed.  Unitrends includes multiple NIC adapters in most of our products specifically to account for backups that require management networks to reach.  The most secure option to protect a system in a DMZ is to deploy an additional backup appliance dedicated to insecure network segments.  Protect the data for those systems using a small unitrends appliance or UEB, then replicate the data from that small appliance to a larger appliance or Unitrends Cloud asset for long term storage or archiving.  If you cannot isolate this traffic to a management VLAN, the above process "may" resolve your issues.   


See also What ports need to be open for the Unitrends system?

For more detailed information on backup failures and performance issues see Unitrends KB 5062 - Backup Failures and Performance Issues

Unitrends can assist with configuration to attempt to make communication more reliable through a local firewall to a DMZ network segment, however, WAN backup support is limited, and backup across non-persistent connections through an ISP is not openly supported.  If you are attempting to back up across the open internet including through VPN you may need to acquire an appliance to protect the systems at the other end of that connection. MPLS, private fiber networks, and some other forms of private site linking may be supported in some cases depending on data set size and pipe speed and type, your sales representative can provide more information on this type of support.  Please note, Unitrends architectural design is to have at least 1 appliance at each physical location backups are intended to run at, and can replicate data across those links using more efficient protocols, open transfer of bulk data across low speed or unreliably routed connections is not the design intent of this product.  

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section