VPN practical tips

Contents

Overview

This Howto gives practical examples regarding using VPN and making connections to remote servers and workstations.

Please refer to seperate Howtos for configuration of the VPN client on Windows 2000, XP and other workstations

http://www.domain-logic.com/support/secure_tunnel_w2k.htm

http://www.domain-logic.com/support/secure_tunnel_XP.htm

For basic troubleshooting refer to entries made in the log file /var/log/messages at the time the VPN connection was being established

For advanced troubleshooting techniques see http://pptpclient.sourceforge.net/howto-diagnosis.phtml

Background information

VPN uses TCP port 1723 and protocol 47 (GRE).

In server & gateway mode your modem should be configured in bridged mode and automatically forwards all traffic to the server.

In server only mode, your router must be configured to forward TCP port 1723 to your server and must provide full support for protocol 47. Note that protocol 47 (GRE) is not a port and therefore you cannot forward it. Not all routers support this protocol so VPN is not always possible in this network arrangement. In order to make pptp type VPN connections in this network arrangement, the router specification must clearly say that it can handle passthrough pptp VPN connections. Note that the routers at both the remote and local ends of the VPN pptp connection must be able to handle pptp VPN passthrough for this scenario to work correctly. Check your router specifications carefully. Errors in your log files may indicate that one of your routers may have a problem forwarding GRE packets. If you see LCP timeout errors in your log files, there are many possible reasons. The most likely one is that a firewall somewhere between the two ends is blocking/dropping GRE packets. Some routers/gateways automatically forward GRE when required, by watching the negotiation on TCP port 1723.


In any point to point VPN connection, there will be numerous pieces of equipment that the signal passes through eg corporate firewalls, additional routers/firewalls, software firewalls/filters etc. All these steps in the chain must support protocol 47, if any piece of equipment in the chain does not support that protocol then the VPN connection will be unsuccessful. Sometimes these matters are out of the end users control, especially in corporate situations, or home user situations where low end broadband connections are used and ISP's limit functionality.

If you have a modem and a router between your SME server and the Internet, keep in mind that you need to open TCP port 1723 on both devices, and they must both support the protocol 47 (GRE).


You cannot establish a VPN passthrough connection through an SME server to a local machine due to problems with the sme server supporting the passthrough of protocol 47 (GRE).


VPN connections to workstations will run very slowly. It is not advisable to run programs across VPN connections, even with fast broadband Internet speeds. This applies to scenarios where a VPN connection is established to a sme server, and then a connection is made to a workstation on the remote network.


Check that the VPN user(s) in server-manager User panel are allowed VPN access

Check that the "Number of pptp clients" in the "Remote access" panel in server manager, is set to more than zero

Check that the connection is set to "Negotiate multi-link connections" in the Windows VPN client setup

Check that the VPN connection/service is allowed access through a personal firewall on Windows workstations


Please read the sections of the SME server manual that relate to VPN

For further information please also search the forums and bugzilla for numerous reports of localised and other issues using VPN

Workaround for Appletalk issue

Important.png Note:
Support for Appletalk has been dropped from SME Server since version 8.0

Try this workaround to resolve issues with Kernel Panic errors, Appletalk and VPN disconnection problems

config setprop atalk status disabled
signal-event reboot

Refer to these bugs

http://bugs.contribs.org/show_bug.cgi?id=3500

http://bugs.contribs.org/show_bug.cgi?id=5167

Mapping Ip addresses

to map a user to a fixed ip address do

db accounts setprop username PPTPIP xxx.xxx.xxx.xxx
signal-event remoteaccess-update

where xxx.xxx.xxx.xxx is a local ip

Establishing connections & drive mapping

Important.png Note:
The following presupposes that if VPN'ing from behind another sme server, then the IP number and name of the local sme server & the remote sme server are different ie if the local sme server's local IP is 192.168.1.1 then the remote sme server's local IP must be 192.168.2.1 etc, if the local sme server's name is server1 then the remote sme server's name must be server2 etc.


After establishing a VPN connection with the sme server, users then need to connect to shares

to map a ibay do

net use N: \\serverIP\ibayname

or

net use N: \\servername\ibayname


to see all server shares do

\\serverIP

or

\\servername


to connect to a workstation C: or D: drive (that has been shared in Windows) do

\\workstationname

or

\\workstationIP

or

net use W: \\workstationIP\c

IPSec network to network VPN

For establishing a permanent VPN connection between networks see http://wiki.contribs.org/Ipsec


OpenVPN

OpenVPN is an alternative way to provide remote access to users from home or on the road, and completely replaces the PPTP VPN which is a part of the standard SME distribution. This method may suit users who experience connection reliability issues using the standard PPTP VPN.

See: http://wiki.contribs.org/OpenVPN

http://wiki.contribs.org/OpenVPN_Bridge

http://wiki.contribs.org/OpenVPN_SiteToSite

Also see: http://www.openvpn.net

Remote Desktop Protocol (RDP)

A good alternative to access workstations behind a SME server on a remote network, is Remote Desktop Protocol (RDP). It uses encrypted connections, is fast and flexible.

In use, forward a chosen port (say 2345), either in the port forwarding server manager panel (sme in server gateway mode) or in your router (sme in server only mode), to port 3389 on a workstation, which will allow direct RDP access to that workstation using a URL like http://yourdomain:2345

See

http://en.wikipedia.org/wiki/Remote_Desktop_Protocol

http://msdn2.microsoft.com/en-us/library/aa383015.aspx

http://support.microsoft.com/kb/186607

Reference links