To test VPN Masquerade:
RASMONif 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.SYSor 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 printcommand and look for an
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
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.
/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.
ipfwdif you're masquerading the server.
You may find it helpful to turn on VPN debugging and recompile your kernel. Add the following to
and watch# debugging *.=debug /var/log/debug
/var/log/debugfor 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 <firstname.lastname@example.org> 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 <email@example.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.