Skip to content



About this Document

In this How To, we explain the basic principles of PPTP and how to deploy the AXS Guard PPTP server in your network. This document is intended for technical personnel and network administators.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

Basic PPTP Concepts


In this section, we explain the general concepts of Virtual Private Networking (VPN), in particular the Point to Point Tunneling Protocol (PPTP). Topics covered in the section include:

  • The key elements underpinning PPTP: authentication, tunneling and encryption.

  • The standard PPTP deployment: how a PPTP client interacts with a PPTP server.

Introduction to VPNs

A Virtual Private Network (VPN) is a network which uses a public (inherently insecure) network infrastructure, such as the Internet, to provide a private (secured) connection between hosts and network applications. A VPN also ensures the integrity of data as it traverses the Internet, through authentication, tunneling and encryption. In other words, a VPN allows roaming or remote users to securely connect to corporate LAN resources, such as shared folders, applications, databases or e-mail. Several VPN protocols are available, such as the PPTP protocol explained in this manual.

VPN Concept

About PPTP

Protocol Description

PPTP stands for Point to Point Tunneling Protocol and is an extension of the PPP protocol, defined per RFC 1171. PPTP allows organizations to use the Internet to securely transmit data across a VPN. It does this by embedding its own network protocol within the TCP/IP packets carried by the Internet, which is referred to as tunneling or encapsulation. PPTP in its barest form works by encapsulating packets inside PPP packets, which are in turn encapsulated in Generic Routing Encapsulation (GRE) packets. The GRE packets are sent over IP to the destination PPTP server and back again. The image below shows the structure of a PPTP network packet.


Key Elements of PPTP Security

The PPTP protocol provides the following key security elements:

  • Authentication: The VPN server verifies the VPN client’s identity and restricts VPN access to authorized users only (MS-CHAP and MS-CHAP v2). The VPN server may also provide audit and accounting capabilities to monitor who accessed which information and when.

  • Tunneling: A technology that enables one network to send its data via another network’s connections. Tunneling works by encapsulating a network protocol within packets carried by another network. Tunneling is also referred to as encapsulation and is achieved by the GRE and PPP protocol.

  • Encryption: To insure privacy, data transmission via the VPN over the Internet is rendered unreadable to unauthorized clients through encryption (MPPE).

  • Compression: The process of reducing the amount of information necessary to transmit data.


PPTP VPN servers use two authentication protocols:

  • PAP: The Password Authentication Protocol is a simple authentication protocol to authenticate a user with a Network Access Server. PAP sends user names and passwords over the network in cleartext and is therefore insecure.

  • CHAP: Stands for Challenge Handshake Authentication Protocol and functions as follows:


  1. The PPTP VPN server sends a challenge to the requesting client.

  2. The client uses this challenge and the password to calculate a response, which is sent to the server.

  3. The PPTP VPN server checks the provided response against its own calculation of the expected response. If the received response matches, the server acknowledges the authentication; if not, the connection is terminated.


  • PAP is not supported by the AXS Guard because it is insecure. Only MS-CHAP is supported.
  • Able recommends 2FA, as this is the most secure option.


A VPN uses an IP tunneling mechanism where the packet formats and the addressing used by the VPN might be unrelated to the packet formats and addressing which is used to route the tunneled packet across the Internet.

For this reason, PPTP uses the Generic Routing Encapsulation (GRE) protocol. The GRE protocol is defined per RFC-1701, 1702 and 2784 and is identified as IP Protocol 47. GRE is used to implement several categories of encryption and network security. In its most basic form, GRE allows any network-layer protocol (or in some cases, protocols from other layers, e.g. Ethernet frames) to be encapsulated in any other network-layer protocol. In its current form, GRE has been implemented in most UNIX network stacks, routers and other network equipment and is widely supported.


PPTP supports PPP-based data encryption mechanisms. The Microsoft implementation of PPTP supports optional use of Microsoft Point-to-Point Encryption (MPPE), based on the RSA/RC4 algorithm. 40 bit encryption is supported, but highly insecure. AXS Guard enforces 128 bit encryption by default, as this is the most secure option.


Compression reduces the amount of information necessary to transmit data, hereby saving bandwidth and increasing the data transfer speed. PPTP uses the Compression Control Protocol (CCP) used by the PPP protocol. PPP negotiates MPPE with the AXS Guard PPTP server using CCP.

Standard PPTP Deployment

Two hosts are involved in the deployment of PPTP:

  • A PPTP Client with access to the Internet.

  • A PPTP Server, such as the AXS Guard PPTP server.

A PPTP connection between the client and the server consists of two channels, a control channel and a data channel. These are explained below.

PPTP Control Channel

The PPTP control channel is the initial channel which is negotiated between a PPTP client on the Internet and the AXS Guard PPTP server. A TCP connection is therefore made to the PPTP server on TCP port 1723, as shown in the illustration below. This control channel is used to negotiate tunnel parameters, such as the encryption method and the compression algorithm. The PPTP control channel also establishes, manages, and releases the PPTP data channel.

PPTP Data Channel

Once the PPTP control channel is up, a second channel is negotiated to secure the data transfer within the tunnel. This is the PPTP data channel. On this data channel, PPTP uses the GRE protocol to encapsulate the PPP packets for secure delivery to the AXS Guard PPTP server. In turn, the AXS Guard PPTP server verifies and decapsulates these packets before delivery to the destination host in the LAN.

PPTP Control and Data Channel

Routing Scenarios


Once the PPTP VPN is up, a PPP interface with its own IP address is assigned to both the client and the PPTP server. The client’s interface settings can be viewed by running the ipconfig command from a Windows command prompt as shown below.

Listing the PPP Device with ipconfig

On the client side, all network traffic not destined for the local network is routed through the PPP interface, until the PPTP connection is terminated. This means that a strict Firewall Policy should be enforced on the PPTP client and server.

On the server side, only PPTP traffic is routed through this interface. Different routing scenarios apply, depending on the network address which is assigned to the client’s PPP interface. These are explained in the following sections.

Source and Destination Address in Different IP Ranges

The client’s PPP interface has an IP address in a different IP range than the LAN of the PPTP server, as shown in the image below. Standard routing applies.

PPTP Client and PPTP Server with different IP ranges

The PPTP client with IP sends a request to a server in the AXS Guard LAN. This server has IP The server receives the request and replies using the client’s IP address as its destination. Since this IP address ( is in a different range than the AXS Guard LAN, the packet is automatically routed through the PPP interface (gateway) of the AXS Guard.

Source and Destination address in the Same IP Range

The client’s PPP interface has an IP address in the same IP range as the LAN IP of the PPTP server, as shown in the image below. Traffic can only be routed correctly using Proxy ARP, which is explained below.

PPTP Client and PPTP Server in same IP Range

The PPTP client with IP sends a request to a server in the AXS Guard LAN. This server has IP The server replies using the client’s IP address as its destination. Since this address is within the same IP range as the AXS Guard LAN, the contacted server "thinks" it can reply directly via the LAN using ARP. This is not the case, since the reply needs be routed back to the originating client and not the LAN. The AXS Guard solves this problem by using Proxy ARP, as explained below.


Proxy ARP is a technique in which a host, usually a router, answers ARP requests intended for another host by supplying its own physical address. By "pretending" to be another host, the AXS Guard correctly routes the traffic back to the requesting host. Proxy ARP is defined per RFC 1027. For more information about ARP, see the appropriate online resources.

Firewalls and PPTP

It is highly recommended to configure the AXS Guard Firewall so that only required network resources can be accessed by the client. This also improves security in case a client’s computer is hijacked (illustrated below).

The default system-wide Firewall Policies on the AXS Guard provide the appropriate security for PPTP VPN access. However, system administrators can and should implement the strictest PPTP Firewall Security at the group or user level.


Avoid the use of the no-restrictions and int-no-restrictions Firewall Policies at all times, except for testing or troubleshooting purposes in non-production environments.

Consequences of Compromised Client

  1. A hacker on the Internet scans public IP addresses for open services and vulnerabilities.

  2. The hacker hijacks the client which has a public IP address.

  3. The hacker can execute any attack posing as the hijacked computer and can access the resources of the corporate LAN through the hijacked computer’s PPTP connection.


  • Create strict, separate AXS Guard Firewall Policies for PPTP VPN access on a user / group basis in agreement with your company policies, as explained above.

  • Use a strong hardware or software Firewall on the client side. Ensure that outgoing traffic to TCP port 1723 and the GRE protocol are allowed, otherwise the client will not be able to connect to the PPTP server.

PPTP Server Configuration

Configuration Overview

  1. Activating the PPTP server feature under System > Feature Activation > VPN.

  2. Configure the PPTP server settings under VPN > PPTP.

  3. Configure the PPTP authentication policy under Authentication > Services, e.g. DIGIPASS authentication.

  4. Configure PPTP access for users and groups.

  5. Configure your PPTP client(s).

Feature Activation

  1. Log on to the AXS Guard appliance.

  2. Navigate to System > Feature Activation > VPN.

  3. Check the Do you use the AXS Guard PPTP Server? option and update your configuration.

    PPTP Feature Activation

PPTP Server Settings

  1. Navigate to VPN > PPTP > Server.

  2. Configure the settings as explained in the tables below.

  3. Update your configuration.

    PPTP General Configuration Settings

DHCP Configuration

Field Description

First IP in Range

The first IP address of the DHCP address range.

Last IP in Range

The last IP address of the DHCP address range.

DNS IP Address

The DNS server(s) to be used by PPTP clients. This is usually the LAN IP address of the AXS Guard or the IP address of your primary Domain Controller.

WINS IP Address

The WINS server(s) to be used by PPTP clients. This is a required parameter when using Directory Services password authentication. The AXS Guard itself is not a WINS server. The WINS server is usually the primary Domain Controller in your windows domain.

Network Settings

Field Description

Accept Client IP Configuration

Check this option to accept the IP address proposed by the PPTP client. Sometimes clients need a specific IP to be able to use certain applications in your network. Accepting a remote client IP also allows a PPTP client to print documents via an RDP Session if the drivers for printer sharing are installed on the client.

Connection Limit

Maximum number of allowed concurrent connections. 100 is the system default configuration.

Inactivity Settings

Option Description

Idle Timeout

PPTP will terminate the connection after a period of inactivity. The link is considered idle when no data is sent or received. The default value is set to 0 seconds, which means the option is disabled. Broadcast and multicast traffic are not considered as user activity.

Authentication Settings

Username Restrictions

Format Description and Examples When to use

User account name

Also known as the logon name, e.g. UserName, Bob, Alice, JonDoe.

This format must be used for authentication when the AXS Guard system domain matches the domain of the directory server of which the user is also a member or if the AXS Guard appliance is not synchronized with a directory server.

User Principal Name (UPN)

The UPN format is used to specify an Internet-style name, such as

This format must be used for authentication when the AXS Guard system domain does not match the domain of the directory server of which the user is a member.


The UPN format cannot be used to authenticate for PPTP and AXS Guard services for which Kerberos authentication has been enforced.

We highly recommend 2FA for PPTP access. This is the most secure option. You can also combine authentication methods.

Supported Authentication Methods

AXS Guard Service

Authentication Policy


  • OATH


  • DirectoryService


  • Password

  • Password and DIGIPASS

  • Password and OATH

  • DIGIPASS or Password

  • DirectoryService or Password

  • RADIUS or Password

  • OATH or Password

  • DIGIPASS or DirectoryService



  • OATH or DirectoryService


  • (Password and OATH) or DIGIPASS

  • (Password and OATH) or (Password and DIGIPASS)


  • A WINS server is required for AD back-end authentication, because the AXS Guard appliance must be able to resolve the domain/workgroup name to the IP address of the AD Server.
  • AD Authentication is only possible if the Directory Services module is activated and configured. For more information, see the AXS Guard Directory Services How To, which is available via the Documentation button in the Administrator Tool.

Configuring the Authentication Method

  1. Navigate to Authentication > Services.

  2. Select the PPTP VPN service.

  3. Select the desired Authentication Policy, e.g. DIGIPASS.

  4. Update your configuration.



For additional information about authentication methods, rules and policies, see the AXS Guard Authentication How To, which is accessible via the on-screen Documentation button in the Administrator Tool.

Granting Access to PPTP

Group-level Access

  1. Navigate to Users & Groups > Groups

  2. Select the appropriate group

  3. Select the VPN tab

  4. Check the appropriate VPN option

  5. Click on update to save your settings


User-level Access

The following VPN settings can be edited at the user level:

  • Authorization or denial to use the VPN service.

  • The password used to authenticate with the VPN server.

  • The user’s VPN Firewall settings.

To adjust a user’s VPN settings:

  1. Navigate to Users & Groups > Users.

  2. Select the appropriate user name.

  3. Select the VPN tab.

  4. If PPTP is enabled in the user’s group, select use group configuration. If not, set the option to on to overrule the group settings.

  5. Click on update when finished.

    User Settings

PPTP Firewall and Application Control Policies


Always use the strictest Firewall settings for PPTP. Do not use the AXS Guard no-restrictions and the int-no-restrictions Firewall Policies as these seriously jeopardize your network security. These policies should be used for testing or troubleshooting only and in a network that is shielded from the Internet.

Firewall Rights determine which services, ports and hosts a user can or cannot access. It is therefore critical to implement the strictest Firewall Policies on the AXS Guard, to prevent damage in case the client’s computer is compromized. Network traffic should be restricted to the resources that are needed by the PPTP client, as illustrated below. The Firewall settings for the AXS Guard PPTP service are configured in two stages:

  • Allow PPTP traffic (and enforce Strong Authentication, e.g. DIGIPASS).

  • Implement strict PPTP VPN Firewall Rules and restrict access to the needed resources.

Firewall Configuration

Allowing PPTP Traffic

PPTP traffic must be allowed on the AXS Guard for clients to successfully connect to the PPTP service. The int-pptp-1 and int-pptp-2 rules are automatically added to the stat-int (system-wide) Firewall Policy when the PPTP service is activated via System > Feature Activation > VPN. The Firewall rules int-pptp-1 and int-pptp-2 open TCP port 1723 and allow GRE traffic (IP protocol ID 47), which are required for PPTP access.

PPTP Firewall Policies

System-Wide Firewall Rights:

System-Wide Firewall Rights apply to all users in the AXS Guard network. Since connected PPTP VPN users are considered a part of the secure network zone, it is of utmost importance to restrict the System-Wide Firewall Rights as much as possible. The default AXS Guard System-Wide Firewall Policies (stat-sec and stat-z-fix) provide appropriate security for PPTP VPN access. However, you can overrule these default Policies simply by creating custom Firewall Policies which deny the default traffic. The created Firewall Policies should then be added to the Group’s or User’s VPN & RAS Firewall settings (explained further). This solution allows you to:

  • Maintain any changes you have made to System-Wide Firewall Policies.

  • To implement even stricter Firewall Policies than the system default policies.

A list of AXS Guard Firewall Rules that are active by default is available in the Firewall How To. This document can be accessed via the on-screen Documentation button in the Administrator Tool. You can also click on a Firewall Rule / Policy to view its contents.

User and Group Firewall Policies

Able highly recommends the use of a strong client-side firewall and the creation of dedicated firewall policies for access to network resources that are available through the VPN connection. A predefined firewall policy, fwd-access-lan, is available for convenience. This policy allows any type of traffic towards the AXS Guard secure LAN when a VPN connection is established.

About Application Control

The application control system monitors the application layer (layer 7 of the OSI model) of the network. This is also known to as Deep Packet Inspection (DPI), a form of computer network packet filtering that examines the data part of a packet as it passes the AXS Guard, searching for defined criteria, such as protocols or websites, to decide whether the packet may pass or needs to be blocked. The AXS Guard also collects and reports statistical information about all layer 7 traffic.

The application control system allows application-layer detection of protocols, regardless of the port being used. This means that it is possible to both detect known protocols on non-standard ports, e.g. http traffic on ports other than 80, and also the opposite, e.g. detect Skype traffic on port 80. The system will also detect and block access to certain file types, such as multimedia files (if enabled).


Group-level Configuration
  1. Navigate to Users & Groups > Groups.

  2. Click on the appropriate group name.

  3. Select the VPN tab to specify the VPN firewall and application control policies.

  4. Update your configuration.

    L2TP Group Level Firewall Configuration



Add Firewall Policy

Select specific firewall policies for group members who connect to the corporate network with a VPN client, such as a PPTP client. Go to Firewall > Policies > Dynamic for an overview of defined firewall policies.

Option Description

Use computer/system application control policies

Enforce the system-wide policies, assigned under Application Control > General and the computer-level policies, if any.

Add to computer/system application control policies

Assign specific policies to this group, in addition to the system-wide policies configured under Application Control > General and computer-level policies, if any.

Overrule computer/system application control policies

Do not enforce the system-wide policies and computer-level policies, but only the specified policies. The specific policies will be enforced when a member of the group successfully authenticates.

User-level Configuration
  1. Navigate to Users & Groups > Users.

  2. Click on the appropriate username.

  3. Select the VPN tab and select the appropriate firewall and application control policy modes as explained below.

  4. Update your configuration.

    User Level Firewall Configuration

Option Description

Use Group Firewall Policies

Select this option if you wish to apply the same firewall policies for VPN use as defined in the user’s group.

Add to Group Firewall Policies

Select this option to add specific policies for VPN use, in addition to the user’s group firewall policies.

Overrule Groups Firewall Policies

Select this option to overrule the group firewall configuration and specify unique policies for the user.

Option Description

Use group application control policies

Only enforce the policies as configured for the user’s group.

Add to group application control policies

Enforce the policies as configured for the user’s group and the policies that are specified in the user profile.

Overrule group application control policies

Only policies configured at the user, computer and system levels are enforced. Group policies are not enforced.

Overrule Group / Computer / System Application Control Policies

Only the application control policies configured at the user level are enforced.

PPTP Firewall Configuration Example

Assume you only wish to grant access to 2 specific servers in the LAN for a PPTP VPN user. Access to any other servers in the LAN is not allowed.

This requires you to create two new through Firewall Rules on the AXS Guard, allowing traffic to the specific servers. An additional Firewall Rule dropping all traffic must be created afterwards.

The new Firewall Rules must then be added to a Firewall Policy, which in turn must be assigned to the VPN & RAS Firewall settings of the PPTP user.

Create the Firewall Rules for allowed traffic

  1. Navigate to Firewall > Rules > Through.

  2. Search for the fwd-access-lan Rule and click to view its contents.

  3. Click on the Edit as New button.

  4. Provide a name and description for the new Rule.

  5. Check the enabled option.

  6. Do not specify a Source IP.

  7. Specify the Destination IP of the server which can be accessed, e.g.

  8. Select Allow as the target.

  9. Decide whether you want to log traffic by checking / unchecking the Log this rule target? option.

  10. Save the Rule.

  11. Repeat the same steps for the second server, e.g.

Create the Firewall Rules for traffic that must be dropped

  1. Repeat steps 1 to 6 as explained above.

  2. Do not specify a Destination IP.

  3. Select Drop as the target.

  4. Repeat steps 9 and 10 as explained above.

Add the Firewall Rules to a Firewall Policy

  1. Navigate to Firewall > Policies > Dynamic.

  2. Click on the Add New button.

  3. Enter a name and a description for the Firewall Policy.

  4. Check the enabled option.

  5. Add the Firewall Rules created above (Add the "allow" Rules first, followed by the "drop" Rule).

  6. Save the Firewall Policy.

Add the Firewall Policy to the VPN Group Settings of the user

  1. Add the new Firewall Policy to the user’s VPN Group Policy, add it separately or overrule the user’s VPN Firewall policy (see above). Ensure that this Firewall Policy is the only one in the list.

  2. Update your settings.

As a result, only network traffic towards the specific servers (e.g. and is allowed, since this Firewall Policy is listed first in the Firewall chain. Any other traffic is dropped.


  1. Navigate to VPN > Logs > PPTP.

  2. Click on the appropriate log file.



Search filters help you to locate specific information.

Overview of information recorded in the logs:

  • When a connection was initiated / terminated

  • The public IP address of the remote client

  • The PPP IP address used by the remote client

  • The authentication information

  • Information about encryption

  • The type of compression

  • Useful error messages for troubleshooting

Client Configuration Examples


In this chapter, we explain how to configure your PPTP client in:

  • Windows 7

  • Windows 8

Client-Side Firewall Settings

Able recommends the use of a strong client-side Firewall. Ensure that PPTP VPN pass-through is allowed on the client Firewall, otherwise you will not be able to connect to the AXS Guard PPTP server. Refer to your Firewall’s documentation if necessary.

Client-Side Authentication Settings

The AXS Guard does not support PAP, because it is insecure. Use MS-CHAP instead.

  1. Open the PPTP connection’s properties

  2. Select the Security tab

  3. Enable MS-CHAP v2


Windows 7

  1. Click on the Start button and navigate to the Control Panel.


  2. In the Control Panel, select Network and Internet.


  3. Select Network and Sharing Center.


  4. Click on Set up a new connection or network.


  5. Select Connect to a Workplace and click on Next.


  6. Select the first option (create a new connection) as shown below and click on Next.


  7. Click on Use my Internet connection.


  8. Enter the external IP address or FQDN of the AXS Guard PPTP server you are connecting to (e.g. or and enter a name for the connection (e.g. office).

  9. Leave the other options open and click on Next.


  10. Enter the user name and password provided by your system administrator to connect to the remote AXS Guard PPTP server.

  11. Enter the domain you are connecting to (optional).


    The UPN username format to specify an Internet-style name, such as`, is not supported by the AXS Guard PPTP server.


  12. Click on Connect. You should be connected after a few seconds, depending on the speed of your Internet connection.

You can verify the status of the VPN connection by clicking on the Network Icon in the lower right corner of your Windows desktop (see the image below).


Windows 8

  1. Log in to Windows 8 as a regular user.

  2. Move your mouse pointer to the top-right corner of your screen to access the Windows 8 toolbar.

  3. Select Settings and go the Windows Control Panel.

    Windows 8 Toolbar

  4. Open the Network and Sharing Center. Then choose Set up a new connection or network.

    Setting up a new Connection

  5. In the next window, select Connect to a workplace and click Next.

    Connect to a Workplace

  6. In the next window, select Use my Internet Connection (VPN).

    Select Connection

  7. Enter the public FQDN or IP address of the AXS Guard PPTP server you want to connect to.

  8. Then enter a name in the Destination name box (you can name it as you want) and click Create.

    Creating the Connection

  9. Click on the monitor icon on the bottom right-hand corner.

  10. Right–click on the created PPTP connection, and select Properties from the menu.

    Connection Properties

  11. Select the Security Tab and set "Point to Point Tunneling Protocol (PPTP)" as the VPN type. Click OK to finish.

    Selecting the VPN Type

Testing your VPN Connection

  1. Click on the monitor icon on the bottom right-hand corner of your screen.

  2. Find your (PPTP) connection and click connect.

  3. Enter your VPN username and password and click OK.


    The UPN username format to specify an Internet-style name, such as`, is not supported by the AXS Guard PPTP server.

    Testing your Connection


Client-side Troubleshooting

The client is connected to the PPTP VPN, but cannot access any resources.

  1. Check the VPN Firewall rights of the user and adjust them if necessary.

  2. Check the IP address of the client’s PPP device. If the client’s PPP device’s IP address is within the same range as its Ethernet IP address, the problem is ARP-related.

Modify the IP address range of the client accordingly. Refer to the documentation of the Operating System if necessary.

PPTP error: "Your credentials have failed remote network authentication".

  1. Your username or password may be incorrect. Contact your system administrator.

  2. Check if the connecting PC is in a Windows domain. If this is the case, check the properties of your VPN connection and ensure that the Include Windows logon domain option is unchecked (see image below).


PPTP Error 734: The PPP link control protocol was terminated.

You probably are using incompatible encryption or authentication settings. Make sure MS-CHAP is enabled.

PPTP Error 741: The local computer does not support the required data encryption type.

See error 734 above.

PPTP Error 769: The specified destination is not reachable.

The hostname or IP address of the machine you are connecting to is incorrect. Check your settings and/or contact your system adminstrator if necessary.

PPTP Error 678: There was no answer.

See error 769 above.

PPTP Error 619: the specified port is not connected.

If you see the following message:


  1. The client sits behind a firewall which is blocking PPTP / GRE traffic. The firewall should be configured to allow this traffic. Refer to your router / firewall documentation if necessary.

  2. Verify the user’s PPTP settings on the AXS Guard appliance.

  3. Another error ocurred while setting up the connection, restart Windows and try again.

  4. Your Internet Service provider or in-between networks are blocking GRE packets.

I cannot log in.

The UPN username format to specify an Internet-style name, such as, is not supported by the AXS Guard PPTP server.

I cannot log on with my Active Directory Password (Directory Services Password).

  • On AXS Guard, verify if the correct Authentication Policy has been assigned under Authentication > Services.

  • Verify if the user exists on your Active Directory Server. If the user exists, make sure the AD user account isn’t locked. If the user is not present or locked, authentication fails.

  • A WINS server is required. The AXS Guard needs to be able to resolve the domain/workgroup to the AD IP address. The GlobalNames zones (WINS successor) should work as well. WINS is slowly getting phased out by Microsoft being and being replaced by "GlobalNames zones". On MS server 2008, WINS is no longer a role but has become a "feature". The WINS configuration itself is exactly the same as on MS server 2003. For more information about setting up a WINS server, consult your Microsoft documentation. Information can also be found on this MS Technet link:

  • Verify if the DS username with DS tree search permissions has the appropriate privileges on the AD server. See the section "Specifying a Directory Base" in the AXS Guard Directory Services How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool. Only search (read) permissions are required, but you may try to escalate the privileges as a last resort. Consult your Microsoft documentation if necessary.

Server-side Troubleshooting

PPTP log Error

read(fd=5,buffer=804d580,len=8196) from PTY failed: status = -1 error = Input/output error

The client is most probably getting PPTP error 619 as mentioned above. GRE packets are being prevented from reaching the AXS Guard.

  1. Log on to the AXS Guard Administrator Tool as explained in the Command Line Interface How To.

  2. Use the tcpdump command on the Internet device.

PPTP log Error

GRE: read(fd=7,buffer=8056b60,len=8260) from network failed: status = -1 error = Protocol not available

  1. Client firewall: Make sure your client Firewall is not blocking outbound network traffic for port 1723 and IP protocol 47. Many consumer grade routers have PPTP pass-through disabled by default. Make sure this option is enabled.

  2. Server firewall: Make sure the AXS Guard PPTP server can receive a connection on port 1723 and that protocol 47 is being allowed.


Protocol 47 is not the same as port 47. This is a simple but common problem. Do not get port 47 confused with protocol 47. Opening port 47 on your firewall is not the same as allowing protocol 47 or GRE.

The PPTP service cannot be started

If pppd (the PPTP service) does not have any users configured, it will not start. The result is a session that ends prematurely with an error on the user side which indicates that the server has closed the connection.

PPTP VPN Client issues with Windows 7 x64 - Spurious ICMP Protocol Unreachable messages sent to server causing disconnection.

Drop the ICMP GRE message as explained in PPTP Server Settings. The following firewall rule will automatically be activated:

    DROP       icmp --              u32 "0x0>>0x16&0x3c@0xe&0xff=0x2f" mark match 0x20000000/0xf0000000 icmptype 3 code 2


If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

  1. Check the troubleshooting section of the feature-specific manual.

  2. Check the knowledge base on this site for information about special configurations.

  3. If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400