Debian server + PPTP VPN – connection not working

debianpptppptpdvpn

I set up a Seagate DockStar with Debian Squeeze as a litte server in my home network. I'd like to access it from outside my own network now, so I need a VPN connection. BTW, I don't have a router with an integrated VPN server.
I already have a "big" Windows XP server running which I can access via a PPTP VPN tunnel. That was pretty easy, but now with Debian, I have some problems setting up the VPN connection.

I installed pptpd via

apt-get install pptpd 

already. This is my pptpd.conf:

# TAG: ppp
#    Path to the pppd program, default '/usr/sbin/pppd' on Linux
#
#ppp /usr/sbin/pppd

# TAG: option
#    Specifies the location of the PPP options file.
#    By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#    Turns on (more) debugging to syslog
#
#debug

# TAG: stimeout
#    Specifies timeout (in seconds) on starting ctrl connection
#
# stimeout 10

# TAG: noipparam
#       Suppress the passing of the client's IP address to PPP, which is
#       done by default otherwise.
#
#noipparam

# TAG: logwtmp
#    Use wtmp(5) to record client connections and disconnections.
#
logwtmp

# TAG: bcrelay <if>
#    Turns on broadcast relay to clients from interface <if>
#
#bcrelay eth1

# TAG: localip
# TAG: remoteip
#    Specifies the local and remote IP address ranges.
#
#       Any addresses work as long as the local machine takes care of the
#       routing.  But if you want to use MS-Windows networking, you should
#       use IP addresses out of the LAN address space and use the proxyarp
#       option in the pppd options file, or run bcrelay.
#
#    You can specify single IP addresses seperated by commas or you can
#    specify ranges, or both. For example:
#
#        192.168.0.234,192.168.0.245-249,192.168.0.254
#
#    IMPORTANT RESTRICTIONS:
#
#    1. No spaces are permitted between commas or within addresses.
#
#    2. If you give more IP addresses than MAX_CONNECTIONS, it will
#       start at the beginning of the list and go until it gets 
#       MAX_CONNECTIONS IPs. Others will be ignored.
#
#    3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#       you must type 234-238 if you mean this.
#
#    4. If you give a single localIP, that's ok - all local IPs will
#       be set to the given one. You MUST still give at least one remote
#       IP for each simultaneous client.
#
# (Recommended)
localip 192.168.0.120
remoteip 192.168.0.121-129
# or
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245

My DHCP server in the router is distributing IPs beginning with 192.168.0.2. My big server distributed IPs beginning at 192.168.0.121 to VPN clients (the server itself had the x.x.x.120 TP) – as I already wrote, on the big server VPN works, so I've just set localip and the remoteip range to those from the big server.

My pptpd-options looks like this:

# Authentication

# Name of the local system for authentication purposes 
# (must match the second field in /etc/ppp/chap-secrets entries)
name pptpd

# Optional: domain name to use for authentication
# domain mydomain.net

# Strip the domain prefix from the username before authentication.
# (applies if you use pppd with chapms-strip-domain patch)
#chapms-strip-domain


# Encryption
# Debian: on systems with a kernel built with the package
# kernel-patch-mppe >= 2.4.2 and using ppp >= 2.4.2, ...
# {{{
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
#require-mppe-128
# }}}




# Network and Routing

# If pppd is acting as a server for Microsoft Windows clients, this
# option allows pppd to supply one or two DNS (Domain Name Server)
# addresses to the clients.  The first instance of this option
# specifies the primary DNS address; the second instance (if given)
# specifies the secondary DNS address.
# Attention! This information may not be taken into account by a Windows
# client. See KB311218 in Microsoft's knowledge base for more information.
#ms-dns 10.0.0.1
#ms-dns 10.0.0.2

# If pppd is acting as a server for Microsoft Windows or "Samba"
# clients, this option allows pppd to supply one or two WINS (Windows
# Internet Name Services) server addresses to the clients.  The first
# instance of this option specifies the primary WINS address; the
# second instance (if given) specifies the secondary WINS address.
#ms-wins 10.0.0.3
#ms-wins 10.0.0.4

# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.  This will have the effect of making the peer appear to other
# systems to be on the local ethernet.
# (you do not need this if your PPTP server is responsible for routing
# packets to the clients -- James Cameron)
proxyarp

# Debian: do not replace the default route
nodefaultroute


# Logging

# Enable connection debugging facilities.
# (see your syslog configuration for where pppd sends to)
#debug

# Print out all the option values which have been set.
# (often requested by mailing list to verify options)
#dump


# Miscellaneous

# Create a UUCP-style lock file for the pseudo-tty to ensure exclusive
# access.
lock

# Disable BSD-Compress compression
nobsdcomp 

ms-dns 192.168.0.1
netmask 255.255.255.0
noipx
mtu 1490
mru 1490

In the chap-secrets file I registered one user. (like the following: – is this right?)

netstat tells me that port 1723 is open and listened to by pptpd, as well as an nmap port scan from another computer does.
iptables isn't installed on the DockStar.
In my router, I'm forwarding every TCP or UDP connection to port 1723 to the DockStar's IP.

I tried connecting with a Windoows XP, a Windows 7 and a Mac OS X client. All are not able to establish a connection. Mac OS X does only show a general error message, the Windows clients show "Error 619 – A connection with the remote computer could not be established.". The clients are configured to use MSCHAPv2 with the username and password set in the chap-secrets file.

It doesn't matter if I try to connect to the server from my notebook in the same network or via my WWAN connection (while WiFi is turned off) – it doesn't work every time I try to connect.

Does anybody have an idea what's wrong with the server's configuration and knows how I can get it working?

Thanks in advance,

iYassin

Best Answer

It's not entirely clear to me how you got PPTP working to the Windows XP server when you have forwarded all port 1723 traffic to the Debian Squeeze server. You likely can only "VPN" to the WinXP server from within your local LAN, which seems to be of limited usefulness.

Regardless, PPTP requires not only TCP port 1723 traffic, but also GRE protocol. Is your router capable of handling GRE tunnels correctly? If it's an ordinary consumer-grade router, then I suspect not. And even if it is, GRE is esoteric enough that finding help may be difficult.

In your case I recommend trying a VPN solution that uses only TCP and/or UDP transports, since those protocols are ubiquitous and well-known. OpenVPN is one such VPN solution, and it is available for all the major OSes (Win, Mac, Linux, *BSD).

Depending on what you're trying to accomplish, another possibility is to run sshd on the Debian server, e.g.:

apt-get install openssh-server

All the major OSes have free ssh clients capable of creating tunnels over an ssh connection.