RAD GNU/Linux Point-to-Point services HOWTO


Table of Contents

RAD GNU/Linux Point-to-Point services HOWTO
License
Thanks
Introduction
Common PPP topics
Authentication and Authorization
Accounting
Access-lists
Persistent client connections
Traffic shaping
Point-to-Point Protocol over Ethernet (PPPoE)
Configuring PPPoE server
Configuring PPPoE client
Point-to-Point Protocol over TCP (PPTP)
Configuring PPTP server
Configuring PPTP client

RAD GNU/Linux Point-to-Point services HOWTO

License

Copyright (c) 2005 RAD GNU/Linux project, Peter V. Saveliev.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the project homepage[1] and on the GNU site[2].

Thanks

Author acknowledges these people:

  • Lidia V. Starostina - documentation proofreading

And all the people from the RAD GNU/Linux maillists for their significant help in testing. Thank you.

Introduction

This document implies the basic knowledge of the network architecture, AAA (authentication, authorization and accounting) and network protocol levels understanding. The HOWTO doesn't cover all these topics.

Common PPP topics

RAD GNU/Linux starts all pppd(8)-based services in a similar way. This section describes common topics, applicable both to PPPoE and PPTP services.

Authentication and Authorization

RAD GNU/Linux supports RADIUS for AAA purposes as good as local user database. In case of RADIUS usage, a RADIUS-server can be installed either on a separate box or in a virtual context. RADIUS authorization and accounting can be provided by separate servers, so, there are separate directives in the config. Access key (radius-key ...) is used to gain authorized access to the RADIUS server and has to be provided for each server in the list.

Local user databases are maintained with these commands:

configure ppp pap , show ppp pap

Edit or show PAP user database. This database is used when option require-pap is defined.

configure ppp chap , show ppp chap

Edit or show CHAP user database. This database is used in all other cases such as option require-chap, option require-mschap-v2 and so on.

Other PPP related shell commands:

show ppp users

Show connected PPP users.

clear ppp line

Cancel an established session by PPP interface name.

Example 1. Configuration: PPPoE server with local user authorization

!
service pppoe Internet
	!
	! interfaces to listen on
	interface ethernet 0
	interface ethernet 1
	!
	! auth. mechanism definition
	option require-mschap-v2
	option mppe required
	!
	! pppoe-specific ...
	...
!
					

Example 2. Configuration: PPTP server with RADIUS auth

!
service pptp VPN
	!
	interface ethernet 0
	!
	! auth. mechanism definition
	!  this option is required to enable RADIUS support
	enable radius
	!  authorization RADIUS      -- {ipaddr:port}
	radius-auth 10.0.0.10:1812
	!  accounting RADIUS         -- {ipaddr:port}
	radius-acct 10.0.0.10:1813
	!  RADIUS server access key  -- {ipaddr} {key}
	radius-key  10.0.0.10  secret
	!
	! pptp-specific ...
	...
!
					

Example 3. PAP or CHAP database file format

#
# comments start with #
#
# note that username and password must be enclosed in
# double quotes
#
# "username"   server   "password"   ipaddr

"ptest"        *        "secret!"    10.0.0.4
"ptes1"        *        "blah"       *

#
# in this example user ptest will obtain the fixed ipaddr and
# dynamic ipaddr allocation will be used for ptes1
					

Accounting

In case of using a RADIUS server, accounting will be performed by RADIUS itself and will be stored according to the RADIUS server backend. RADIUS accounting is based on values provided by pppd(8), so, one must realize that these values will not correlate with real amount of a user's traffic. This is because pppd(8) accounts also service packets, not only the user's ones. Even more, in case of using any kind of compression, pppd(8) session accounting values can be below values on the external gateway interface. But in most cases such accounting is enough.

Another way to collect accounting is to use a syslog facility. This method is usable when the local user databases are used. Internal RAD GNU/Linux system log is limited by ~200Kb, so, one has to use a remote syslog on a separate box or in a virtual context. Collected log can be parsed to extract pppd(8) accounting records and aggregate them. Note, that syslog can drop records in case of high system load.

Example 4. Configuration: redirection syslog to another host

!
service syslog
	! log-server's ipaddr
	remote 10.0.0.5
!
					

And the last way to collect traffic accounting is to use service netflow. This service uses Cisco NetFlow v5 protocol to export collected information. Such flow can be processed, for instance, with flow-tools[3].

Example 5. Configuration: service netflow

!
service netflow
	!
	! interfaces to listen on
	interface ethernet 0
	!
	! dynamic instaface example: a new process will be
	! started for each new PPP session
	interface ppp*
	!
	! where to export the traffic
	export destination 127.0.0.1 9996
	!
	! one _must_ set memory-limit, otherwise memory
	! will be overfilled with buffered netflow accounting
	memory-limit 10m
	!
	! traffic aggregation is very advised to save the memory
	aggregate 192.168.0.0/16 strip 32
	aggregate 0.0.0.0/0 strip 24
	aggregate 3128-3128 into 3128
	aggregate 1024-65535 into 65535
	aggregate 150-1023 into 1023
!
					

Service netflow in RAD GNU/Linux is implemented with ipcad(8) [4]. Here are netflow related shell commands:

show ip accounting

Dump all collected info to a terminal.

show ip cache flow

Show active ip flows.

Access-lists

One can apply access-lists to any PPP-related service section like service pppoe or so. Once applied, access-list will produce firewall rules for each established PPP session.

Example 6. Configuration: combined access-list and service pppoe-client usage

!
access-list upstream
	masquerade any
!
service pppoe-client test
	interface ethernet 0
	option user ptest
	!
	! access-list application: any outgoing
	! traffic will be masqueraded
	access-list upstream out
!
					

Rules will be installed with a session setup and a session termination will cause rule deletion. Installed rules are showen with show ip table. In the example above, rule will be installed in the NAT table, so, one should use show ip table nat command.

Persistent client connections

Frequently it is desirable to re-establish a broken client session or to continue trying to connect until the access server become reachable. In this case one has to use persistent and maxfail pppd(8) options as it is shown in the example below.

Example 7. Configuration: persistent client connection

!
service pptp-client
	remote 10.0.0.1
	!
	! use ptest's credentials to login
	option user ptest
	!
	! persistent connection
	option persistent
	!
	! maxfail = 0 means that there is no limit
	! of failed attempts
	option maxfail 0
	!
	! turn the debug on
	option debug
!
					

Traffic shaping

There is no way to define traffic shaper for dynamic PPP interfaces in the regular config, as it is done with shaper rule ... and ip shaper ... for real interfaces. Instead of this, shaping rules for the PPP interfaces can be defined in a separate local database or received from a RADIUS server in Vendor-Specific attributes.

Example 8. PPP limits database file format

#
# prefix        limit

10.0            1Mbit
192.168.111     64Kbit
10.4.5.6        128Kbit

#
# 10.0 == 10.0.0.0/8, 192.168.111 == 192.168.111.0/24
# and so on
					

Related commands:

configure ppp limits , show ppp limits

Edit or show a limits database. This database is used any time when PPP session is established and no appropriate Vendor-Specific attribute is obtained from a RADIUS-server. If the peer ipaddr meets any coincidence in ths database, the corresponding shaper will be installed on the PPP interface for outgoing traffic.

show ip egress

Show install traffic shapers.

FIXME: a Vendor-Specific RADIUS attributes description!

Point-to-Point Protocol over Ethernet (PPPoE)

PPPoE is a widely used solution for deploying authenticated access in office or campus scale packet-switched networks. It provides all AAA facilities to authenticate users and to account traffic. This mechanism is supported by MS Windows (tm) OS family ("Broadband Internet connection") as good as by any GNU/Linux or FreeBSD/OpenBSD based system and therefore can be used natively, without any desperate efforts on the client-side when RAD GNU/Linux is acting as PPPoE server. PPPoE details can be found in RFC2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"[5].

Configuring PPPoE server

Both client and server PPPoE operation modes in RAD GNU/Linux are provided with rp-pppoe package[6] and the standard pppd(8) with MPPE[7]/MPPC[8] patch from Jan Dubiec[9].

To configure RAD GNU/Linux as a PPPoE server, one has to use service pppoe section. There can be several service pppoe sections, in this case each section has to be designated with unique name, for instance service pppoe Internet or service pppoe test.

Example 9. Configuration: several "service pppoe" sections

!
service pppoe gateway0
	interface bridge 0
	option require-pap
	option debug
!
service pppoe gateway1
	interface bridge 1
	option require-pap
	option debug
!
					
MSS clamping

In case of any incapsulation, maximum payload per packet is decreased by the size of incapsulated headers. So, path MTU discovery mechanism[10] (PMTUD) has to be used. But unfortunately there are unripe firewalls that disable PMTUD by blocking ICMP packets. Moreover, some operating systems cannot properly adjust MTU even when there are no barriers to do it.

This issue can be fixed with manual definition of MSS (Maximum Segment Size) for TCP packets, which is called "MSS clamping". MSS clamping doesn't solve problems with big ICMP or UDP packets, but for most cases it is enough. It is done using clamp-mss option.

Session limit

Amount of concurrent sessions for every PPPoE-server can be limited. By default, there can be only 64 sessions established at one moment. To change this limit, one can use session-limit option.

Service announce

There can be several PPPoE-servers listening in one Ethernet segment. To help users to distinguish one server from another, announce option has to be used.

Example 10. Configuration: PPPoE-specific options

!
service pppoe Internet
	interface ethernet 0
	...
	!
	! announce as "Internet"
	announce Internet
	!
	! reduce MSS of TCP packets
	clamp-mss 1400
	!
	! set session limit
	session-limit 1024
	
!
service pppoe Backup
	interface ethernet 0
	...
	!
	! backup channel
	announce Backup
	!
	! clamp MSS
	clamp-mss 1400
!
					

Configuring PPPoE client

There is a possibility to use RAD GNU/Linux as a gateway to the PPPoE-enabled upstream. For this purpose, service pppoe-client has to be used. Only the local password database authentication is applicable in this case.

Example 11. Configuration: PPPoE client service, minimal config

!
service pppoe-client test
	!
	interface ethernet 0
	!
	! such user must exist in the local PAP
	! or CHAP password database
	option user ptest
!
					

All the same issues related to service pppoe, are applicable to service pppoe-client. There can be several PPPoE-clients per interface and one service pppoe-client can contain several interface ... options. In the latter case, separate PPPoE clients will be started on every named interface, but all within one context.

A desired service name (corresponding server option is announce) can be defined with ?????, and access concentrator name - with acn option.

Example 12. Configuration: PPPoE client service, complete definition

!
interface ethernet 0
interface ethernet 1
!
access-list masquerade
	masquerade any
!
service pppoe-client
	!
	! separate pppd(8) processes will be started
	! for every interface, but all within one
	! context with the same options. To start
	! them with different options, use separate
	! sections
	interface ethernet 0
	interface ethernet 1
	!
	! such user must exist in the local PAP
	! or CHAP password database
	option user ptest
	!
	! do not forget to clamp MSS
	clamp-mss 1400
	!
	! choose right acn and service
	acn radlinux
	?????
	!
	! other pppd(8) options
	option debug
	option defaultroute
	access-list masquerade out
!
					

Point-to-Point Protocol over TCP (PPTP)

PPTP service offers encrypted tunneling over established TCP sessions. Encryption is done with MPPE/MPPC mechanisms and is supported by many operationg systems. Strictly speaking, PPTP is the primary solution to deploy VPN (Virtual Private Networks) on MS Windows (tm) platform and RAD GNU/Linux easily fits into this scheme. PPTP details can be found on a GNU/Linux PPTP implementation project's page[11] and on Microsoft (tm) server[12]

Configuring PPTP server

The way the PPTP service has to be defined is similar to PPPoE. But unlike PPPoE, PPTP works over established connections and therefore needs an IP address(es) of the server to be bound to. If no address is specified, PPTP server will listen for an incoming connection on all available interfaces.

Also one has to define IP address ranges to use for client sessions. After all defined IP addresses had been used, no one new connection can be established.

Example 13. Configuration: PPTP server

!
interface ethernet 0
	address 10.0.0.1/24
	address 192.168.0.1/24
!
! service's name is optional, but is desired
! in the case of several concurrent services
service pptp
	!
	! address to bind to
	address 10.0.0.1
	!
	! local and remote address-space
	local 192.168.111.1
	remote 192.168.111.2-254
	!
	! pppd(8) options
	!   encryption
	option required-mschap-v2
	option mppe required
	!   debug
	option debug
!
					
Firewall issues

In order to have PPTP working, one has to setup a firewall to accept incoming connections to TCP port 1723 and to allow protocol 47 (GRE)

Example 14. Configuration: firewall rules

!
interface ethernet 0
	address 10.0.0.1/24
	!
	! accept PPTP VPN connections
	access-list vpn in
	!
	! accept service traffic
	access-list maintenance in
	!
	! reject all other packets
	access-lsit reject in priority 100
!
access-list vpn
	!
	! accept GRE
	accept proto 47
	!
	! accept control connections
	accept proto tcp dport 1723
!
access-list maintenance
	!
	! accept DNS traffic
	accept proto udp sport 53
	!
	! accept NTP
	accept proto udp dport 123
!
access-list reject
	!
	! reject all packets
	reject any
!
						

In the example above, a real ethernet interface will be restriced to accept only DNS, NTP and VPN traffic. But established PPP sessions will not be firewalled, so, one can use VPN connection to gain a telnet session into the system.

ARP proxying

There is a possibility to announce PPTP client's MAC addresses to a local network so there will be appearance of one plain Ethernet segment. For such purpose, one must not define local address and must define remote addresses from the same range the LAN uses. Also, proxyarp option has to be set.

Example 15. Configuration: ARP proxying

!
interface ethernet 0
	address 192.168.0.1/24
!
service pptp
	!
	! note that remote addresses are
	! from the same range the local
	! interfac uses
	!
	! local address is not defined
	!
	remote 192.168.0.128-254
	!
	option require-mschap-v2
	option mppe required
	option debug
	!
	! enable ARP proxying
	option proxyarp
!
						

Configuring PPTP client

RAD GNU/Linux can also act as a client part of a VPN connection. This functionality is provided by service pptp-client section(s).

Example 16. Configuration: service pptp-client

!
! for details, see "service pppoe-client"
! examples
service pptp-client
	!
	! VPN access server address to connect to
	remote 10.0.0.1
	!
	! standard pppd(8) options
	option user ptest
	option persist
	option maxfail 0
	option debug
!
					


[5] ftp://ftp.rfc-editor.org/in-notes/rfc2516.txt - A Method for Transmitting PPP Over Ethernet (PPPoE)

[7] http://www.ietf.org/rfc/rfc3078.txt - Microsoft Point-To-Point Encryption (MPPE) Protocol

[8] http://www.ietf.org/rfc/rfc2118.txt - Microsoft Point-To-Point Compression (MPPC) Protocol