2

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

iYassin
  • 121
  • 1
  • 1
  • 7
  • Do you have logs from the pptpd server? Does it show any signs of a connection? – DerfK Oct 13 '10 at 21:49
  • No, I can't find the log. On my Debian installation, I can't even find /var/log/messages. Do I have to activate the syslog after installation? – iYassin Oct 16 '10 at 07:33

2 Answers2

0

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.

Steven Monday
  • 13,019
  • 4
  • 35
  • 45
  • Previously, I forwarded the traffic coming in at port 1723 to the Windows XP server, but now, I changed the forwarding rule to the Debian server. My router is a Netgear DG834NBv2. I think it should be capable of handling a VPN tunnel correctly. Is this GRE protocol also used for a PPTP connection with a Windows server? Or only for a connection pptpd on Linux? If Windows also uses it, my router is definitely capable of handling GRE because PPTP is working with my Windows server. – iYassin Oct 14 '10 at 20:20
  • I already looked at OpenVPN, but for using that, I have to install some extra software on my PC if I understood that OpenVPN website correctly. Regarding that, I would prefer using PPTP as Windows supports it out of the box, but if I can't get PPTP working, I'll have to use OpenVPN. – iYassin Oct 14 '10 at 20:25
0

Well, I really had no logging service installed on my Debian installation. Now I installed rsyslog, so here is the log written to /var/log/syslog when I try to connect to the VPN server via PPTP with my Windows 7 computer:

Oct 17 20:05:57 debian pptpd[769]: MGR: Launching /usr/sbin/pptpctrl to handle client
Oct 17 20:05:57 debian pptpd[769]: CTRL: local address = 192.168.1.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: remote address = 192.168.2.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: pppd options file = /etc/ppp/pptpd-options
Oct 17 20:05:57 debian pptpd[769]: CTRL: Client 192.168.0.7 control connection started
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 1)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Made a START CTRL CONN RPLY packet
Oct 17 20:05:57 debian pptpd[769]: CTRL: I wrote 156 bytes to the client.
Oct 17 20:05:57 debian pptpd[769]: CTRL: Sent packet to client
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 7)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Oct 17 20:05:57 debian pptpd[769]: CTRL: Made a OUT CALL RPLY packet
Oct 17 20:05:57 debian pptpd[769]: CTRL: Starting call (launching pppd, opening GRE)
Oct 17 20:05:57 debian pptpd[769]: CTRL: pty_fd = 6
Oct 17 20:05:57 debian pptpd[769]: CTRL: tty_fd = 7
Oct 17 20:05:57 debian pptpd[769]: CTRL: I wrote 32 bytes to the client.
Oct 17 20:05:57 debian pptpd[769]: CTRL: Sent packet to client
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): local address = 192.168.1.1
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): remote address = 192.168.2.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 15)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Oct 17 20:05:57 debian pppd[771]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so is for pppd version 2.4.4, this is 2.4.5
Oct 17 20:05:57 debian pptpd[769]: GRE: read(fd=6,buffer=1fb40,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Oct 17 20:05:57 debian pptpd[769]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Reaping child PPP[771]
Oct 17 20:05:57 debian pptpd[769]: CTRL: Client 192.168.0.7 control connection finished
Oct 17 20:05:57 debian pptpd[769]: CTRL: Exiting now
Oct 17 20:05:57 debian pptpd[507]: MGR: Reaped child 769

Seems that something is wrong with GRE... but, as I already said, a PPTP connection to my Windows server is working (if I set the port forwarding in my router back to the Windows server). Do Windows servers use GRE for PPTP VPN connections? If they do, I think I can assume that my router has GRE support. Do I maybe have to setup GRE support on the Debian system?

iYassin
  • 121
  • 1
  • 1
  • 7
  • The GRE error is that pppd crashed, the pppd error right above it seems to be the real problem... try disabling the logwtmp line in the configuration, maybe that will prevent loading that invalid pptpd-logwtmp module. If these were all installed from Debian packages, I'd also submit that as a bug on pptpd not being built for the correct pppd version. – DerfK Oct 17 '10 at 19:33
  • Great! I can connect from my notebook in the same network now. Thank you really much! I'll quickly boot up my other notebook with WWAN and try if it's working from outside now, but I think it should work now. – iYassin Oct 17 '10 at 19:49
  • Okay, tried it now with my Windows 7 notebook. I can connect to the VPN, but I can't ping my router (IP 192.168.0.1), other computers in the network (192.168.0.x) or the Debian server itself (network IP 192.168.0.10, VPN IP 192.168.1.1). My computer itself has the VPN IP 192.168.2.1. Of course, I can't mount my Samba shares, too. Is this an issue with the IP ranges I entered for localip and remoteip in pptpd.conf (I posted the file in the first post)? Or did I configure something the wrong way on my notebook? – iYassin Oct 17 '10 at 20:42
  • When I connect from a Mac OS X computer, I can ping the Debian server (but no other PCs or the router), but I can't mount the Samba shares (it tells me that the password was wrong, but it actually isn't). Anyway, the communication issue seems to be related to Windows and the VPN because it's working on the Mac. The mentioned Samba password problem with OS X isn't important, I don't need to connect to the VPN from this computer - but I'd need to be able to communicate with the server and to mount the Samba shares from my Windows 7 notebook (mentioned in the comment above). – iYassin Oct 17 '10 at 20:45
  • Okay, I got it working now by changing "localip" to the 192.168.1.1 and "remoteip" to 192.168.1.2-10. Thanks a lot again! – iYassin Oct 17 '10 at 21:43