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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
use a VPN with internet access? 1
- Thread starter hemec226
- Start date
I'm relatively new to VPNs but, after some wrestling, I have put one together as a pilot.
If you use a service such as ADSL and a couple of routers to provide a LAN to LAN VPN, you will find that traffic not directed at the other LAN will go to the internet.
This makes it very efficient from the perspective of any central site providing shared resources.
I have used Draytek Vigor 2600 routers (based on price primarily) and they do the job very well.
One or two considerations you do need to think about:
1) At least one end should have fixed IP (both if possible), although it is possible to do without (apparently).
2) The LANs should have different local IP subnets, if they are both 192.168.1.x mask 255.255.255.0
you will not be able to route traffic over the VPN - so set one to another range (like 192.168.2.x with a mask of 255.255.255.0)
I hope this helps, one other tip - if you are in the UK, I couldn't recommend getting your ADSL from BT!
Regards
Griff
Keep [Smile]ing
If you use a service such as ADSL and a couple of routers to provide a LAN to LAN VPN, you will find that traffic not directed at the other LAN will go to the internet.
This makes it very efficient from the perspective of any central site providing shared resources.
I have used Draytek Vigor 2600 routers (based on price primarily) and they do the job very well.
One or two considerations you do need to think about:
1) At least one end should have fixed IP (both if possible), although it is possible to do without (apparently).
2) The LANs should have different local IP subnets, if they are both 192.168.1.x mask 255.255.255.0
you will not be able to route traffic over the VPN - so set one to another range (like 192.168.2.x with a mask of 255.255.255.0)
I hope this helps, one other tip - if you are in the UK, I couldn't recommend getting your ADSL from BT!
Regards
Griff
Keep [Smile]ing
If you're using the MS PPTP client, simply uncheck the box that says use default gateway on remote network.
If you have an IPSec solution you normally specify whether the client uses default gateway or not as part of the VPN policy that you configure.
There are security concerns and if you intend to enable this, you definitely want a personal firewall of some sort running on the cient.
If you have an IPSec solution you normally specify whether the client uses default gateway or not as part of the VPN policy that you configure.
There are security concerns and if you intend to enable this, you definitely want a personal firewall of some sort running on the cient.
- Thread starter
- #5
yes, it works, meaning I can get into the VPN and I can't get into my server system, AS400 I guess the router is blocking the split tunnel
Is the AS400 on the same subnet as the VPN server? If so, and you don't have your client use the remote default gateway, you'll need to add a static route to the AS400 via the remote gw.
It sounds as though you're using a Windows server and I think that MS RRAS basically shuts off the public i/f for anything but VPN. I fought with this for a little whilt and then switched to a Linux server to have access to both VPN and internet at the same time. The downside is that all internet traffic first comes into the VPN server and then back out the same T1, but it does offer administrative control over what gets to the remote workstation while it's on the VPN.
You may not have control over the server end, in which case you'll need to mess with your routing. Though inconvenient, it really is better for security to disallow simultaneous internet and vpn access to prevent your workstation from becoming an insecure entry point into your corporate net.
It sounds as though you're using a Windows server and I think that MS RRAS basically shuts off the public i/f for anything but VPN. I fought with this for a little whilt and then switched to a Linux server to have access to both VPN and internet at the same time. The downside is that all internet traffic first comes into the VPN server and then back out the same T1, but it does offer administrative control over what gets to the remote workstation while it's on the VPN.
You may not have control over the server end, in which case you'll need to mess with your routing. Though inconvenient, it really is better for security to disallow simultaneous internet and vpn access to prevent your workstation from becoming an insecure entry point into your corporate net.
Blocked GRE "MUST" Be most of our Problems. I have beat this thing to death, doing everything correctly, and still no connection. I get to the router fine. After that I get the dreaded 721 error. Can anyone add insight to this post?
Comcast has gone to Comcast Business "Broadband Commuter" Service, which has to be blocking the GRE (Port 47) protocol.
Comcast VPN
This is a copy of email from Comcast@Home customer support in response to a customer's inquiry about the new Comcast policy banning VPN use.
Thank you for your message.
The Comcast @Home product is, and has always been, designated as a residential service and does not allow the use of commercial applications. A VPN or Virtual Private Network is primarily used to connect Internet users to her or his work LAN from an Internet access point.
High traffic telecommuting while utilizing a VPN can adversely affect the condition of the network while disrupting the connection of our regular residential subscribers.
To accommodate the needs of our customers who do choose to operate VPN, Comcast offers the Comcast @Home Professional product. @Home Pro is designed to meet the needs of the ever growing population of small office/home office customers and telecommuters that need to take advantage of protocols such as VPN. This product will cost $95 per month, and afford you with standards which differ from the standard residential product.
If you're interested in upgrading your current Comcast @Home service to Comcast @Home Pro, please e-mail your name, address, and phone number to: sales@comcastpc.com. Prior to Sept 15th, you will be contacted by one of our Comcast @Home Pro representatives to discuss upgrading from your current Comcast @Home residential service.
While VPN is not a prohibited use of the @Home Pro product, Comcast does not provide support for VPN technology. All inquiries regarding VPN should be directed toward your company's network administrator.
Currently, the Comcast @Work commercial services do provide VPN support. If your company pays for your internet service, or if you would like to use supported VPN or IP tunneling, please contact our commercial services at 888-638-4338 or visit
If there is anything else we can help you with, please contact us. Thank you for choosing Comcast@Home.
Steve
Comcast@Home
Email Response Specialist
Comcast has gone to Comcast Business "Broadband Commuter" Service, which has to be blocking the GRE (Port 47) protocol.
Comcast VPN
This is a copy of email from Comcast@Home customer support in response to a customer's inquiry about the new Comcast policy banning VPN use.
Thank you for your message.
The Comcast @Home product is, and has always been, designated as a residential service and does not allow the use of commercial applications. A VPN or Virtual Private Network is primarily used to connect Internet users to her or his work LAN from an Internet access point.
High traffic telecommuting while utilizing a VPN can adversely affect the condition of the network while disrupting the connection of our regular residential subscribers.
To accommodate the needs of our customers who do choose to operate VPN, Comcast offers the Comcast @Home Professional product. @Home Pro is designed to meet the needs of the ever growing population of small office/home office customers and telecommuters that need to take advantage of protocols such as VPN. This product will cost $95 per month, and afford you with standards which differ from the standard residential product.
If you're interested in upgrading your current Comcast @Home service to Comcast @Home Pro, please e-mail your name, address, and phone number to: sales@comcastpc.com. Prior to Sept 15th, you will be contacted by one of our Comcast @Home Pro representatives to discuss upgrading from your current Comcast @Home residential service.
While VPN is not a prohibited use of the @Home Pro product, Comcast does not provide support for VPN technology. All inquiries regarding VPN should be directed toward your company's network administrator.
Currently, the Comcast @Work commercial services do provide VPN support. If your company pays for your internet service, or if you would like to use supported VPN or IP tunneling, please contact our commercial services at 888-638-4338 or visit
If there is anything else we can help you with, please contact us. Thank you for choosing Comcast@Home.
Steve
Comcast@Home
Email Response Specialist
-
1
- #8
John Lewis
Programmer
I don't think the router is blocking the split tunnel. I can't think of any way that it would know that you have a split tunnel.
What do you mean you can 'get into' the vpn? Do you mean simply that the network connection dialog says that you or connected, or that you are able to ping or otherwise access the vpn server? If you haven't gone beyond the point of making the vpn live and trying to access something on the other end, let's do some troubleshooting. If you have already taken these steps, please report your results.
A) Can you ping the other end of the tunnel? If you open the status box for the vpn connection and click on the details tab, there should be 2 ip addresses. (Again, I am assuming - this time that you are using the built in PPTP client) The client address is your end of the tunnel, and the server address is the other end. Open a command window and type 'ping' followed by a space and the server address. Don't panic if you see a 'request timed out' message in response, as the ports that are used for ping are often turned off. What we really don't want to see is 'no route to host', but that is real unlikely. If you have made the vpn connection, you should be fine to this point.
B) Now, the vpn server that you are connecting to should have at least one other ip address. The one that we are interested in is the address that is on the same subnet as the AS400 you are trying to get to. Again, open a command window and type 'ping' followed by a space and this other address for your server. Again, a 'request timed out' is not a big deal. If you see that, or a good reply, proceed to D. If you get the dreaded 'no route to host' . . .
C) So far it looks like your problem is with routing on your client machine. In a command window, type 'route print'. Look for a line that indicates a route to the remote network. Check the subnet mask, make sure that it is the same as the actual subnet. There must be a route there even if your vpn addresses lie in the same subnet as the remote network, as the pptp connection always uses a subnet mask of 255.255.255.255, so as far as the client is concerened, they are not really on the same subnet. Windows seems to take care of this sometimes, sometimes not. At any rate, if you don't see a good route, add one and start over.
D) Once you have established a good route from the client to the server, you need to establish the route back from the server to the client. Start over at the server and work back to the client. I have never touched an AS400, but ping is very similar in almost all modern os's. Again, a 'no route to host' is a problem indicator. The server should have a route to the vpn server/router, and often it is necessary to set up a route within the vpn server from the lan interface to the vpn interface. There are too many variables there to give much detail, but if you report back, include your client os, type of router/vpn server/firewall as well as the type of connections to the internet, and maybe someone can help.
What do you mean you can 'get into' the vpn? Do you mean simply that the network connection dialog says that you or connected, or that you are able to ping or otherwise access the vpn server? If you haven't gone beyond the point of making the vpn live and trying to access something on the other end, let's do some troubleshooting. If you have already taken these steps, please report your results.
A) Can you ping the other end of the tunnel? If you open the status box for the vpn connection and click on the details tab, there should be 2 ip addresses. (Again, I am assuming - this time that you are using the built in PPTP client) The client address is your end of the tunnel, and the server address is the other end. Open a command window and type 'ping' followed by a space and the server address. Don't panic if you see a 'request timed out' message in response, as the ports that are used for ping are often turned off. What we really don't want to see is 'no route to host', but that is real unlikely. If you have made the vpn connection, you should be fine to this point.
B) Now, the vpn server that you are connecting to should have at least one other ip address. The one that we are interested in is the address that is on the same subnet as the AS400 you are trying to get to. Again, open a command window and type 'ping' followed by a space and this other address for your server. Again, a 'request timed out' is not a big deal. If you see that, or a good reply, proceed to D. If you get the dreaded 'no route to host' . . .
C) So far it looks like your problem is with routing on your client machine. In a command window, type 'route print'. Look for a line that indicates a route to the remote network. Check the subnet mask, make sure that it is the same as the actual subnet. There must be a route there even if your vpn addresses lie in the same subnet as the remote network, as the pptp connection always uses a subnet mask of 255.255.255.255, so as far as the client is concerened, they are not really on the same subnet. Windows seems to take care of this sometimes, sometimes not. At any rate, if you don't see a good route, add one and start over.
D) Once you have established a good route from the client to the server, you need to establish the route back from the server to the client. Start over at the server and work back to the client. I have never touched an AS400, but ping is very similar in almost all modern os's. Again, a 'no route to host' is a problem indicator. The server should have a route to the vpn server/router, and often it is necessary to set up a route within the vpn server from the lan interface to the vpn interface. There are too many variables there to give much detail, but if you report back, include your client os, type of router/vpn server/firewall as well as the type of connections to the internet, and maybe someone can help.
I, too, am struggling with this issue. The question of the ISP blocking GRE Port 47 finally popped up from Watchguard. The ISP in question is AOL, and they confirmed that they do block the port. However , to muddy thge water further, this seems to be a European policy on the part of AOL, as my colleague in our US office is able to use VPN over AOL.
I am serching for a sympathetic ISP - preferably a free service. All suggestions welcome.
I am serching for a sympathetic ISP - preferably a free service. All suggestions welcome.
- Status
Similar threads
- Question