Link to home
Start Free TrialLog in
Avatar of PasoRon
PasoRonFlag for Afghanistan

asked on

Can't get RRAS VPN to work

I'm trying to set up a new VPN server using RRAS and I cannot get a client to connect.

Here's the environment:  Server 2003, two nics,  one on LAN and one on Internet.

Here's what I observe:  Client tries to connect,  but receives error 800.  Tunnel unable to be created...

Here's what I done so far to diagnose:

I've verified server is listening on port 1723,  RRAS server is active,  PPTP and L2TP ports are active in RRAS console.

I'm running network monitor and I can see the TCP packets from the client,  but the Server does not respond.  I've have observed other TCP traffic receive responses.

For security,  I've unchecked "Client for Microsoft Networks" and "File and Printer Sharing" on network adapter.  I did enable "Client for Microsoft Networks" to see if that made a difference and it did not.  

Any ideas would be helpful.

Ron
Avatar of pwindell
pwindell
Flag of United States of America image

MS Networks and Sharing have nothing to do with it.

Use only PPTP until you get it working.  Add L2TP after you know it works.

Clients must be able to get an IP Config from either an RRAS Static Address Pool or via DHCP.  Even if you use DHCP the Client still gets it from RRAS because RRAS "pre-fetches" the address from DHCP in blocks of 5 (or is it 10?,..whatever) and then gives them to clients as they connect.  The only way to get other specs (beyond just the IP) from DHCP is to add the DHCP Relay Agent to RRAS,...it is considered a "protocol" and is added by choosing to add a New Protocol.
Avatar of PasoRon

ASKER

Thanks,

Actually the problem turned out to be I had the LAN gateway configured on the LAN interface.  When I removed that connection are made without any problems.

Only problem now is getting DHCP relay agent to work correctly,  I think it's configured correctly,  but Gateway and subnet mask are not configured property on the Tunnel Network Interface.  Subnet mask is 255.255.255.255 and gateway is 0.0.0.0  

As I said, dhcp relay is configured,  rras has obtained taken 5 addresses from the dhcp server,  but the additional dhcp info isn't transferring.
Actually the problem turned out to be I had the LAN gateway configured on the LAN interface.  When I removed that connection are made without any problems.

The LAN Interface is supposed to have the LAN's Default Gateway.

but Gateway and subnet mask are not configured property on the Tunnel Network Interface.  Subnet mask is 255.255.255.255 and gateway is 0.0.0.0  

Those are supposed to be that way.  They don't come from DHCP,...they come from RRAS.   VPN is a Dialup Technology,...therefore the V-Interface is a Dialup Interface.  Dialup Interfaces always become the Default Route for the Machine once they go active (0.0.0.0).  The Mask-255.255.255.255 and the Route-0.0.0.0 combined together tells the machine that anything destined for any address that does not exactly match the received IP# of the V-Interface gets passed on to the currently established VPN Connection,...which is what it is supposed to do.
Avatar of PasoRon

ASKER

I do appreciate your feedback,  I've been researching everything I can find.

Let me be specific on the NIC configurations.  There are two NICs on the machine,  

I'm hiding the first 2 octals for security.

VPN:    IP 000.000.9.179 Mask 255.255.255.248 Gateway 000.000.9.177
LAN     IP 192.168.1.7  Mask 255.255.255.0  Gateway 192.168.1.1

I could never get the connection when I had the Gateway on the LAN,  with it removed I can connect without issue consistently,  but with no outside connection.   Some of my remote clients have to use the LAN gateway outside for smtp authentication reasons.  Every time I've put the LAN gateway in place I could not connect.  I made this change because I had read that the response was probably being returned on the LAN gateway and IP mismatch may be causing the non connection.  

I'm looking for ideas,  Thanks
VPN:    IP 000.000.9.179 Mask 255.255.255.248 Gateway 000.000.9.177
LAN     IP 192.168.1.7  Mask 255.255.255.0  Gateway 192.168.1.1


I can't troubleshoot fake IP#s.

I could never get the connection when I had the Gateway on the LAN,  with it removed I can connect without issue consistently,  but with no outside connection.

Then we have to troubleshoot why it isn't working.  But it is not a reason to "do it wrong" because it seemed to kinda-sorta work when you "do it wrong".  It has to be done correctly,...and then figure out what is really happening with whatever subsequent problem that comes up.

To get back to "normal".....

1. Setup the LAN Nic the way it is supposed to be.
2. Delete the VPN DUN completely on the Client Machine.
3. Recreate the VPN DUN on the Client Machine.  Choose the correct connection Protocol (PPTP or L2TP).  Leave everything else on the Default.   Leave all the TCP IP stuff on Automatic.

I'm leaving for the day, but will be back Monday,...However Experts-Exchange is not my "job", so I can't say I will be sitting here staring at the PC screen all day,...Monday is going to be a bit busy around here,...but I'll try to watch for your Posts.
Avatar of PasoRon

ASKER

Well,  first I'm not posting on an open forum my actual IP address.  I've put zeros for the first two octals.  That's the only change.  They are not pertinent to the problem.

I didn't just dream up removing the LAN Gateway,  That's the explicit configuration recommendation from Microsoft.  Their configuration Technote explicitly says to Not have a gateway on the LAN interface.

So here I am,  I can connect to the VPN without the LAN gateway,  but cannot access the internet though the gateway of my network.  I have verified that if I add the LAN gateway after connection to the server, I can access the internet without issue but cannot connect in that configuration.
I didn't just dream up removing the LAN Gateway,  That's the explicit configuration recommendation from Microsoft.  Their configuration Technote explicitly says to Not have a gateway on the LAN interface

I'd have to see that documented.  In all the years I've been doing this I have never heard of that.  I have VPNs "all over the place" and have never done that,...the local gateway is a requirement for my equipment.

Well I anyone else wants to jump in then jump in.  I'm not going to have a lot of time today to deal with it.
Avatar of PasoRon

ASKER

Here's the specific note:

Important
When you configure IPv4 for the intranet interface of the VPN server, do not configure the default gateway on the intranet connection. This will prevent default route conflicts with the default route pointing to the Internet.
http://technet.microsoft.com/en-us/library/dd469687(v=ws.10).aspx

I had also seen other references on other forums to remove the default gateway because on login connection the login response would go back to the client by the default gateway and the client would detect the IP missmatch and believe the server was being spoofed.

So I'm really confused on what to do!  If the default gateway in on the LAN connection the client cannot connect,  If I remove it clients connect without issue.  While connected I can modify the server adding the default gateway and the client can then have access to the internet.

Help Anyone!
Avatar of PasoRon

ASKER

Update for everyone.  I appear to have it working for now.  Based upon my research that the login problem is caused by the response being sent on the default gateway rather than the original internet interface, I changed the preference order of the interfaces to set the VPN Internet interface as the preference.  The client connected and also has internet access.

I'm sure I've read that the LAN interface is suppose to be the preference,  but it seems to be working now.

The next step will be to see what happens when I add a Server to Server connection over another interface.

Thanks everyone for your input.
ASKER CERTIFIED SOLUTION
Avatar of pwindell
pwindell
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial