I believe I have correctly set up the server that I am trying to tunnel into, which is running NT 4.0. I set up the PPTP protocol and gave it a range of IP addresses that it can use. I am able to VPN into the server, but when I try to tunnel in with PC Anywhere, I get the message "Unable to attach to specified device." I can ping the client IP address but not the server IP address. I have the following ports enabled, 500, 47, 1723, 5631 and 5632. Is there anything that I could have done wrong in the setup on the server I am trying to tunnel into?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
I believe I have correctly set up t
- Thread starter mauirlm
- Start date
John Lewis
Programmer
You need to close some ports. 47, 5631 and 5632 should be closed. You will need either tcp/1723 for PPTP or udp/500 for IPsec open, but the others should be closed. If your firewall is on the VPN server, you may need to open the PCAnywhere ports for the VPN virtual adapter, but not on the LAN/WAN adapter.
I can ping the client IP address but not the server IP address.
Not real clear. Where are you pinging from -- the client or the server? Which address are you pinging for the server, the VPN IP or the LAN IP? Also, you can always ping. You won't always get a good reply, but the specific message is important. What response are you getting.
Assuming you are trying to ping the server's LAN address from the client, I would guess you are getting a 'no route to host' message. If you need to connect only to the server, you should be able to do so using the server's VPN IP, subject to properly configuring any firewall residing on the server to allow the traffic on the VPN adapter. If the firewall is somewhere other than the VPN server, you are already past that, so it is not an issue.
Another possibility is that the VPN IP addresses are in the same network as your client IP addresses. Depending upon your OS, this can be a problem, even when trying to reach the VPN server. If your client has an IP of 192.168.1.100 on it's LAN and the VPN IP is 192.168.1.200, any connection you attempt over the VPN is routed to the client network instead of across the VPN.
If you need to access other resources on the server LAN, you will need to add a route on the client side to the server LAN.
Hope this gives you a start. Post back with more info if you need further direction.
I can ping the client IP address but not the server IP address.
Not real clear. Where are you pinging from -- the client or the server? Which address are you pinging for the server, the VPN IP or the LAN IP? Also, you can always ping. You won't always get a good reply, but the specific message is important. What response are you getting.
Assuming you are trying to ping the server's LAN address from the client, I would guess you are getting a 'no route to host' message. If you need to connect only to the server, you should be able to do so using the server's VPN IP, subject to properly configuring any firewall residing on the server to allow the traffic on the VPN adapter. If the firewall is somewhere other than the VPN server, you are already past that, so it is not an issue.
Another possibility is that the VPN IP addresses are in the same network as your client IP addresses. Depending upon your OS, this can be a problem, even when trying to reach the VPN server. If your client has an IP of 192.168.1.100 on it's LAN and the VPN IP is 192.168.1.200, any connection you attempt over the VPN is routed to the client network instead of across the VPN.
If you need to access other resources on the server LAN, you will need to add a route on the client side to the server LAN.
Hope this gives you a start. Post back with more info if you need further direction.
- Thread starter
- #3
mhkwood, you were working we me on this probelem earlier. It was a post at You didn't post back from my last post.
Anway, let's get the locations in sync. I am here at home, trying to tunnell into a customer's server. I guess I have the LAN IP on my side and my customer is on the VPN IP side. I am pinging from my home, and can ping the client IP address but not the server IP address, as called out in the details of the VPN connection. When I try to pine the server IP address, I get "request timed out."
The client IP address I am trying to ping is 204.182.234.161 and the server IP address I am trying to ping is 204.182.234.160. Those are both out of the address range I assinged to the RAS.
Let me know if I have answered your questions so far. I am not really sure what you mean when you say "other resources on the server LAN" would that mean other hosts at my customer's site?
Anway, let's get the locations in sync. I am here at home, trying to tunnell into a customer's server. I guess I have the LAN IP on my side and my customer is on the VPN IP side. I am pinging from my home, and can ping the client IP address but not the server IP address, as called out in the details of the VPN connection. When I try to pine the server IP address, I get "request timed out."
The client IP address I am trying to ping is 204.182.234.161 and the server IP address I am trying to ping is 204.182.234.160. Those are both out of the address range I assinged to the RAS.
Let me know if I have answered your questions so far. I am not really sure what you mean when you say "other resources on the server LAN" would that mean other hosts at my customer's site?
John Lewis
Programmer
Sorry, not sure how I missed your last post in the other thread.
I think you're real close here. I would start by changing the addresses you have assigned in RAS. Try something like 192.168.170.xxx.
The 204.182.234.xxx addresses are routable public IPs. I think that when you try ping to the server VPN IP, it is being routed across the internet and hitting the firewall instead of being routed across the VPN. You could verify this by typing 'tracert 204.182.234.xxx' (replacing the xxx as appropriate for your VPN server) at a command prompt. Be patient, it may take a bit to see the results, but I would expect you to a few hits across the internet and then several 'no reply' messages.
My first thought was that the network at that site had been setup incorrectly, but after a bit of research it appears that your client has obtained a block of IPs. If this is not the case, the remote network should be reconfigured to use one of the private address blocks.
Either way, the VPN is a 'private' network and should use one of the private IPs. It should be different than the network IP on the client side, and if you do need to readdress the server network, it should be different than what you use there. Based upon your current configuration, I would use 192.168.170.xxx for your VPN addresses.
I think that will get you all fixed up. Do remember to close those other ports on the firewall, as I mentioned in my earlier post in this thread. That is especially dangerous if the public IPs on the server network are legitimate. pcAnywhere is very unsecure, and with the addresses being routable . . . close them soon.
If that doesn't work, again post the results of your ping (after changing the RAS addresses). Also, do the 'tracert' and report your results.
By the way . . . "other resources on the server LAN" would mean other hosts at your customer's site. If you are just using pcAnywhere to the VPN server, not an issue.
Good luck!
I think you're real close here. I would start by changing the addresses you have assigned in RAS. Try something like 192.168.170.xxx.
The 204.182.234.xxx addresses are routable public IPs. I think that when you try ping to the server VPN IP, it is being routed across the internet and hitting the firewall instead of being routed across the VPN. You could verify this by typing 'tracert 204.182.234.xxx' (replacing the xxx as appropriate for your VPN server) at a command prompt. Be patient, it may take a bit to see the results, but I would expect you to a few hits across the internet and then several 'no reply' messages.
My first thought was that the network at that site had been setup incorrectly, but after a bit of research it appears that your client has obtained a block of IPs. If this is not the case, the remote network should be reconfigured to use one of the private address blocks.
Either way, the VPN is a 'private' network and should use one of the private IPs. It should be different than the network IP on the client side, and if you do need to readdress the server network, it should be different than what you use there. Based upon your current configuration, I would use 192.168.170.xxx for your VPN addresses.
I think that will get you all fixed up. Do remember to close those other ports on the firewall, as I mentioned in my earlier post in this thread. That is especially dangerous if the public IPs on the server network are legitimate. pcAnywhere is very unsecure, and with the addresses being routable . . . close them soon.
If that doesn't work, again post the results of your ping (after changing the RAS addresses). Also, do the 'tracert' and report your results.
By the way . . . "other resources on the server LAN" would mean other hosts at your customer's site. If you are just using pcAnywhere to the VPN server, not an issue.
Good luck!
- Thread starter
- #5
When I run tracert against the Server IP address, it doesn't go anywhere and I get a "Request Timed Out" on the first hop, and it just repeats.
So here is the scenario I am set up with:
192.168.169.199---192.168.169.1---10.100.16.246---Firewall-
My PC Sonic Wall WAN side At ISP |
|
204.182.234.XX---204.182.234.1---10-100-16.87---|
Customer's Linksys WAN side
Server Router
The customer's 204.182.234.XX addresses are behind a Firewall and a Router. I didn't set those addresses up, another guy did that. We are all hooked up to the same ISP and it looks like the same router at the ISP.
I gave the RAS addresses the range of 192.168.170.160 through 192.168.170.165. Any idea why I can't get past the first hop on a tracert?
So here is the scenario I am set up with:
192.168.169.199---192.168.169.1---10.100.16.246---Firewall-
My PC Sonic Wall WAN side At ISP |
|
204.182.234.XX---204.182.234.1---10-100-16.87---|
Customer's Linksys WAN side
Server Router
The customer's 204.182.234.XX addresses are behind a Firewall and a Router. I didn't set those addresses up, another guy did that. We are all hooked up to the same ISP and it looks like the same router at the ISP.
I gave the RAS addresses the range of 192.168.170.160 through 192.168.170.165. Any idea why I can't get past the first hop on a tracert?
John Lewis
Programmer
Had to read this a few times, but I think I've got it now. Looks like your addresses are OK. tracert uses a series of ping requests to produce it's info. When you tracert to your VPN server VPN address, the VPN server should be the first hop. If it is not able to respond to a ping, you will see exactly what you are reporting.
I am working under the assumption that the addresses on the server side are legitimate public and routable IPs. That being the case, I would imagine that some kind of firewall is running on each of the computers there. I would suspect that none of them are able to respond to ping requests.
Check to see if something is running there. Keep in mind that the VPN creates a virtual network interface, so you will need to enable the ports on that interface. Without knowing what is running there, it's hard to say exactly how to go about that.
On a related note, I haven't worked with pcAnywhere since . . . well, it's been a while -- VNC is cheaper. Anyway, you might need to enable it on the PPP interface as well. In fact, you might be able to get that to work without addressing the ping issue if there is firewall software running. On the other hand, you may need to open the appropriate ports in the software as well.
Hope this makes sense, it's another of those late-nite posts.
I am working under the assumption that the addresses on the server side are legitimate public and routable IPs. That being the case, I would imagine that some kind of firewall is running on each of the computers there. I would suspect that none of them are able to respond to ping requests.
Check to see if something is running there. Keep in mind that the VPN creates a virtual network interface, so you will need to enable the ports on that interface. Without knowing what is running there, it's hard to say exactly how to go about that.
On a related note, I haven't worked with pcAnywhere since . . . well, it's been a while -- VNC is cheaper. Anyway, you might need to enable it on the PPP interface as well. In fact, you might be able to get that to work without addressing the ping issue if there is firewall software running. On the other hand, you may need to open the appropriate ports in the software as well.
Hope this makes sense, it's another of those late-nite posts.
- Thread starter
- #7
I have mentioned before that the customer had a SonicWall in place and I could tunnel into the whole network after establishing a VPN through SonicWall. I replaced the SonicWall with the Linksys and have told you what ports I have enabled. I have enabled some of the ports on the router that talks to the Linksys. What ports do you think I should have open. I am not sure what ports are opened on the firewall at the ISP. What ports do you think should be opened there? I am guessing that I would need to have ping enabled on both the ISPs router and firewall, which might be on in the same. I can check that out. Basically I need to know what ports to have opened.
John Lewis
Programmer
You only need the ports associated with the VPN forwarded on to the server. Read back over both posts, but still not sure if you are dealing with PPTP or IPSec. For PPTP, you should have TCP/1723 forwarded and PPTP pass-through enabled (called GRE protocol in a few routers, don't think you have anything that applies to). If you are using IPSec, it would be UDP/500 with IPSec pass-through enabled.
You don't need anything else open to access resources on the remote network, as anything you do over the VPN is wrapped up in a packet that passes through the router/firewall (either in a PPTP or IPSec packet). The firewall isn't aware/doesn't care what you are sending in the VPN packets. If the VPN is connecting, and it sounds like it is, you have enough ports open, at least at any point between the two computers participating in the VPN.
You should allow ICMP requests to allow for troubleshooting. You may need to ping or traceroute to the router at some point. I generally setup rules to block ICMP after 50 requests in 30 seconds or 700 in 10 minutes -- allows for a single source to ping constantly, but kills a DOS attack at that level. Not a big issue.
It sounds like the VPN is running fine, your addresses are ok. Possible problems left at this point . . .
A) Firewall software on either the VPN server or VPN client. Again, this will vary depending upon what you have installed, but the VPN will create a virtual network interface, and anything coming in on this interface is VPN traffic and should be allowed. If you have software installed, and it allows you to further limit traffic by IP address, you may want to limit it to traffic coming in on the VPN interface that has a source address on the same subnet as the VPN. Would try without it first, just to get things running.
On that note, NT 4.0 does have IP filtering built in, but it uses a system wide policy, if you are able to ping the server from within the server side LAN, that is not an issue.
B) You could still have routing issues. I would discount this possibility, as you should see a 'no route to host' response to your ping or tracert after changing the IP addresses. This may become an issue if you try to work with other machines on the server side network, if you need to connect to a computer at 204.182.234.xxx other than the VPN server (which you are connecting to at 192.170.160.xxx, right?) routing will nedd to be configured to send the traffic over the VPN instead of the public internet. Note that if you connect to the VPN server with pcAnywhere and use other resources from there, this is not an issue as you are technically not connecting to those computers over the VPN, you are connected to the VPN server which is in turn connecting to those computers.
On that note, it would be interesting to see what happens if you were to try these from the VPN server to the VPN client if problems persist.
C) This is where I think the problem lies (at least with pcAnywhere). I don't work with pcAnywhere, but I got curious and had to poke around a bit. As I suspected, pcAnywhere only connects to the first configured IP address by default. In your case, this would be the server side LAN IP, which you will not be able to hit without the routing. It is going to be more efficient to connect to the VPN IP anyway, so you need to enable it there. Take a look here: I would set it to allow connections on all network adapters, at least until you get it working to your satisfaction, then change it to listen only on the VPN IP if you feel the need later.
A lot of ifs/ands/buts here, but (there went another) I hope to have given you a good direction. Sorry if I repeat and/or forget details here and there, the threads run together sometimes.
Do post back if you need further clarification, or if something just doesn't work. You were close, and you still are. Has to be something minor, so hang in.
You don't need anything else open to access resources on the remote network, as anything you do over the VPN is wrapped up in a packet that passes through the router/firewall (either in a PPTP or IPSec packet). The firewall isn't aware/doesn't care what you are sending in the VPN packets. If the VPN is connecting, and it sounds like it is, you have enough ports open, at least at any point between the two computers participating in the VPN.
You should allow ICMP requests to allow for troubleshooting. You may need to ping or traceroute to the router at some point. I generally setup rules to block ICMP after 50 requests in 30 seconds or 700 in 10 minutes -- allows for a single source to ping constantly, but kills a DOS attack at that level. Not a big issue.
It sounds like the VPN is running fine, your addresses are ok. Possible problems left at this point . . .
A) Firewall software on either the VPN server or VPN client. Again, this will vary depending upon what you have installed, but the VPN will create a virtual network interface, and anything coming in on this interface is VPN traffic and should be allowed. If you have software installed, and it allows you to further limit traffic by IP address, you may want to limit it to traffic coming in on the VPN interface that has a source address on the same subnet as the VPN. Would try without it first, just to get things running.
On that note, NT 4.0 does have IP filtering built in, but it uses a system wide policy, if you are able to ping the server from within the server side LAN, that is not an issue.
B) You could still have routing issues. I would discount this possibility, as you should see a 'no route to host' response to your ping or tracert after changing the IP addresses. This may become an issue if you try to work with other machines on the server side network, if you need to connect to a computer at 204.182.234.xxx other than the VPN server (which you are connecting to at 192.170.160.xxx, right?) routing will nedd to be configured to send the traffic over the VPN instead of the public internet. Note that if you connect to the VPN server with pcAnywhere and use other resources from there, this is not an issue as you are technically not connecting to those computers over the VPN, you are connected to the VPN server which is in turn connecting to those computers.
On that note, it would be interesting to see what happens if you were to try these from the VPN server to the VPN client if problems persist.
C) This is where I think the problem lies (at least with pcAnywhere). I don't work with pcAnywhere, but I got curious and had to poke around a bit. As I suspected, pcAnywhere only connects to the first configured IP address by default. In your case, this would be the server side LAN IP, which you will not be able to hit without the routing. It is going to be more efficient to connect to the VPN IP anyway, so you need to enable it there. Take a look here: I would set it to allow connections on all network adapters, at least until you get it working to your satisfaction, then change it to listen only on the VPN IP if you feel the need later.
A lot of ifs/ands/buts here, but (there went another) I hope to have given you a good direction. Sorry if I repeat and/or forget details here and there, the threads run together sometimes.
Do post back if you need further clarification, or if something just doesn't work. You were close, and you still are. Has to be something minor, so hang in.
- Thread starter
- #9
So you are saying that since the VPN is working, that I don't need to open any more ports. The reason ports 5631 and 5632 are opened (see above) is because those are the ports for pcAnywhere.
How would I allow ICMP request? I could find all kinds of information on what ICMP was, but not how to implement it. By a port?
When you ask "the VPN server which you are connecting to at 192.170.160.xxx, right?) you mean the RAS addresses I have set up, correct? I have them set up as 192.168.170.XXX. When you say "routing will nedd to be configured to send the traffic over the VPN instead of the public internet" you mean the routing from the VPN server to the rest of the hosts on the network, right?
I tried the index thing on my side at home. I set the index to three and then four, which either should have worked, right? Didn't seem to fix them problem.
Let me know about how to enable the ICMP.
How would I allow ICMP request? I could find all kinds of information on what ICMP was, but not how to implement it. By a port?
When you ask "the VPN server which you are connecting to at 192.170.160.xxx, right?) you mean the RAS addresses I have set up, correct? I have them set up as 192.168.170.XXX. When you say "routing will nedd to be configured to send the traffic over the VPN instead of the public internet" you mean the routing from the VPN server to the rest of the hosts on the network, right?
I tried the index thing on my side at home. I set the index to three and then four, which either should have worked, right? Didn't seem to fix them problem.
Let me know about how to enable the ICMP.
John Lewis
Programmer
So you are saying that since the VPN is working, that I don't need to open any more ports.
Correct.
The reason ports 5631 and 5632 are opened (see above) is because those are the ports for pcAnywhere.
Nope. The VPN shoots right through the firewall. You can send anything over the VPN, regardless of your firewall rules. Only exception would be a software firewall residing on the VPN server, which might need to have ports opened.
ICMP is a protocol and is not related to a specific port. The procedure varies between between firewalls, so I'm not sure of the specifics for your situation. Not a big deal, other than if it is not enabled you will not get a reply from a ping request.
. . . you mean the routing from the VPN server to the rest of the hosts on the network, right?
Yep.
I tried the index thing on my side at home. I set the index to three and then four, which either should have worked, right? Didn't seem to fix them problem.
Didn't follow that at all. What are you changing?
Sorry for the delay, haven't had time to write anything of any substance for a few days.
Correct.
The reason ports 5631 and 5632 are opened (see above) is because those are the ports for pcAnywhere.
Nope. The VPN shoots right through the firewall. You can send anything over the VPN, regardless of your firewall rules. Only exception would be a software firewall residing on the VPN server, which might need to have ports opened.
ICMP is a protocol and is not related to a specific port. The procedure varies between between firewalls, so I'm not sure of the specifics for your situation. Not a big deal, other than if it is not enabled you will not get a reply from a ping request.
. . . you mean the routing from the VPN server to the rest of the hosts on the network, right?
Yep.
I tried the index thing on my side at home. I set the index to three and then four, which either should have worked, right? Didn't seem to fix them problem.
Didn't follow that at all. What are you changing?
Sorry for the delay, haven't had time to write anything of any substance for a few days.
- Thread starter
- #11
- Status
Similar threads
- Locked
- Solved
- Locked
- Question