09-29-2004 12:54 PM - edited 03-09-2019 08:56 AM
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?
09-29-2004 03:32 PM
Hi,
Enable Syslogging on the PIX. Get the log message and see if there is any deny.
Thanks
Nadeem
09-29-2004 04:56 PM
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
09-30-2004 06:49 AM
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?
09-30-2004 07:16 AM
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
10-01-2004 12:38 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide