PPTPPROXY

Section: Maintenance Commands (8)
Index Return to Main Contents

NAME

pptpproxy - forward PPTP connections through firewalls

SYNOPSIS

pptpproxy [options]

DESCRIPTION

pptpproxy forwards the PPTP virtual private network (VPN) protocol through a firewall.

OPTIONS

-h,--help

Prints a short help message and exit.

-n,--nofork

Do not fork in the background and output diagnostics on stdout. This option is useful when running pptpproxy in a controled environment such as svscan.

-v,--version

Prints version and exit.

-d,--debug

Run in debug mode.

When running in debug mode pptpproxy

will log all its output to stdout.

will stay in the foreground (-nofork),

will output lots of mostly useless information about what it is doing.

-e,--extensive

Like debug, but with full packet dump

-l,--log logFile

Specify where to output log messages. his option forces output to be redirected to logFile, even if --debug or --nofork are specified.

-p,--proxy [listenAddress[:port],]peerAddress[:port]

Specify a proxy pair. pptpproxy will listen for incoming PPTP connections on listenAddress:port.

When a PPTP connection request is received on that specific address and port, the connection is forwarded to peerAddress:port.

Multiple proxy pairs can be specified. See the example section for details.

The listen address can be omited, in which case it defaults to 0.0.0.0 (listen on all local interfaces).

The port number can be omitted, in which case it defaults to 1723 (the standard PPTP tcp port).

The peer address is compulsory.

The peer port number can be omitted, in which case it defaults to 1723.

If the listenAddress:port conflicts with a previously specified one, the newly specified pair will be ignored.

At least one proxy pair must be specified for pptpproxy to do anything useful. It exits if you don't.

-a,--acl subnet/mask

Specify an access control list (ACL). For a connection to be forwarded by pptpproxy the connection request has to originate from an IP address that matches an ACL.

Multiple ACLs can be specified.

If no ACL's are specified, pptpproxy will accept any incoming connection.

-x,--aclCmd external command

Specify an external command to launch and verify incoming IP authorization. For a connection to be forwarded by pptpproxy the connection request has to originate from an IP address that is verified by the external command.

The external command is called with the IP address as an argument, and should return 0 if the IP address is authorized, and a non zero value otherwise.

Multiple external commands can be specified. All will be tried in order, until one is found that authorizes the IP. If all external command fail to validate the IP address, pptpproxy will reject the connection attempt.

EXAMPLES

Scenario 1: home user with personal firewall

A home user workstation has an IP address of 192.0.168.2.

The workstation can access the internet through a personal unix firewall.

The unix firewall is dual-homed (it has two network interfaces).

One of the firewall's interfaces has an IP address of 192.0.168.1 and is used to communicate with the "inside" LAN.

The other firewall's interface is used to communicate with the "outside" (the internet). It can have a static or dynamically changing IP address.

The workstation user would like to establish a VPN between his machine and a remote PPTP server located at IP address pptp.mycorp.com in order to get work done from home.

Solution:

1. Configure the workstation to connect to a PPTP server located at 192.0.168.1. All other configurations should be as if connecting directly to pptp.mycorp.com

2. Run pptpproxy as follows on the unix firewall:

pptpproxy -p pptp.mycorp.com -a 192.0.168.0/255.255.255.0

Scenario 2: firewalled PTPP server

A pptp server is running on a machine behind a unix firewall.

The pptp server has an IP address of 192.0.168.27.

The unix firewall is dual-homed.

One of the firewall's interfaces is used to communicate with the "inside" LAN.

The other firewall's interface has an IP address of firewall.mycorp.com and is used to communicate with the "outside" (the internet).

The system administrator of this LAN would like to make the internal PPTP server accessible to remote internet users.

Solution:

1. Configure user workstations to connect to a PPTP server located at firewall.mycorp.com. All other configurations should be as if connecting directly to 192.0.168.27

2. Run pptpproxy as follows on the unix firewall:

pptpproxy -p 192.0.168.27 -a 255.255.255.255/0.0.0.0

Scenario 3:firewalled client + firewalled server

The combination of the two above: a home user workstation behind a personal firewall trying to access a PPTP server that is behind yet another firewall.

Solution:

On the personal user firewall, run:

pptpproxy -p pptp.mycorp.com -a 192.0.168.0/255.255.255.0

On the server side firewall, run:

pptpproxy -p 192.0.168.27 -a 255.255.255.255/0.0.0.0

DIAGNOSTICS

In --debug mode or in --nofork mode, pptpproxy will return an exit value of 1 upon encountering a fatal error.

In normal mode, pptpproxy will fork itself in the background and should return an exit value of 0 unless it met with a fatal error prior to doing this. Further diagnostics can be examined via the system log.

PROXY CHAINING

It is perfectly possible to have a chain of proxies, one instance of pptpproxy relaying to the next.

A possible use for such a setup would be to bypass certain vendor's PPTP implementation limitations that lets the user specify the server's IP address but prevents him/her from specifiying a TCP port.

Using two instances of pptpproxy , one running on the firewall, the other on another computer, it becomes possible to route a PPTP connection on port 1723 on that computer to another port on the firewall's pptpproxy instance, but on a different port, thereby allowing people to connect to different PPTP peers on the other side of the firewall.

LIMITATIONS

The PPTP protocol works with two concurrent communication pathes, a so-called "control connection" over a regular TCP pipe, and another packet-based, portless path that handles the actual data transfer.

For scalability reasons, pptpproxy's architeture was designed around two threads.

The main thread forwards the TCP control connections. It also peeps at the passing TCP chitchat in order to keep a database of "living" PPTP connection, and their so called "call id" (see RFC 2637 for details).

The second thread handles the PPTP packet-based path. For each data packet received, it extracts its "call id" and queries the connection database in order to figure out the packet's actual destination.

Because of this design, only one instance of pptpproxy can be run on a given machine at a given time, because if more were to be run, the packet-based path handler thread might receive packets with caller ids not registered in it's connection database, and would thus discard them.

The good nes is, this instance is perfectly capable of handling any number of simultaneous connections, so running two instances of pptpproxy should never be necessary.

BUGS

The proper way of forwarding PPTP is to use native kernel NAT, but it isn't always easy, feasible or even implemented properly. pptpproxy was written for these situations.

Microsoft's implementation of the PPTP protocol is not secure at all. Using PPTP to carry sensitive data through the internet over Microsoft's PPTP is not a very good idea.

As of this writing, poptop, the Linux pptp server, does not handle multiple simultaneous connections originating from the same IP address. As a result, if you are trying to connect multiple home machines to a remote poptop server via pptpproxy, it will not work.