VPN Access through router

  • Thread starter Thread starter Graham Greenway
  • Start date Start date
G

Graham Greenway

I have static ADSL service and am currently connecting to
a cheap D-link Router to provide NAT conversion for my 25
internal clients. I am trying to set up VPN access to the
server, but keep getting stuck at verifying user name and
password.
I have forworded ports 1723 and 47 to the server. I have
One Windows 2000 server, currently using one NIC assigned
an address of 192.168.1.2. The Router uses 192.168.1.1.

It looks like my requests are reaching the server but
timing out. I have gone through every setting in Routing
and remote access. I have tried no encryption, no
authentication, setting up a RADIUS server, allowing
unrestricted access throught the remote accress policy.
And still I can not connect.

Everything I read seems to point to using 2 NICs in the
server. How would I set this up? Do I need 2 cards? Is my
cheap router causeing the problem? How secure would W2K be
if I connected on card directly to the modem>? and the
other to the internal network?> I have a few more public
IP addresses to use.

Any help would be great.
Thanks
Graham
 
The port 47 thing is an urban myth. It is widely believed (you will even
see it in documents from router manufacturers), but it has nothing to do
with VPN.

What is required is GRE, which is IP protocol 47. The encrypted data (ie
the tunnelled traffic) comes across the link as the payload of packets with
GRE headers. If the router blocks GRE, no VPN traffic.

On simple SOHO routers, allowing GRE is sometimes referred to as PPTP
pass-through mode or VPN pass-through mode.
 
Hi,

Bill is right on target here. You need to close TCP port 47 and allow IP
Protocol 47 (GRE).

Thanks,
Marc Reynolds
Microsoft Technical Support
 
Thanks for the tips,

I disabled port forwarding on port 47 and made sure PPTP
pass through was enabled on my router but still get stuck
at Verifying user name and password. Any other ideas>>??
Thanks
 
Hi Graham,

Getting stuck at verify username and password is a sign that GRE (IP
Protocol 47) is being blocked. You'll need to make sure your router is
passing GRE traffic.

Thanks,
Marc Reynolds
Microsoft Technical Support
 
-----Original Message-----
Hi Graham,

Getting stuck at verify username and password is a sign that GRE (IP
Protocol 47) is being blocked. You'll need to make sure your router is
passing GRE traffic.
Click to expand...

Add me to the list of people with this problem. The
router is a linksys befrs41. I have both pptp and l2tp
passthrough enabled, port forwarding for 1723 and 500, and
port triggering, per linksys kb instructions. This should
insure that GRE is not being blocked. Moreover, the
problem persists when I put the win2k vpn server in a
DMZ. So I cannot but assume that there is another problem
here besides GRE being blocked.

-Basil
 
"Moreover, the problem persists when I put the win2k vpn server in a DMZ.
So I cannot but assume that there is another problem here besides GRE being
blocked."

You cannot make that assumption since the VPN traffic still needs to go
through routers. It could be a server side router blocking GRE or a client
side router blocking GRE.

A better test would be to try to connect to your VPN server from another
client in the DMZ or even from the client session on the VPN server itself.


Thanks,
Marc Reynolds
Microsoft Technical Support
 
You cannot make that assumption since the VPN traffic still needs to go
through routers. It could be a server side router blocking GRE or a client
side router blocking GRE.
Click to expand...

Thanks for the reply. One "common denominator" that
I found in doing a general google search on "vpn error
721" is that a lot of the reports of the problems made
some attribution to ADSL. Is there any reason to believe
that the gateway routers used by telcos could be blocking
GRE on outgoing traffic? FWIW, my DSL service is not
PPPoE, but the older PPP DSL technology.

Do you know of any way I could test whether I can
send Port 47 traffic outbound from the LAN? I really
don't think the problem is with the passthrough inbound.
A better test would be to try to connect to your VPN server from another
client in the DMZ or even from the client session on the
Click to expand...
VPN server itself.

Well, there is no problem connecting from a client
session on the VPN server itself, nor from other clients
on the LAN. The problem is connecting from outside the
LAN, which is the whole idea of a vpn.
Thanks,
Click to expand...

And thanks to you.

-Basil
 
Back
Top