pptp
PPTP driver
see also :
pppd
Synopsis
pptp
<pptp-server-IP> <pptp-options> [ppp-options]
...
add an example, a script, a trick and tips
examples
source
Fedora 19 and PPTP
Just install all required PPTP packages. This has
changed since Kernel 3.10.3-300. The packages are not installed
by default anymore.
Connection to a Microsoft Windows VPN Server
pppd noauth nobsdcomp nodeflate require-mppe-128 name
domain\\\\username remotename PPTP pty "pptp 10.0.0.5
--nolaunchpppd"
Note that the chap-secrets file used by pppd must
include an entry for domain\\username
source
Unable to connect to PPTP VPN with Ubuntu 10.04
I have the same issues with my company laptop. I've been using
Debian Lenny for about a year. I get around those Linux
limitations by running Microsoft Windows in a VirtualBox VM. I
can VPN into our corporate office inside the VM. That lets me
access the corporate network from inside the VM, but not from the
Linux host.
source
Linux PPTP VPN and gateway woes
The 192.168.7.0/24 network is not routed via ppp0
route add -net 192.168.7.0/24 gw 0.0.0.0 ppp0
source
ssh tunnel via specific interface
You're looking for -b. But this is pointless unless
ppp0 already has a route to nas.
source
Forcing Deluge traffic down ppp0 adapter?
You can use the owner netfilter module. For example,
run deluged as a deluge user and then
apply the rule:
iptables -A OUTPUT -m owner --uid-owner deluge \! -o tun0
-j REJECT
It will reject everything except connections to tun0 for any
processes under deluge user.
source
Creating stable, automatically reconnecting PPTP connection in Ubuntu
Yes, Use kvpnc. It works well, is much more advanced than NM's
VPN support, and can automatically reconnect upon a disconnect.
sudo aptitude install kvpnc
note that you may have to install some other packages such as
pptp-linux. Check the kvpnc settings for more info.
source
PPTP without GRE: possible?
No, this is not possible.
PPTP is using TCP port 1723 to build up the tunnel, but the data
carried over the VPN always GRE.
This is then the IP protocol 47 (Not TCP!)
Anyway PPTP is security wise not a good solution and should be
replaced by a better protocol.
OpenVPN is one of the flexible VPN solutions
source
PPTP: Linux clients unreachable
On the VPN SERVER, following need to be done:
Enable tcp/ip forwarding
Linux TCP/IP stack by default does not forward packets (either
between interfaces or re-routing them between IP network). It has
to be enabled
echo 1 > /proc/sys/net/ipv4/ip_forward
Without that, VPN server will accept VPN client packet locally,
and route client packet according to NAT rule, but will not route
traffic to local network, which include other vPN client.
Iptables
Iptables block all traffic by default. You need rules to allow
traffic to get through.
$IPTABLES -A FORWARD -s 192.168.1.0/24 -d 192.168.1.0/24 -j ACCEPT
Change 192.168.1.0/24 to match your vpn network
ip addresses. That will allow traffic between your vpn network
machines.
/etc/pptp.conf
When vpn client need to talk to each together, the vpn server is
acting as a routing point and need to be on the same netowrk.
localip 192.168.1.1
remoteip 192.168.1.2-254
Modify the above according to your network setup.
source
Set linux routing tables to route F5 vpn and internet traffic
I found a nice little tutorial here:
http://www.gentoo.org/doc/en/vpnc-howto.xml#doc_chap7
I had the same issue that you did: I had two default routes.
Unfortunately, I have a Juniper VPN that exits as soon as you
mess with the default route.
But, the way I understand it, you can remove the default VPN
route with this command:
sudo route del default gw XXX.XXX.XXX.XXX
Then, you can add the specific subnet routing with this:
sudo route add -net XXX.XXX.XXX.XXX netmask 255.255.255.0 dev tun0
You may need to adjust your netmask to match the network you are
going for. The "tun0" is the device of the VPN. You can use
ifconfig to see which device your vpn added.
Just FYI, I believe this technique is called split tunneling.
From what I understand, the vpn administrator can either allow or
disallow the split tunneling. The Juniper VPN seems to do a good
job of enforcing this decision, and I can't see a way to override
it.
description
pptp
establishes the client side of a Virtual Private Network
(VPN) using the Point-to-Point Tunneling Protocol (PPTP).
Use this program to connect to an employer’s PPTP
based VPN, or to certain cable and ADSL service
providers.
By default,
pptp establishes the PPTP call to the PPTP server,
and then starts an instance of pppd to manage the
data transfer. However, pptp can also be run as a
connection manager within pppd.
options
The first
non-option argument on the pptp command line
must be the host name or IP address of the PPTP server.
All long
options (starting with "--") are
interpreted as pptp options, and a fatal error occurs if an
unrecognised option is used.
All
command-line arguments which do not start with
"-" are interpreted as ppp options, and
passed as is to pppd unless
--nolaunchpppd is given.
--phone <number>
Pass <number> to remote
host as phone number
--nolaunchpppd
Do not launch pppd but
use stdin as the network connection. Use this flag when
including pptp as a pppd connection process
using the pty option. See EXAMPLES.
--quirks
<quirk>
Work around a buggy PPTP
implementation, adopts special case handling for particular
PPTP servers and ADSL modems. Currently recognised values
are BEZEQ_ISRAEL only
--debug
Run in foreground (for
debugging with gdb)
--sync
Enable Synchronous HDLC (pppd must use it too)
--timeout
<secs>
Time to wait for reordered
packets (0.01 to 10 secs)
--nobuffer
Completely disables buffering
and reordering of packets. Any --timeout
specified will be ignored.
--idle-wait
<secs>
Time to wait before sending a
control connection echo request. The RFC2637 default is 60
seconds.
--max-echo-wait
<secs>
Time to wait for an echo reply
before closing the control connection. The RFC2637 default
is 60 seconds.
--logstring
<name>
Use <name> instead of
’anon’ in syslog messages
--localbind
<addr>
Bind to specified IP address
instead of wildcard
--loglevel
<level>
Sets the debugging level
(0=low, 1=default, 2=high)
--test-type
<n>
Enable packet reordering tests
that damage the integrity of the packet stream to the
server. Use this only when testing servers. Zero is the
default, and means that packets are sent in the correct
order. A value of one (1) causes a single swap between two
packets, such that the sequence numbers might be 1 2 3 4 6 5
7 8 9. A value of two (2) causes ten packets to be buffered,
then sent out of order but ascending, such that the sequence
numbers might be 1 2 3 4 16 6 7 8 9 10 11 12 13 14 15 17 18
19 20. A value of three (3) causes ten packets to be
buffered, then sent in the reverse order, like this; 1 2 3 4
16 15 14 13 12 11 10 9 8 7 6 5 17 18 19 20.
--test-rate
<n>
Sets the number of packets to
pass before causing a reordering test. Default is 100. Has
no effect if test-type is zero. The result of test types 2
and 3 are undefined if this value is less than ten.
quirks
BEZEQ_ISRAEL
modifies packets to interoperate with Orckit ADSL modems on the
BEZEQ network in Israel.
statistics
The pptp process collects statistics when sending and receiving
GRE packets. They are intended to be useful for debugging poor
PPTP performance and for general monitoring of link quality. The
statistics are cumulative since the pptp process was started.
The statistics can be viewed by sending a SIGUSR1 signal to the
"GRE-to-PPP Gateway" process, which will cause it to dump them to
the system logs (at the LOG_NOTICE level). A better way to
present the statistics to applications is being sought (e.g.
SNMP?).
The following statistics are collected at the time of writing
(April 2003):
rx accepted
the number of GRE packets successfully passed to PPP
rx lost
the number of packets never received, and presumed lost in the
network
rx under win
the number of packets which were duplicates or had old sequence
numbers (this might be caused by a packet-reordering network if
your reordering timeout is set too low)
rx over win
the number of packets which were too far ahead in the sequence to
be reordered (might be caused by loss of more than 300 packets in
a row)
rx buffered
the number of packets which were slightly ahead of sequence, and
were either buffered for reordering, or if buffering is disabled,
accepted immediately (resulting in the intermediate packets being
discarded).
rx OS errors
the number of times where the operating system reported an error
when we tried to read a packet
rx truncated
the number of times we received a packet which was shorter than
the length implied by the GRE header
rx invalid
the number of times we received a packet which had invalid or
unsupported flags set in the header, wrong version, or wrong
protocol.
rx acks
the number of pure acknowledgements received (without data). Too
many of these will waste bandwidth, and might be solved by tuning
the remote host.
tx sent
the number of GRE packets sent with data
tx failed
the number of packets we tried to send, but the OS reported an
error
tx short
the number of times the OS would not let us write a complete
packet
tx acks
the number of times we sent a pure ack, without data
tx oversize
the number of times we couldn’t send a packet because it was over
PACKET_MAX bytes long
round trip
the estimated round-trip time in milliseconds
see also
pppd
Documentation
in /usr/share/doc/pptp
author
This manual
page was written by James Cameron
<james.cameron[:at:]hp[:dot:]com> from text contributed by Thomas
Quinot <thomas[:at:]debian[:dot:]org>, for the Debian GNU/Linux
system. The description of the available statistics was
written by Chris Wilson <chris[:at:]netservers.co[:dot:]uk>.
Updates for the Debian distribution by Ola Lundqvist
<opal[:at:]debian[:dot:]org>.