Jump to content

Retrospect Professional and Port Usage


PeterJT

Recommended Posts

Dantz

 

I'm getting kind of frustrated by the lack of responses to questions myself and other are posting regarding Retrospect Professional and TCP/IP port usage.

 

Presently, I have NO choice but to disable any firewall sofiware on the machine where Retrospect Professional 6.5.350 is running when I attempt to perform a backup of another machine.

 

Statements that 'Port 497 are required to be open' might be true on the CLIENT side but not the server.

 

This evening I found that onve again, backups of my wife's machine had failed with the message 'unable to find SUESP4', A quick shutdown of the the Microsoft Firewall from XP-SP2 and a manual run worked.

 

Viewing the connections active between the two systems we see

TCP 192.168.1.100:2506 192.168.1.102:497 ESTABLISHED

 

where 192.168.1.100 is the BACKUP server and 192.168.1.102 is the CLIENT machine.

 

Yes; 497 is the SOURCE port for traffic from the client, but not the DESTINATION port. The Microsoft Firewall is after the DESTINATION port on the BACKUP server.

 

At what point will Dantz make any statement about a workaround for this?

 

I see some people have taken the approach of openning a large range of ports. This is not a vialble option...

 

Peter

Link to comment
Share on other sites

Quote:

I'm getting kind of frustrated by the lack of responses to questions myself and other are posting regarding Retrospect Professional and TCP/IP port usage.

<snip>

At what point will Dantz make any statement about a workaround for this?

 


 

I second your frustration with the lack of response and reluctance to open a large range of ports, Peter. This is such a basic issue that it really deserves a proper response from Dantz engineers. Perhaps if we submit posts in the feedback area someone will at least take notice.

 

Does anyone from Dantz participate here, or just users (however expert and helpful)?

 

Abe

Link to comment
Share on other sites

Click the 'Advanced' Button under the 'Advanced' Tab of your network connection Properties dialogbox. (for each computer running XP firewall)

 

 

 

Click 'Add' under the 'Services' Tab and add the following (1 for TCP and 1 for UDP)

 

Description of Service = <whatever>

 

Name of IP... = <your computer> on Server | <server computer> on Clients

 

External Port = <497>

 

Internal Port = <497>

 

 

 

I believe UDP is used for the Server polling clients on the network and TCP is used for the backup. Could be all wet though but it works for me.

 

 

 

Try that

Link to comment
Share on other sites

Retrospect uses a well-known port, 497, assigned by the Internet Assigned Number Authority (IANA), for both TCP and UDP. Retrospect also uses subnet broadcast and Multicast packets. No other ports are used by Retrospect to transfer data using the Retrospect Client or to access clients.

 

Retrospect uses UDP broadcast, Subnet Broadcast and multicast. If your network has any of these blocked, then network transfers will likely fail. I have seen cases where a firewall may allow a client to be seen on the network, while actual copy of data fails. You must fully open the above network protocols to port 497

Link to comment
Share on other sites

Here's some information that I think might show otherwise.

This is captured from the Microsoft Windows Firewall log file, and shows two attempts to "connect" to a client machine from within Retrospect Professional.

 

 

Please observe that while the Retrospect attempts to talk to the CLIENT on port 497, the client is attempting to establish a connection to a non-registered [ephermal] port on the SERVER; in fact, the CLIENT "appears" to be connecting to the a port one greater than the port that the SERVER had initiated his session from.

 

With Microsoft's forthcoming standard of ACTIVATING this Windows Firewall on all XP systems with the deployment of SP2, it is safe to say that unless Dantz ACTIVELY investigates this issue, that when SP2 IS released to the public you will have many, many additional support requests.

 

 

=======

 

Rules in effect at this time:

 

ALLOW Program name "C:\Program Files\Dantz\Retrospect.exe" FULL access to internet

Attempt made from 192.168.1.101 to "REFRESH" the stats of a client located at 192.168.1.102

 

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

 

2004-05-06 01:23:13 OPEN UDP 192.168.1.101 192.168.1.102 2708 497 - - - - - - - - -

2004-05-06 01:23:13 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:15 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:17 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:19 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:21 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:21 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:21 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:23 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:24 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:26 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:26 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:28 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:28 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:30 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

2004-05-06 01:23:30 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

 

Observe:

Communication initated from Server -> Client

Server Port 2708 -> Client 497

2004-05-06 01:23:13 OPEN UDP 192.168.1.101 192.168.1.102 2708 497 - - - - - - - - -

 

Client attempts to talk back to server but is blocked

Client Port 497 -> Server 2709

2004-05-06 01:23:13 DROP UDP 192.168.1.102 192.168.1.101 497 2709 224 - - - - - - - RECEIVE

 

------

 

Second attempt:

Rules in effect at this time:

ALLOW Program name "C:\Program Files\Dantz\Retrospect.exe" FULL access to internet

ALLOW Ports 497 both TCP and UDP

Attempt made from 192.168.1.101 to "REFRESH" the stats of a client located at 192.168.1.102

 

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

 

2004-05-06 01:29:37 OPEN UDP 192.168.1.101 192.168.1.102 2718 497 - - - - - - - - -

2004-05-06 01:29:37 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:39 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:41 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:43 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:45 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:45 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:45 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:47 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:48 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:50 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:50 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:52 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:52 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:54 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

2004-05-06 01:29:54 DROP UDP 192.168.1.102 192.168.1.101 497 2719 224 - - - - - - - RECEIVE

 

No change; observe though that this time the Retrospect server is using the

port pair 2718/2719 as opposed to the first run using 2708/2709

Link to comment
Share on other sites

I;m not sure if you looked closely at that trace. if yoiu break the fields according to the information above them you will see the follpowing:

#Fields:

date 2004-05-06

time 01:23:13

action DROP

protocol UDP

src-ip 192.168.1.102

dst-ip 192.168.1.101

src-port 497

dst-port 2709

size 224

tcpflags -

tcpsyn -

tcpack -

tcpwin -

icmptype -

icmpcode -

info -

path RECEIVE

 

The 224 that is above has nothing to do with multicast; rather it is the size of the datagram that was "returned" by the client machine on 192.168.1.102 to the server on 192.168.1.101. Client data flow was initiated from port 497 to server port 2709.

 

As I indicated in my earlier post, the "port"s in use on the server side change; this has nothing to do with "udp scan-change", rather in how the Operating system is assigning port's to the application as it runs.

 

Normally, "server" class applications while they might INITIATE a communications from any port, will "LISTEN" on a well-known port; this for instance is why a web-server "listens" on port 80. This is also the model that Microsoft has implemented within their firewall component; you "name" the ports that a server LISTENS on.

 

Unfortunately, it would appear that the Retrospect SERVER INITIATES from a non-well known port, and also LISTENS on a non-well known, TRANSIENT port.

 

Peter

Link to comment
Share on other sites

I did some research and found:

 

The original poster is running XP SP2. SP2 is in beta and not release quality yet. We don't guarantee support for a non publicly released SP. We have run some testing with XP SP2 and found the same problems. There are logged bugs. When SP2 is released, we plan on having fixes for our product released as well.

Link to comment
Share on other sites

I think you'll find I was the original poster <g>

 

I'm more than willing to work with you on this; All I've been trying to say all along is that there WAS a problem, and how do I work with you and with Microsoft to get this resolved.

 

Not quite so frustrated...

 

Petet

Link to comment
Share on other sites

Our engineers do know the solution and it will be available at the time SP2 ships.

 

The heart of the problem is that MS decided to turn on the firewall for EVERY user who updates to SP2, resulting in lots of problems for network software like Retrospect.

 

The new firewall is also much stronger then the one included in SP1

Link to comment
Share on other sites

Quote:

Please observe that while the Retrospect attempts to talk to the CLIENT on port 497, the client is attempting to establish a connection to a non-registered [ephermal] port on the SERVER; in fact, the CLIENT "appears" to be connecting to the a port one greater than the port that the SERVER had initiated his session from.

 


I've seen this model used on many Licensing and Database software.

Quote:

Yes; 497 is the SOURCE port for traffic from the client, but not the DESTINATION port. The Microsoft Firewall is after the DESTINATION port on the BACKUP server.

Peter

 


This is going to be a hoot as it stands now. grin.gif

Link to comment
Share on other sites

  • 2 weeks later...

Peter,

 

Unfortunate I am glad to see others are have the same problem with Retrospect and port usage. Their customer support keeps telling me they only use 497 and that something must be wrong on my system.

 

My experience matches yours. The client only need 497 open, but for some reason they want to respond to the server on any number of other ports. My latest server firewall log shows them responding on 1078, 1060, 1057, 1054, and 1042 at various times. All the clients try the same port, but you never know what that port number will be.

 

I am not using the XP firewall. I am using PC-Cillin's firewall.

 

If you ever get a good answer, please post it. Unless I get a work around, I am going to switch to some other solution and dump Retrospect.

 

Ken

Link to comment
Share on other sites

I just got off the phone with Tech Support. They tell me that they cannot control which port the client tries to connect to on the server. They say the operating system controls that and that the only option is if your firewall allows you open all ports for traffic from a specific application. I find it unbelievable and am very sorry I spent my money on the product. I would not recommend Retrospect for anyone who intends to set up a firewall on the individual machines.

 

Ken

Link to comment
Share on other sites

Guest psykoyiko

First I would like to address the problems with UDP and firewalls in general.

By its very design, UDP is a connectionless, non-stateful protocol. That

means that host A sends a packet to host B, it may or may not receive a

response, and if it doesn't it will have no indication other than the lack of

packet, whereas in TCP, you have the guarantee of a handshake, etc. The

design of UDP makes it very difficult to use in firewalled and NAT

environments, as it is nearly impossible to tell whether a given inbound

packet was the result of a previous outgoing packet, which is relatively easy

to determine in a stateful TCP session.

 

Retrospect offers three ways of adding clients in the Single Server and

MultiServer versions. (If Dantz sees anything wrong with my descriptions here,

please chime in)

 

a) Multicast - This uses UDP, and it sends packets to the multicast address

to discover clients. Because it's UDP, it's subject to the limitations above,

but it's also great technically, because Retrospect merely has to send

discovery packets to the multicast address, and wait for whoever is in that

multicast group (all retrospect clients) to respond.

 

B) Subnet Broadcast - Very similar to multicast, except that it's sending UDP

packets on port 497 to the broadcast address for each subnet that is

configured within the Retrospect application. Great for discovery without

prior knowledge of what the client's IP address is. Still subject to the

limitations above.

 

c) Direct Connection - Does not use UDP. Makes a direct TCP connection with

the IP address entered in Retrospect, and communicates with the client that

way. Not subject to the firewalling problems that UDP is subject to, but also

cannot discover clients without prior knowledge of the client's IP address.

Won't really work in a DHCP environment unless dynamic updating of DNS records

is configured, and DNS information is entered in Retrospect rather that the IP

address.

 

So, in conclusion, Retrospect offers a way to get around the problems that you

all are experiencing with UDP and firewalling, although it may be a little

more difficult to configure on your end. So why not just use the direct

connection method, and still maintain the "security" of your firewalled ports?

 

Granted this is the Retrospect Professional forum, but if you require advanced

networking capabilities, maybe you should be using Retrospect Single Server or

Multi Server anyway.

Link to comment
Share on other sites

I am running a simple network. There are no servers on it. It is strictly a peer network.

 

I hope you are correct. I will try your suggestion. If you are correct, I am surprised that Dantz's technical support did not suggest the same thing.

 

I will report back my results.

Link to comment
Share on other sites

I tried what you suggested. There does not appear to be a way to do a "Direct connection" in Retrospect Professional. In other words there is not option to specify an IP address directly. The only way to add a client is to allow it to do the multicast.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...