PeterJT Posted April 27, 2004 Report Share Posted April 27, 2004 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 More sharing options...
abe Posted April 27, 2004 Report Share Posted April 27, 2004 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 More sharing options...
ecrm Posted April 29, 2004 Report Share Posted April 29, 2004 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 More sharing options...
PeterJT Posted May 2, 2004 Author Report Share Posted May 2, 2004 Believe me, this HAS been done and has not helped. Peter Link to comment Share on other sites More sharing options...
Mayoff Posted May 2, 2004 Report Share Posted May 2, 2004 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 More sharing options...
PeterJT Posted May 6, 2004 Author Report Share Posted May 6, 2004 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 More sharing options...
Mayoff Posted May 6, 2004 Report Share Posted May 6, 2004 I deleted my post since the info was all screwed up. Link to comment Share on other sites More sharing options...
PeterJT Posted May 6, 2004 Author Report Share Posted May 6, 2004 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 More sharing options...
Mayoff Posted May 6, 2004 Report Share Posted May 6, 2004 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 More sharing options...
PeterJT Posted May 7, 2004 Author Report Share Posted May 7, 2004 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 More sharing options...
Mayoff Posted May 7, 2004 Report Share Posted May 7, 2004 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 More sharing options...
ecrm Posted May 7, 2004 Report Share Posted May 7, 2004 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. Link to comment Share on other sites More sharing options...
ckw Posted May 19, 2004 Report Share Posted May 19, 2004 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 More sharing options...
ckw Posted May 19, 2004 Report Share Posted May 19, 2004 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 More sharing options...
Guest psykoyiko Posted May 21, 2004 Report Share Posted May 21, 2004 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. 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 More sharing options...
ckw Posted May 21, 2004 Report Share Posted May 21, 2004 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 More sharing options...
ckw Posted May 24, 2004 Report Share Posted May 24, 2004 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.