Wintivity

Connecting to a Windows Domain based network can be very advantageous for remote workers who “really do need” access to their company or branch office Local Area Network (LAN). LAN access is not always necessary but when it is needed, connecting the proverbial dots is the first step. Today’s article is a pro-active attempt to help Users troubleshoot VPN Connections when they are “initially attempting to connect” to a company LAN from their home environments.

Assuming that the Remote Access Server at the Corporate Office has been properly configured and the firewall is set to allow VPN traffic, the next step is connecting from a client maching (i.e. a Laptop or Workstation outside the office). To accomplish a connection, the firewall in the location at which the “remote User” resides is going to have to be configured.

Let’s look at a sample connection attempt as a lesson in how we configure the “User side” Firewall and why we make these adjustments:

Step 1 – launch the VPN Connection

Connect to a network VPN

Step 2 – enter credentials for the Domain

VPN User name Password Domain

Step 3 – attempting the connection

Connecting to VPN connection

Failure message – cannot connect

VPN cannot connect error

This CANNOT CONNECT error (specifically when the error occurs prior to ever reaching the point where Verifying the username and password takes place) commonly occurs because TCP Port 1723 has not been opened.

• IF: a connection cannot be made??
• THEN: Oconfigure the Firewall to pass PPTP traffic (TCP Port 1723)
• IF: it appears as though a connection is being made BUT!!! the Verifying your user name and password screen is never reached or shown
• THEN: PPTP traffic is generally not being passed  and you will need to configure the Firewall to pass PPTP traffic (TCP Port 1723)

Once a PPTP Point to Point Tranfer Protocol connection can be made, we can attempt the next step: Your VPN connection attempt must authenticate the User name and password of the user.

Let’s say that the first 3 steps above complete successfully.

1. Step 1 – launch the VPN Connection = SUCCESS
2. Step 2 – enter credentials for the Domain = SUCCESS
3. Step 3 – attempting the connection = SUCCESS

Connecting to vpn.ourcompany.com = OK

and you reach the Verifying user name and password screen BUT!!! the Verifying user name and password screen “DOES NOT AUTHENTICATE SUCCESSFULLY”

EXAMPLE: a PPTP connection can be made but the Verifying user name and password screen simply persists and runs on for a long period time without authenticating. In this circumstance, the Connecting to succeeds but Authentication HAS FAILED…

Verifying username and password to VPN Connection FAILS

If this occurs, Windows may offer this Error message (Vista example).

GRE error causes Username and Password fail to authenticate

this is a Generic Routing Encapsulation (GRE) Protocol 47 error

Let’s learn a little more about GRE and review.

A simple VPN connection requires two primary rules to be configured on a Home Office / Remote Office firewall

1. TCP Port 1723 (discussed above) must be allowed to pass traffic originating from Inside (permitting the PPTP Point To Point Protocol traffic used by the VPN) – this would take the form of an Outbound rule
2. GRE Protocol 47 must be allowed to pass traffic originating from the inside (permitting IPSec traffic relating to the PPTP VPN connection) – this would also take the form of an Outbound rule

… the 2nd requirement, (the GRE Protocol 47) Generic Routing Encapsulation is required to pass IPSec (Internet Protocol Security) traffic for the IPSec session that is part of making the overall VPN Connection. If the GRE protocol does not pass, the connection can’t “authenticate” even though a connection has been made. A GRE block results in the Username and Password authentication failing and the VPN connection simply timing-out.

To pass GRE Protocol 47 on your firewall may:

• enable the “VPN feature” (if one exists)
• enable “IPSec pass through” (if a simple IPSec pass through exists)
• you may have to expressly allow the GRE protocol.  GRE = Protocol 47)
• you may have to explicitly create an Outbound rule and then confirm that all requests made from the Internal network subsequently allow the returning traffic from outside to pass through to the Internal network once again (this causes the “State” on the internal side of the Firewall).
• NOTE: you may have to upgrade your Router’s Firmware or your Firewall’s Firmware to access these features
• NOTE: Some ISPs block VPN traffic intentionally (sometimes to sell a higher priced service that allows it). Most often though, configuring the Firewall properly is all that’s needed.

An explicit Outbound Rule (if you have to define one) would take on these objectives:

#PPTP Virtual Private Network
pass protocol tcp, to port 1723 >> state, done
pass protocol 47 >> done

Whatever the case, passing GRE Protocol 47 from inside>out is needed to allow IPSec traffic for your authentication. Here are some helpful links about GRE and passing Generic Routing Encapsulation traffic

• Troubleshooting remote access VPNs
• You receive an “Error 721″ error message when you try to establish a VPN connection through your Windows Server-based remote access server
• VPN Tunnels – GRE Protocol 47 Packet Description and Use

Try these articles and the above steps to find resolution to your VPN connection issues. Contact your administrator for additional help.

Thanks for reading. Please comment or link back to this article if it has helped you.
Mark Raborn
WIGITAL