cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
537
Views
0
Helpful
5
Replies

pcAnywhere install

refram
Level 3
Level 3

I have a PIX 501 through which I'm trying to allow pcAnywhere to connect.

I have a static IP for my PIX that is different from the static IP's for my pcAnywhere machines. There are 6 IP's total, all continuous and within the same subnet.

The connections were working with the router that was sold to us by the telco when the line was put in.

We are able to hit the internet, and we are able to send and receive internet email on our internal email server.

As an example, here is the format of the static translation I have for one of the pcAnywhere machines:

static (inside,outside) <outside IP> <inside IP> netmask 255.255.255.255 0 0

Here are the lines in the access-list:

access-list outside_access_in permit tcp any host <outside IP> eq pcanywhere-data

access-list outside_access_in permit udp any host <outside IP> eq pcanywhere-status

By the way, I actually put in port 5631 for the first, and 5632 for the second. These were replaced with the translated names by the PIX.

Finally, here is the statement that applies the list:

access-group outside_access_in in interface outside

When I connect to the internet from outside the building and telnet port 5631, I get the response that I'm supposed to get (something like, "Hit Enter"). But I just can't get the actual pcanywhere connection to come up. It always times out.

Any ideas?

5 Replies 5

nkhawaja
Cisco Employee
Cisco Employee

Hi,

Enable Syslogging on the PIX. Get the log message and see if there is any deny.

Thanks

Nadeem

I got it working on a customer site with that access-list.

access-list acl_outside permit udp host RemotePcAnywhereClient host MyPublicIP eq pcanywhere-status

access-list acl_outside permit tcp host RemotePcAnywhereClient host MyPublicIP eq pcanywhere-data

access-list acl_outside permit tcp host RemotePcAnywhereClient host MyPublicIP eq 5632

sincerely

Patrick

I found out something rather odd. It turns out that the configuration I had originally did, in fact work. But I had to try a pcAnywhere connection once, wait for it to fail, and then immediatly try it again. It would then work. I have several pcAnywhere machine set up (two different versions of Windows). In each case, if I try it twice quickly, it works on the second try.

So I (finally) took Nadeem's advice, and looked at the syslog. Turned out that on the initial connection attempt, it was trying to create a link on port 22. I researched this, and found port 22 is an old port used by early versions of pcAnywhere. I have all new versions, but I opened it anyway.

Now, I have the same problem, I still must try to connect twice. But the first time, the port 22 connection is made. It just doesn't seem to try to connect to the other two ports until the second try. The syslog doesn't mention an attempt to connect on 5631 or 5632 (no deny, no mention at all). The second attempt causes connections to be made to all 3 ports (5631, 5632 and 22).

Now what?

Use the PIX "capture" feature to analyze the traffic flow. Be sure you use for toubleshooting a "logg trap info" to see all details of that connection.

Please could you explain me why do you use a telnet instead of using directly the PcAnywhere application to connect ? I am not a PcAnywhere crack !!

sincerely

Patrick

It would seem that I have the solution. I was using a copy of pcAnywhere v.9 to test the connection. Even though pcAnywhere has been using it's registered ports (5631 and 5632) by default for several versions, this one was apparantly still old enough that it was trying the older pcAnywhere ports before it tried the new ones. When I upgraded the pcAnywhere version, everything worked right the first time.