I have a Linksys bfew11s4 v2 and connected to a win2k server. I have some general questions for you guru's out there. If I connect the dsl modem to the router and the router to my server internet and file sharing works fine, but I can't get it to accept incoming vpn using pptp. Should I have DHCP running on the server or only the router? I have the user account created and vpn access given. The client recieves a 678 error when attempting to connect. I tried port forwarding but it didn't seem to help, but DHCP was enabled on both the server and the router. Any help would be great.... even a shove to a good website. Thanks!
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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PPTP server help
- Thread starter rookieP
- Start date
Sorry to be the bearer of bad tidings, BUT... Unless you want to put your machine in teh DMZ, it will not work. Others have said I am incorrect, so you may want to prove me wrong. From experience, I have found that the Linksys product does not recognize IP protocol 47, GRE. So, Good luck, I'd use a different router.... Thanks,
Matt Wray
Matt Wray
John Lewis
Programmer
I'll have a different opinion on this one. I have seen Linksys routers do fine in this situation. Not sure yours will do it, I don't use Linksys, and as such I don't do a good job of keeping up on which one will do what. Do make sure that you have the latest and greatest firmware before you try.
PPTP requires two things . . . TCP on port 1723, and as mattwray stated GRE. The initial connection is made and maintained on TCP/1723. Data is passed through in GRE. If your router is not able to pass GRE, you will get an error when you try to connect. But not this one. This one indicates that the connection isn't even getting to the server, or the server is unable/unwilling to respond. That will be related either to your server configuration or forwarding of TCP on 1723.
Make sure that your server is configured to accept the incoming VPN connection. Connect it directly to your modem to make sure it works at that point -- don't leave it there too long.
Set your router to forward TCP on port 1723 to your server. You may need to enable forwarding of GRE, sometimes called PPTP pass-through.
When you try to make your connection, remember that you are forwarding the traffic from your router, so you need to target your modem IP instead of your server IP.
That assumes that you are using PPTP as your post indicates. If you are using IPsec or L2TP, the rules change slightly. Generally, I stick with PPTP unless I feel there is a real security issue.
On another note, I don't entirely understand your DHCP question. As a practical matter, either your router or your server should be acting as a DHCP server, not both. Either or both may be a client, but only one server. On a small network (up to 12 devices or so), I generally assign fixed IPs to everything and turn off all of the DHCP servers.
PPTP requires two things . . . TCP on port 1723, and as mattwray stated GRE. The initial connection is made and maintained on TCP/1723. Data is passed through in GRE. If your router is not able to pass GRE, you will get an error when you try to connect. But not this one. This one indicates that the connection isn't even getting to the server, or the server is unable/unwilling to respond. That will be related either to your server configuration or forwarding of TCP on 1723.
Make sure that your server is configured to accept the incoming VPN connection. Connect it directly to your modem to make sure it works at that point -- don't leave it there too long.
Set your router to forward TCP on port 1723 to your server. You may need to enable forwarding of GRE, sometimes called PPTP pass-through.
When you try to make your connection, remember that you are forwarding the traffic from your router, so you need to target your modem IP instead of your server IP.
That assumes that you are using PPTP as your post indicates. If you are using IPsec or L2TP, the rules change slightly. Generally, I stick with PPTP unless I feel there is a real security issue.
On another note, I don't entirely understand your DHCP question. As a practical matter, either your router or your server should be acting as a DHCP server, not both. Either or both may be a client, but only one server. On a small network (up to 12 devices or so), I generally assign fixed IPs to everything and turn off all of the DHCP servers.
how is the server connected to the internet, thru the router?
how is the client connected to the internet, thru a router or dial up?
I found that in my case the server was connected to the internet with a internal ip of 192.168.1.50 and the client was connected to with an internal ip of 192.168.1.100. It wouldn't work, the routers were both setup as 192.168.1.1.
When i changed the client's router ip to 192.168.2.1, which changed the client's ip to 192.168.2.100, after a reboot. I had no problems. I found that if the computer dialed in there was no problem.
how is the client connected to the internet, thru a router or dial up?
I found that in my case the server was connected to the internet with a internal ip of 192.168.1.50 and the client was connected to with an internal ip of 192.168.1.100. It wouldn't work, the routers were both setup as 192.168.1.1.
When i changed the client's router ip to 192.168.2.1, which changed the client's ip to 192.168.2.100, after a reboot. I had no problems. I found that if the computer dialed in there was no problem.
- Thread starter
- #6
John Lewis
Programmer
GRE is also known as IP protocol 47. It is the protocol used by PPTP to pass actual data back and forth through the tunnel. It is often confused with port 47 (see the first post from jcostanz), I have even seen this in documents from Microsoft and Cisco . . . both should know better. Port 47 is assigned to a service that no longer has a legitimate use.
Point is, if you are told to forward port 47, ignore it. If you already have it open, close it. The fewer uneeded ports you have open the better.
As I stated earlier, forwarding GRE is often referred to as PPTP pass-through. The pass-through term is more accurate, as you do not have to designate a target. The control connection on port 1723 takes care of that.
PPTP pass-through is on the Advanced tab/Filters in the setup and is enabled by default. Make sure that is still enabled, set port 1723 / TCP to forward and you should be set.
Point is, if you are told to forward port 47, ignore it. If you already have it open, close it. The fewer uneeded ports you have open the better.
As I stated earlier, forwarding GRE is often referred to as PPTP pass-through. The pass-through term is more accurate, as you do not have to designate a target. The control connection on port 1723 takes care of that.
PPTP pass-through is on the Advanced tab/Filters in the setup and is enabled by default. Make sure that is still enabled, set port 1723 / TCP to forward and you should be set.
- Thread starter
- #8
Thanks for the great info. I still must be screwing something up though. Here is my current situation.
I have DHCP only running on the Router now, and not on the Server. I forwarded ports 1723 to the static IP of the servers NIC. (Tried 47 and 1723 both at one point with no success) LAN Clients are able to get network shares and access internet. For some reason the server is no longer able to get internet access, and when an outside user attempts to connect to my VPN the error changed from 678 to 721. A different error is cool though because at least they seem to be communicating at least on some level, but it does seem to be more of an argument that a friendly chat. It errors at the verifying username and password message.
Did I mess up their account in the active directory or something? I checked it and everything seemed okay.
Thanks in advance. You guys are great!
I have DHCP only running on the Router now, and not on the Server. I forwarded ports 1723 to the static IP of the servers NIC. (Tried 47 and 1723 both at one point with no success) LAN Clients are able to get network shares and access internet. For some reason the server is no longer able to get internet access, and when an outside user attempts to connect to my VPN the error changed from 678 to 721. A different error is cool though because at least they seem to be communicating at least on some level, but it does seem to be more of an argument that a friendly chat. It errors at the verifying username and password message.
Did I mess up their account in the active directory or something? I checked it and everything seemed okay.
Thanks in advance. You guys are great!
John Lewis
Programmer
Well, you are making progress. The first error you had indicated that the TCP packets were not getting to the server at all. This error tends to indicate that they are getting there, but the server is unwilling or unable to respond. This is related directly to the fact that you have lost internet connectivity on that particular machine. The response has to be sent across the internet, just like your regular internet traffic. Haven't got far enough to indicate/rule out a AD or authentication problem yet.
From reading your earlier posts in this thread, I would suspect that you had the VPN server setup for DHCP at one time, but have since assigned a fixed private IP. That should be fine, except DHCP does more than assign an IP. It also sets the DNS server and the default gateway. I am thinking that when you assigned a fixed IP you did not set the default gateway, and perhaps not the DNS server as well. You will need to configure these in network properties. The default gateway should be set to private IP of your router, DNS should be set to the DNS server provided by your ISP.
I am also guessing that you are able to access LAN resources from the server. If not, post back as the steps will be slightly different.
Check (or double check) those items first. If that is not the source of the problem, some troubleshooting is in order.
Before we start, the following are not pass/fail tests. The specific response to each command is important, so if you need further help report back with the specifics, not just 'it doesn't work'. Having said that, in a command window:
Type 'ping yahoo.com' and press enter.
A response of 'unknown host' indicates a problem with the DNS server. Could be that it is not set to the correct IP, or a routing issue.
A response of 'no route to host' or 'destination unreachable' indicates a routing problem.
If 'ping yahoo.com' results in anything other than 'Reply form xxx.xxx.xxx.xxx . . . ' then try 'ping 64.58.79.230'.
Type 'ping xxx.xxx.xxx.xxx' replacing the xxx.xxx.xxx.xxx with the address of your ISP's default gateway.
Try 'tracert 64.58.79.230'
Type 'ipconfig' Check the results against what you entered in the network settings.
Type 'route print' This will print your routing table.
Since you have other computers that are accessing the internet properly, you can try the same commands on one of those to see what you should be getting. Again, if you need help sorting out the output from these commands, provide the specific results. It's ok to include private IP numbers for clarity (192.168.###.###), but any public IP numbers should be masked out, (64.58.xxx.xxx). That's a good rule to follow any time you are posting to the internet.
Above all, don't get discouraged, you are making progress. You may see several different errors before you get everything ironed out, but once you get everything going it should be low maintenance.
From reading your earlier posts in this thread, I would suspect that you had the VPN server setup for DHCP at one time, but have since assigned a fixed private IP. That should be fine, except DHCP does more than assign an IP. It also sets the DNS server and the default gateway. I am thinking that when you assigned a fixed IP you did not set the default gateway, and perhaps not the DNS server as well. You will need to configure these in network properties. The default gateway should be set to private IP of your router, DNS should be set to the DNS server provided by your ISP.
I am also guessing that you are able to access LAN resources from the server. If not, post back as the steps will be slightly different.
Check (or double check) those items first. If that is not the source of the problem, some troubleshooting is in order.
Before we start, the following are not pass/fail tests. The specific response to each command is important, so if you need further help report back with the specifics, not just 'it doesn't work'. Having said that, in a command window:
Type 'ping yahoo.com' and press enter.
A response of 'unknown host' indicates a problem with the DNS server. Could be that it is not set to the correct IP, or a routing issue.
A response of 'no route to host' or 'destination unreachable' indicates a routing problem.
If 'ping yahoo.com' results in anything other than 'Reply form xxx.xxx.xxx.xxx . . . ' then try 'ping 64.58.79.230'.
Type 'ping xxx.xxx.xxx.xxx' replacing the xxx.xxx.xxx.xxx with the address of your ISP's default gateway.
Try 'tracert 64.58.79.230'
Type 'ipconfig' Check the results against what you entered in the network settings.
Type 'route print' This will print your routing table.
Since you have other computers that are accessing the internet properly, you can try the same commands on one of those to see what you should be getting. Again, if you need help sorting out the output from these commands, provide the specific results. It's ok to include private IP numbers for clarity (192.168.###.###), but any public IP numbers should be masked out, (64.58.xxx.xxx). That's a good rule to follow any time you are posting to the internet.
Above all, don't get discouraged, you are making progress. You may see several different errors before you get everything ironed out, but once you get everything going it should be low maintenance.
For the server's internet access, make sure that the server's TCP IP settings include the DNS server address for your connection, the DNS server address set in the router, along with the default gateway set to the address of the router, typ 192.168.1.1.
I got error 721 when I first tried, The problem was that the client was connected to a router with an IP of 192.168.1.1 and the server was connected to a router with an IP of 192.168.1.1. I solved this problem by changing the client's router ip to 192.168.2.1 which also changed the client's ip from 192.168.1.100 to 192.168.2.100, this is the ip without the vpn connection.
I got error 721 when I first tried, The problem was that the client was connected to a router with an IP of 192.168.1.1 and the server was connected to a router with an IP of 192.168.1.1. I solved this problem by changing the client's router ip to 192.168.2.1 which also changed the client's ip from 192.168.1.100 to 192.168.2.100, this is the ip without the vpn connection.
- Thread starter
- #11
mhkwood you were right on the money about Internet access on the server. Still having trouble with the VPN though. Here's what i have...
When looking on the html interface for my dsl modem I saw this:
Wan IP: 66.xx.xx.xx
dns 64.xx.xx.xx
Lan port: 172.B
dhcp info: 172.A
My linksys was
wan IP 172.A
gateway: 172.B
dns: 172.B
now, internet access works on the server with the servers gateway at: 192.168.1.1 and dns either: 172.A, or 172.B Is that strange that either work?
Also I'm having my buddy attempt to connect to the 66.xx Ip when he gets the 721 error.
I was reading some other posts and noticed some problems with having multiple NIC's. My server does have 2 nics, but one is disabled. If you think it would help I don't mind pulling it.
The client is connecting from an xp machine coming through a dsl modem.
I performed the troubleshooting you mentioned in the last post but I figured since internet does work on the server now you don't need it.
Thanks for the encourgement and all the advice. It seems like with your help I get a little closer every night.
When looking on the html interface for my dsl modem I saw this:
Wan IP: 66.xx.xx.xx
dns 64.xx.xx.xx
Lan port: 172.B
dhcp info: 172.A
My linksys was
wan IP 172.A
gateway: 172.B
dns: 172.B
now, internet access works on the server with the servers gateway at: 192.168.1.1 and dns either: 172.A, or 172.B Is that strange that either work?
Also I'm having my buddy attempt to connect to the 66.xx Ip when he gets the 721 error.
I was reading some other posts and noticed some problems with having multiple NIC's. My server does have 2 nics, but one is disabled. If you think it would help I don't mind pulling it.
The client is connecting from an xp machine coming through a dsl modem.
I performed the troubleshooting you mentioned in the last post but I figured since internet does work on the server now you don't need it.
Thanks for the encourgement and all the advice. It seems like with your help I get a little closer every night.
John Lewis
Programmer
Sorry for the delayed reply. Have been reviewing your info. Not an easy one for long distance troubleshooting.
The DNS behavior you are seeing is normal. Generally, a DSL modem will forward DNS requests to the server in it's configuration.
As to the second NIC, pull it. Don't think it's the problem, especially if it is disabled, but I would eliminate the possibility.
Microsoft is not nice about providing good error messages here. Could be one or more of several things, but we have eliminated some with restoring your internet connectivity.
A) When trying to make the connection, try to ping the client's address from the server to make sure that the path back to the client is good.
B) Is the client behind a router? Has it been configured to pass PPTP like yours?
C) The VPN IP addresses should be on a subnet that is different than the subnet of the LAN on the server side. Looks like you are using 192.168.1.0 for the server LAN, so you could use 192.168.2.0 for the VPN IP's. If the client is using a router with NAT, it should be configured with a network address different than the VPN network IP. Also, if you ever want to forward traffic on either the client network or the server network, those addresses should be different as well. If these addresses are on the same subnet, the server and/or client will get confused about where to send VPN traffic. This could cause the error you are seeing.
D) Hate XP. Hate it. Maybe I'll get used to it eventually, but I have been avoiding it. Check the built-in firewall on the client side. It will need to allow the outbound connection to 1723/tcp and allow GRE both ways. Not sure how to configure that at this point, other than to upgrade to Windows 2000. Of course, if there is a router on the client side, it will need to be configured to pass the traffic as well.
E) When all else fails, install a packet sniffer to see if the traffic is going to port 1723 and if the reply is being sent, and to where. I like ethereal ( Works great and the price is right (can you spell f r e e ?).
E.1) Turn on ppp logging on the server. See . Make sure you turn it back off at some point. Can eat lots of hard drive real fast.
Hope some of this makes some sense as it is late. Post back and we'll try some more.
The DNS behavior you are seeing is normal. Generally, a DSL modem will forward DNS requests to the server in it's configuration.
As to the second NIC, pull it. Don't think it's the problem, especially if it is disabled, but I would eliminate the possibility.
Microsoft is not nice about providing good error messages here. Could be one or more of several things, but we have eliminated some with restoring your internet connectivity.
A) When trying to make the connection, try to ping the client's address from the server to make sure that the path back to the client is good.
B) Is the client behind a router? Has it been configured to pass PPTP like yours?
C) The VPN IP addresses should be on a subnet that is different than the subnet of the LAN on the server side. Looks like you are using 192.168.1.0 for the server LAN, so you could use 192.168.2.0 for the VPN IP's. If the client is using a router with NAT, it should be configured with a network address different than the VPN network IP. Also, if you ever want to forward traffic on either the client network or the server network, those addresses should be different as well. If these addresses are on the same subnet, the server and/or client will get confused about where to send VPN traffic. This could cause the error you are seeing.
D) Hate XP. Hate it. Maybe I'll get used to it eventually, but I have been avoiding it. Check the built-in firewall on the client side. It will need to allow the outbound connection to 1723/tcp and allow GRE both ways. Not sure how to configure that at this point, other than to upgrade to Windows 2000. Of course, if there is a router on the client side, it will need to be configured to pass the traffic as well.
E) When all else fails, install a packet sniffer to see if the traffic is going to port 1723 and if the reply is being sent, and to where. I like ethereal ( Works great and the price is right (can you spell f r e e ?).
E.1) Turn on ppp logging on the server. See . Make sure you turn it back off at some point. Can eat lots of hard drive real fast.
Hope some of this makes some sense as it is late. Post back and we'll try some more.
- Thread starter
- #13
Well..... I took the router out of the picture. I have 1 nic from the server connected to the dsl modem, and the other into a hub. The server is doing dhcp and all pc's get internet, and can file share. I can VPN into the server from a client when I type the server name or local IP. External clients still get 721 error. I craps out right after showing 'verifying user name and password'. I noticed that if he pings the ip of the server... 172.xx.xx he gets a timeout response. He can get replies from the WAN IP 66.xx, but he can't vpn to that address, or he'll get a 678. Thanks for being so helpfull and so patient.
John Lewis
Programmer
Well, I'm just a little bit lost here.
First, not enough of the 172. address to tell for sure, but I addume this is part of the private network on the server side? The second number is between 16-31?
Now, assuming that is the case, a ping timeout to that address would be expected, as would a 678 error from the VPN connection. This is a private address and as such is not routable over the internet. The client doesn't know how to get there for a ping or a VPN connection.
Based upon what you have posted, I would look for a problem on the client side. You didn't mention a router on that side, but if it is there, it will need to have pptp pass-through enabled. Port forwarding there is not needed, should be allowed back through as a 'related' connection. XP's built in firewall software could be a problem. Not real sure how to deal with it, XP is not my thing. Did I ever mention that I hated it?
Next step would be to start looking at the packets. See the Ethereal link in a previous post. Best to try when your private network is otherwise quiet. On the server side, you will see a tcp packet come in on port 1721. You should then see packet returned to the client. This is the one that should be causing a 721 error. Pay attention to where it is going. Should be the address of the modem on the client side -- the modem will forward directly to whatever is plugged into the LAN port. Try a ping to that address, and a tracert if the ping comes back with anything other than a reply. If it is being pointed somewhere else, need to figure out why.
If all is well on the server side, look at the packets on the client side. Again, Ethereal would be my tool of choice. You will see the outbound tcp to 1721 at the server, then a response back. Again, the error you are seeing would indicate that the response isn't getting there, generally.
If you get that far and all looks well, next suspect would be a GRE problem somewhere. I would expect a different error from that, but Microsoft plays with the error messages from time to time, so anything is possible. Check that out and post back. If you see that the initial TCP packets aren't going where they are supposed to, post back with the next set of numbers in the 172. addresses and as many specifics as you can.
First, not enough of the 172. address to tell for sure, but I addume this is part of the private network on the server side? The second number is between 16-31?
Now, assuming that is the case, a ping timeout to that address would be expected, as would a 678 error from the VPN connection. This is a private address and as such is not routable over the internet. The client doesn't know how to get there for a ping or a VPN connection.
Based upon what you have posted, I would look for a problem on the client side. You didn't mention a router on that side, but if it is there, it will need to have pptp pass-through enabled. Port forwarding there is not needed, should be allowed back through as a 'related' connection. XP's built in firewall software could be a problem. Not real sure how to deal with it, XP is not my thing. Did I ever mention that I hated it?
Next step would be to start looking at the packets. See the Ethereal link in a previous post. Best to try when your private network is otherwise quiet. On the server side, you will see a tcp packet come in on port 1721. You should then see packet returned to the client. This is the one that should be causing a 721 error. Pay attention to where it is going. Should be the address of the modem on the client side -- the modem will forward directly to whatever is plugged into the LAN port. Try a ping to that address, and a tracert if the ping comes back with anything other than a reply. If it is being pointed somewhere else, need to figure out why.
If all is well on the server side, look at the packets on the client side. Again, Ethereal would be my tool of choice. You will see the outbound tcp to 1721 at the server, then a response back. Again, the error you are seeing would indicate that the response isn't getting there, generally.
If you get that far and all looks well, next suspect would be a GRE problem somewhere. I would expect a different error from that, but Microsoft plays with the error messages from time to time, so anything is possible. Check that out and post back. If you see that the initial TCP packets aren't going where they are supposed to, post back with the next set of numbers in the 172. addresses and as many specifics as you can.
Hey,
Did you ever figure out what is wrong? I have an eerily similar problem--which I can't figrue out. In my house I have a box with Windows 2000 Server connected to a LinkSys bfew11s4 v2, which is connected to a cable modem. I have a static IP address assigned to by my ISP. I can use Terminal Services to Remote Desktop into my pc at home from my pc at work [which tells me I can get to my box and do interesting things from work]. I can also VPN to that box from any box at work running Windows 2000. However, if I vpn to my box at home from a box running XP, it works the first time--but when I disconnect I have to wait 20 minutes before I can make another connection from that xp box. I have no problem if I try to vpn to my server from within the router using up boxes as long as I vpn to the lan address (ie 192.168.1.xxx). Any ideas?
Did you ever figure out what is wrong? I have an eerily similar problem--which I can't figrue out. In my house I have a box with Windows 2000 Server connected to a LinkSys bfew11s4 v2, which is connected to a cable modem. I have a static IP address assigned to by my ISP. I can use Terminal Services to Remote Desktop into my pc at home from my pc at work [which tells me I can get to my box and do interesting things from work]. I can also VPN to that box from any box at work running Windows 2000. However, if I vpn to my box at home from a box running XP, it works the first time--but when I disconnect I have to wait 20 minutes before I can make another connection from that xp box. I have no problem if I try to vpn to my server from within the router using up boxes as long as I vpn to the lan address (ie 192.168.1.xxx). Any ideas?
- Status
Similar threads
- Locked
- Question
- Locked
- Question