OS X Client access problems with Trend Micro firewall

[abe]

I'm having a devil of a time getting Retrospect Pro 6.5 on my WinXP PC to talk to an OS X client through the Trend Micro Internet Security 2004 firewall. I allowed incoming/outgoing TCP/UDP traffic on port 497 to the IP address of the Mac as usual, but the TM logs are recording traffic all over the spectrum when I try to access the client.

 

Just to add the client with piton multicast I had to enable incoming traffic on 3469 and 3563. That finally enabled me to add the client. [bTW, what's this ridiculousness of having to pay extra to add clients by IP address--requires a Client Networking add-on??? Not cool, Dantz. Incidentally, such an add-on isn't listed in the online store!]

 

Note that the client is reported "found" by clicking Test and entering the IP address, without enabling those ports.

 

Once the client is added, however, I can't add the right ports. I'm in Client Properties and I click Refresh because the client status is "not connected". Eventually times out with the standard error -530. I check the firewall logs ad fins that TM is blocking inbound traffic on a *different port* every time I click the Refresh button!! So far I've enabled 3186, 3196, 3324, 3469, 3563, 3579, 3586, 3592, 3607, etc. etc., and *still* can't connect. All traffic is listed as UDP, and all comes from 497 on the Mac, which, BTW, is running Client 6.0.108, just installed on 10.3.3.

 

What's up with all these apparently random ports being accessed? As far as I knew previously, 497 was the only port required to be open for Retrospect--so Dantz article ID 26620, and so too my previous experience. I don't like the TM firewall much and may well go back to ZAP, but it's clearly recording traffic and I'd like to know what's going on. Ideas?

 

Thanks!

 

Abe

[wscott44]

The problem is not limited to OS X; I have the same trouble accessing a Win98 client. I have to tell the TM Firewall to Allow All to do the backup. I have not had time to do the experimenting you have; and this client is an old PC that I don't care much about -- it is more of a test platform I use before deploying something on a more important machine.

 

I know what you mean about the add-on stuff and not being able to find the correct one even if you tried to buy it. I cannot create a disaster recovery CD for a client without an additional license of some kind. The list of products and licenses is not clear at all about what I would need.

 

When I tell TM to Allow All, the server can find the client by name.

 

Sorry I could not help more than to just commiserate with you.

 

Wayne Scott

[abe]

Thanks for your commiseration, Wayne. ;-) FYI, I've done a wee bit of testing and it seems that things are working OK now that my TM "Retrospect Client" rule allows traffic on TCP/UDP ports 497,3000-4100. [i don't like to open everything, even between computers on my own network that are secured--just in case.]

 

I'm not happy about enabling this wide range, and I'd like to hear from a Dantz engineer about why these random ports are being used in the first place. There should be a tech note on this.

 

Abe

[natew]

Hi

 

Just to be clear, the built in OSX firewall on the mac is also set to allow communication on port 497? Does temporarily stopping the firewall on the windows machine allow you to connect?

 

The add by address and multi subnet backup features are a part of Retrospect single and multi server. If you are backing up to hard disk you can also get this functionality in the disk to disk product.

 

Nate

[abe]

Hi, Nate. Yes indeed, port 497 is open on the Mac. And while I haven't tried it, I'm quite certain that stopping the firewall on the PC would allow me to connect. What I find curious (and would like an answer to) is why the TM firewall is logging (and must permit) Retrospect traffic on all these other ports. Any idea?

 

Abe

[paleolith]

Yeah, I know, this discussion is five months old. But I've just been banging my head against the same problem, and I think I figured out what's wrong (after waiting for a clueless response from Trend Micro support), so I thought I'd share it. Someone else may come across this thread in a search, just as I did.

 

TCP and UDP packets have a source port and a destination port. These normally are NOT the same. When we talk about using such-and-such a port, we are referring to the port on which the server is listening. When a client wants to connect to the server, it doesn't assign a specific port number -- instead it calls the networking software saying "assign me a port, any port". As a result, the client port number is not predictable.

 

Retrospect turns the client/server designation on its head. The Retrospect client is listening for the backup computer to connect to it. So it's the ports on the Retrospect client that predictable, always 497.

 

So for example, my backup computer sends a UDP packet from port 1856 to the client's port 497. Somehow this gets past the TIS firewall. The client sends a packet back using the same ports, and when it arrives on port 1856, the firewall rejects it.

 

When you read the article at http://www.dantz.com/en/support/kbase.dtml?id=28189 about configuring the firewall in WinXP SP2 on the backup computer, look closely at steps 15-18. The SP2 firewall is providing a method by which packets to and from ports open by Retrospect are allowed. The WinXP SP2 firewall also offers port filtering where you can specify both source and destination ports.

 

TIS (Trend Micro Internet Security) offers neither of these options -- neither program filtering nor source+destination port filtering.

 

Medieval.

 

I had decided to try Trend in the hope of alleviating my frustration with NAV, but it's starting to look like I jumped from the frying pan into the fire. For their firewall to be inferior to the Windows firewall is a Very Bad Sign. It's also totally muddy to me whether I have to use the TIS firewall. If I turn it off, it warns me that I'm no longer protected against network viruses. But exactly what is disabled? What is meant by "network virus"?

 

But ... the docs for TIS claim that it is a stateful firewall. So why isn't it noticing the exchange of packets (it's not a connection because the blocks I'm seeing are on UDP packets) and allowing the traffic? This is what I'm now brining up with Trend support. In the probably vain hope that anyone in support will have a clue about firewalls.

 

I got mine working by adding a firewall exception: port 1024-9999, TCP/UDP, Allow, In. It might be that UDP alone would have sufficed. I'm behind a NAT and so this setting up the firewall is mostly an experiment anyway -- the email malware blocking is the important feature -- and I didn't want to take any more time experimenting.

 

Edward Reid