replication broken since V8 upgrade

[seapro220]

Hello all,
I've had a case open for a couple of weeks, and now with a level 2 at veeam and can't seem to get any resolution so I hope someone has some clues as to what might be going on. Here's the situation -

local nas for data storage
remote nas for data storage and replications
vsphere at both sides, but independent configurations - both running 5.1.x and VPN between 2 sites
backup repository - remote side and local side - no issues connecting or scanning
all jobs - whenever testing credentials - validate w/o any issues.

version 7 - running for over a year, all service packs and no issues. 7 backup jobs and 4 replication jobs for ip-remap.
a couple of weeks ago I upgraded to version 8 and also their 2 latest patches - so, current version is 8.0.0.917

Since upgrading, 2 replication jobs have continued to work - and 2 have been broken. No other changes.
all 4 jobs configured the same way
the 2 jobs that are working are configured similarly with the following settings -
'destination' - remote cluster (vsphere)
'repository for replica - remote side
'data transfer' - source=VMware and target is 'automatic'
'direct' mode is selected - not using any 'WAN accelerators - even though I have 3 at the remote side.
'seeding' - selected and from 'local' side. all replica servers show up.
'application aware' - selected and credentials validated

jobs failing with error message of "An existing connection was forcibly closed by the remote host"

I've tried all combinations of local/remote/auto-auto/auto-VMware, etc but can not get these jobs to work.

support staff are saying that port 2500 isn't open at the remote side and there is a firewall between or 'something' blocking' the connection. This isn't possible as I have 2 out of 4 jobs, with the same configurations that work - daily - w/o issues. I've even shown them, within their logs that port 2500 communication begins. from what I can tell, on my packet captures the next thing that start up - is a (random) port exchange somewhere around 6160 and I see a password/username issue - which might be causing the jobs to fail. as the username, within the packet capture is 'strange' with like a 12-digit combination I don't know what it is. I've also provided this to the Veeam staff but they haven't answered back as to what I might be.


thoughts ?

[foggy]

'repository for replica - remote side

In terms of performance, it is always recommended to select repository located on the source side to store replica metadata.

'jobs failing with error message of "An existing connection was forcibly closed by the remote host"

Support guys are right in that this error usually suspects network-related issues, so keep investigating the logs with them.

[seapro220]

I think I've cracked the code - but need to further test.
A question - on the 'seeding' tab - should the 'initial seed' be on the target side, or the local side where the backups occur? I presume, on a fresh or new replication process that the 'initial' seed should be from the target side but once the process is done and replication works - should the setting be changed back to the local or LAN side, or just that the check-mark be removed and saved?

[foggy]

The backup used for seeding should be placed into the repository on the target side. You can disable the "Low connection bandwidth (enable replica seeding)" check box after successfully seeding the replica.

[seapro220]

OK.
I'm still struggling to get the replication process to actually work - different issues with the 2 main servers (replica already exists and parent virtual disk has been modified since the child was created) - but wanted to share the results on what was causing the issues.

I'd been reading about a lot of issues with "ultrasurf" applications and how they are utilized for viruses, trojans, etc - due to their 'internal programming' ability to randomly generate ports and create connections to the 'outside'. I have an Sonicwall application firewall and had created a "app rule' to prevent the ultrasurf applications that might be running within my environment. I found out that most, cell phones are huge in their attempts to communicate with external content - probably due to all the different apps that people have running on them (i provide wireless for our internal users also).

What I didn't realize was that Veeam is also performing the same process during it initial connections to both the remote VSphere environment, as well as their proxy servers. I'd read that Veeam utilizes specific ports for initial communications as well as 'known' ports for Veeam for data transfers, etc. I didn't realize that the application rule that I created within my Firewall was also detecting the Veeam connections as 'ultrasurf' applications and shutting them down. Good for Sonicwall - bad for Veeam. I've since modified my rule to allow these type of connections to my remote site, and .. wa la...the Veeam process works again.