To test VPN Masquerade:
RASMON if it is available, as this will give you a minimal amount
of information about the status of the connection. If you establish a
PPTP connection on the first try, congratulations! You're done!
There are several things that may prevent a VPN session from being established. We'll work through them going from the client to the server and back again. We will assume you're using a Windows-based client for the examples, as that's the most common case.
NDISWAN.SYS or W'95/'98 PPTP software, you will not be able
to establish a strongly-encrypted session. Unfortunately in my experience
this problem does not generate any obvious error messages, it just keeps
trying and trying and trying... The strong encryption update can be
obtained from the Microsoft secure site URL given in the "Configuring
a MS Client" section.
This may also affect IPsec clients, if they use the MS-supplied encryption libraries rather than using their own libraries.
route print command and look
for an 0.0.0.0 entry.
If other masqueraded services (such as HTTP, FTP, IRC, etc.) work from your VPN client system then this probably is not the problem.
For IPsec, the authentication and key exchange service (ISAKMP), which is a normal UDP session to port 500 on the remote IPsec host, must be configured for masquerading as you would any other UDP service (such as DNS).
For PPTP, the control channel, which is a normal TCP session to port 1723 on the PPTP server, must be configured for masquerading as you would any other TCP service (such as HTTP).
The encrypted data channel in IPsec is carried over ESP, IP protocol 50.
The encrypted data channel in PPTP is carried over GRE, IP protocol 47.
(Note that these are not TCP or UDP port numbers!)
Since the 2.0 Linux kernel only lets you specify TCP,
UDP, ICMP and ALL IP protocols when creating
masquerade rules, you must also masquerade ALL protocol traffic if
you are masquerading only specific services. If you are masquerading
everything, you don't need to worry about this.
In order to isolate the firewall rules from the kernel masquerade code, try establishing a VPN connection with your firewall completely open, then if it works, tighten the firewall rules.
2.0.x ipfwadm completely open firewall:
ipfwadm -I -p accept ipfwadm -O -p accept ipfwadm -F -a accept -m
2.2.x ipchains completely open firewall:
ipchains -P input ACCEPT ipchains -P output ACCEPT ipchains -P forward MASQ
Do not leave your firewall completely open for any longer than it takes to prove that a masqueraded VPN connection can be established!
To isolate whether an intermediary hop is blocking GRE traffic, use a
patched traceroute to trace the progress of GRE packets. See the
resources section for information on the traceroute patch. A similar patch
for ESP is in the works.
Look in /var/log/messages for log entries showing that VPN
traffic was seen. Turning on VPN debugging may help you to determine
whether or not the patch is at fault. Also run a sniffer on your internet
connection and look for outbound VPN traffic (see below).
Most problems can be localized by running a packet sniffer
(e.g. tcpdump with the -v option) on your VPN firewall.
If everything is working properly, you'll see the following traffic:
IPsec: UDP (destination UDP port 500) and ESP (IP protocol 50) traffic from your IPsec client local network IP to the remote IPsec host's Internet IP. If you don't see this, your IPsec client is misconfigured.
PPTP: TCP (destination TCP port 1723) and GRE (IP protocol 47) traffic from your PPTP client local network IP to the PPTP server's Internet IP. If you don't see this, your PPTP client is misconfigured.
:) or some intermediary is blocking ESP
or GRE traffic.
ipportfw and ipfwd if you're masquerading the server.
You may find it helpful to turn on VPN debugging and recompile your
kernel. Add the following to /etc/syslog.conf
and watch# debugging *.=debug /var/log/debug
/var/log/messages and /var/log/debug for log
messages about the VPN traffic. Note that logging - especially verbose
logging - will cause a great deal of disk activity and will cause the log
files to grow very large very quickly. Don't turn on debugging unless you
need to, and turn it off when you're done.
Thanks to Charles Curley <ccurley@trib.com> for the following:
If you use PPTP (Point to Point Tunneling Protocol) to access a Microsoft Networking (SMB) environment and have your own Microsoft Networking environment in your local private network (Samba or Windows), give your local workgroup a name that does not show up in the remote environment. The reason is that while your PPTP client is logged into the remote environment, it will see the remote environment's domain name servers, and will only see the remote computers in that workgroup.You should avoid the lazy option. Microsoft ships Windows set up for a default workgroup name of WORKGROUP. Some people will be lazy and accept that as their workgroup when they set up their computers. So there is a good chance that the remote environment will have a workgroup called WORKGROUP, administrators willing or not.
I think that this will apply regardless of the VPN in use, as name services aren't dependent on the transport. If your client(s) can see the WINS servers on the remote network then you may experience this, PPTP or no PPTP.
If you're having trouble with IPX traffic over your PPTP link, please see sections 3.5 and 5.2 in this MS Knowledge Base article: http://microsoft.com/ntserver/nts/downloads/recommended/dun13win95/ReleaseNotes.asp
The same considerations probably apply to Win'98 as well.
Thanks to David Griswold <dgriswol@ix.netcom.com>
When you are using a VPN to access a MS network you should remember that you will have to provide two different authentication tokens - one to connect to the VPN server (the VPN password) and the other to access resources on the remote network once the connection is established (the network password).
The VPN password - the username and password you enter into your VPN client when initiating the call to the VPN server - is only used by the VPN server to grant you permission to connect to the network via the VPN. It isn't used for anything else once you're connected.
The VPN password is not used to prove your identity to other computers on the remote network. You must provide another username/password pair - your network password - for that.
There are two ways to supply a network password. Your network password may be the same username/password pair you supplied when logging onto the local network when you started your computer up. If it is different, you can configure your VPN client to ask you for your network password for the remote network once the VPN connection is established.
If you are successfully connecting to the VPN server but you cannot access any of the resources provided by the remote network, then you aren't providing a valid network username/password pair for the remote network. Verify that the username and password for your local network will also work on the remote network, or set your VPN client to prompt you for a username and password for use on the remote network and "log on" to the remote network once the VPN connection is established.
If you're having trouble with your IPsec tunnel regularly dying, particularly if checking the system logs on the firewall shows that ISAKMP packets with "zero cookie" values are being seen, here's what's happening:
Earlier versions of the IPsec Masq patch did not change the timeout for masq table entries for ISAKMP UDP packets. The masq table entries for the ISAKMP UDP traffic would time out fairly quickly (relative to the data channel) and be removed; if the remote IPsec host then decided to initiate rekeying before the local IPsec host did, the inbound ISAKMP traffic for the rekey couldn't be routed to the masqueraded host. The rekey traffic would be discarded, the remote IPsec host would think the link had failed, and the connection would eventually be terminated.
The 2.0.x patch has been modified from its original version to increase the timeout on ISAKMP UDP masq table entries. Get the current version of the patch, available via the sites given in the Resources section, and repatch and recompile your kernel.
Also verify that your IPsec Masq Table Lifetime parameter is
configured to be the same as or slightly longer than your rekey interval.
Did you remember to put modprobe ip_masq_pptp.o or
modprobe ip_masq_ipsec.o commands into your
/etc/rc.d/rc.local startup script if you compiled VPN Masq support
as modules?
The PPTP RFC specifies that there may only be one control channel between two systems. This may mean that only one masqueraded client will be able to contact a given PPTP server at a time. See multiclientpptp for more details.