From 6be06966e3bbb19bebd093b142e332ba869044ea Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 24 Dec 2023 15:41:30 +0100 Subject: [PATCH] Use Makefile rules to generate documentation And regenerate documentation. --- Makefile | 5 +- docs/Makefile | 29 ++ docs/gen-docs.sh | 33 -- docs/html/manual.html | 777 +++++++++++++++++++++++++-------- docs/html/practical-vpns.html | 371 ++++++++++++---- docs/manpages/l2tpns.8 | 16 +- docs/manpages/nsctl.8 | 16 +- docs/manpages/startup-config.5 | 22 +- 8 files changed, 953 insertions(+), 316 deletions(-) create mode 100644 docs/Makefile delete mode 100755 docs/gen-docs.sh diff --git a/Makefile b/Makefile index ece5fcd..cc0f561 100644 --- a/Makefile +++ b/Makefile @@ -43,12 +43,15 @@ endif DEFINES += -DBGP OBJS += bgp.o -all: programs plugins +all: programs plugins doc programs: $(PROGRAMS) plugins: $(PLUGINS) +doc: + $(MAKE) -C docs clean: rm -f *.o test/*.o $(PROGRAMS) $(PLUGINS) Makefile.tmp Makefile.bak + $(MAKE) -C docs clean depend: (sed -n 'p; /^## Dependencies: (autogenerated) ##/q' Makefile && \ diff --git a/docs/Makefile b/docs/Makefile new file mode 100644 index 0000000..cfbb003 --- /dev/null +++ b/docs/Makefile @@ -0,0 +1,29 @@ +ifeq (,$(shell command -v pandoc)) +all: +clean: +else + +# Source documentation in markdown lives in the src/ folder (html and manpages). +# This is what you should edit if you want to make changes to the documentation. +# From these sources, this script generates actual manpages and general +# documentation in html using pandoc. + +HTML_MD = $(wildcard src/html/*.md) +MAN_MD = $(wildcard src/man/*.md) + +HTML_HTML = $(patsubst src/html/%.md,html/%.html,$(HTML_MD)) +MAN_MAN = $(patsubst src/man/%.md,manpages/%,$(MAN_MD)) + +all: $(HTML_HTML) $(MAN_MAN) + +html/%.html: src/html/%.md + pandoc -f markdown -t html $< > $@ + echo $@ successfully built in docs/html directory + +manpages/%: src/man/%.md + pandoc -s -t man $< -o $@ + echo $@ successfully built in docs/manpages directory + +clean: + rm -f html/*.html manpages/*.[58] +endif diff --git a/docs/gen-docs.sh b/docs/gen-docs.sh deleted file mode 100755 index e112d56..0000000 --- a/docs/gen-docs.sh +++ /dev/null @@ -1,33 +0,0 @@ -#!/bin/sh - -# Source documentation in markdown lives in the src/ folder (html and manpages). -# This is what you should edit if you want to make changes to the documentation. -# From these sources, this script generates actual manpages and general -# documentation in html using pandoc. - -if ! [ -x "$(command -v pandoc)" ]; then - echo "Pandoc is missing, please install it first" - exit 1 -fi - -# First we generate manpages - -echo "Manpages generation …" - -for src in src/man/*.md - do - pandoc -s -t man "$src" -o manpages/"$(basename "$src" .md)" && echo "$(basename "$src" .md) successfully built in docs/manpages directory" || echo "Unable to generate manpage from $src" -done - -# We then generate the rest of the documentation - -echo "" - -echo "HTML generation …" - - -for src in src/html/*.md - do - pandoc -f markdown -t html "$src" > html/"$(basename "$src" .md)".html && echo "$(basename "$src" .md).html successfully built in docs/html directory" || echo "Unable to generate html from $src" -done - diff --git a/docs/html/manual.html b/docs/html/manual.html index 3600459..3441a52 100644 --- a/docs/html/manual.html +++ b/docs/html/manual.html @@ -1,199 +1,401 @@

Overview

-

l2tpns is half of a complete L2TP implementation. It supports only the LNS side of the connection.

-

L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 protocol (e.g. Ethernet, PPP) to be tunneled over an IP connection. l2tpns implements PPP over L2TP only.

-

There are a couple of other L2TP implementations, of which l2tpd is probably the most popular. l2tpd also will handle being either end of a tunnel, and is a lot more configurable than l2tpns. However, due to the way it works, it is nowhere near as scalable.

-

l2tpns uses the TUN/TAP interface provided by the Linux kernel to receive and send packets. Using some packet manipulation it doesn't require a single interface per connection, as l2tpd does.

-

This allows it to scale extremely well to very high loads and very high numbers of connections.

-

It also has a plugin architecture which allows custom code to be run during processing. An example of this is in the walled garden module included.

+

l2tpns is half of a complete L2TP implementation. It +supports only the LNS side of the connection.

+

L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 +protocol (e.g. Ethernet, PPP) to be tunneled over an IP connection. +l2tpns implements PPP over L2TP only.

+

There are a couple of other L2TP implementations, of which l2tpd is probably the +most popular. l2tpd also will handle being either end of a tunnel, and +is a lot more configurable than l2tpns. However, due to the +way it works, it is nowhere near as scalable.

+

l2tpns uses the TUN/TAP interface provided by the Linux +kernel to receive and send packets. Using some packet manipulation it +doesn't require a single interface per connection, as l2tpd does.

+

This allows it to scale extremely well to very high loads and very +high numbers of connections.

+

It also has a plugin architecture which allows custom code to be run +during processing. An example of this is in the walled garden module +included.

Installation

Requirements

Compiling

-

You can generally get away with just running make from the source directory. This will compile the daemon, associated tools and any modules shipped with the distribution.

+

You can generally get away with just running make from +the source directory. This will compile the daemon, associated tools and +any modules shipped with the distribution.

Installing

-

After you have successfully compiled everything, run make install to install it. By default, the binaries are installed into /usr/sbin, the configuration into /etc/l2tpns, and the modules into /usr/lib/l2tpns.

-

You will definately need to edit the configuration files before you start. See Configuration for more information.

+

After you have successfully compiled everything, run +make install to install it. By default, the binaries are +installed into /usr/sbin, the configuration into +/etc/l2tpns, and the modules into +/usr/lib/l2tpns.

+

You will definately need to edit the configuration files before you +start. See Configuration for more +information.

Running

-

You only need to run /usr/sbin/l2tpns as root to start it. It does not normally detach to a daemon process (see the -d option), so you should perhaps run it from init.

-

By default there is no log destination set, so all log messages will go to stdout.

+

You only need to run /usr/sbin/l2tpns as root to start +it. It does not normally detach to a daemon process (see the +-d option), so you should perhaps run it from +init.

+

By default there is no log destination set, so all log messages will +go to stdout.

Configuration

-

All configuration of the software is done from the files installed into /etc/l2tpns.

+

All configuration of the software is done from the files installed +into /etc/l2tpns.

startup-config

-

This is the main configuration file for l2tpns. The format of the file is a list of commands that can be run through the command-line interface. This file can also be written directly by the l2tpns process if a user runs the write memory command, so any comments will be lost. However if your policy is not to write the config by the program, then feel free to comment the file with a # or ! at the beginning of the line.

-

A list of the possible configuration directives follows. Each of these should be set by a line like: set configstring "value" set ipaddress 192.168.1.1 set boolean true

+

This is the main configuration file for l2tpns. The +format of the file is a list of commands that can be run through the +command-line interface. This file can also be written directly by the +l2tpns process if a user runs the write memory +command, so any comments will be lost. However if your policy is not to +write the config by the program, then feel free to comment the file with +a # or ! at the beginning of the line.

+

A list of the possible configuration directives follows. Each of +these should be set by a line like: set configstring "value" set +ipaddress 192.168.1.1 set boolean true

debug (int)
-

Sets the level of messages that will be written to the log file. The value should be between 0 and 5, with 0 being no debugging, and 5 being the highest. A rough description of the levels is:

+
+

Sets the level of messages that will be written to the log file. The +value should be between 0 and 5, with 0 being no debugging, and 5 being +the highest. A rough description of the levels is:

0: Critical Errors
-

Things are probably broken

+
+

Things are probably broken

1: Errors
-

Things might have gone wrong, but probably will recover

+
+

Things might have gone wrong, but probably will recover

2: Warnings
-

Just in case you care what is not quite perfect

+
+

Just in case you care what is not quite perfect

3: Information
-

Parameters of control packets

+
+

Parameters of control packets

4: Calls
-

For tracing the execution of the code

+
+

For tracing the execution of the code

5: Packets
-

Everything, including a hex dump of all packets processed... probably twice

+
+

Everything, including a hex dump of all packets processed... probably +twice

-

Note that the higher you set the debugging level, the slower the program will run. Also, at level 5 a lot of information will be logged. This should only ever be used for working out why it doesn't work at all.

+

Note that the higher you set the debugging level, the slower the +program will run. Also, at level 5 a lot of information will be +logged. This should only ever be used for working out why it doesn't +work at all.

log_file (string)
-

This will be where all logging and debugging information is written to. This may be either a filename, such as /var/log/l2tpns, or the special magic string syslog:facility, where facility is any one of the syslog logging facilities, such as local5.

+
+

This will be where all logging and debugging information is written +to. This may be either a filename, such as /var/log/l2tpns, +or the special magic string syslog:facility, where facility +is any one of the syslog logging facilities, such as +local5.

pid_file (string)
-

If set, the process id will be written to the specified file. The value must be an absolute path.

+
+

If set, the process id will be written to the specified file. The +value must be an absolute path.

random_device (string)
-

Path to random data source (default /dev/urandom). Use "" to use the rand() library function.

+
+

Path to random data source (default /dev/urandom). Use +"" to use the rand() library function.

l2tp_secret (string)
-

The secret used by l2tpns for authenticating tunnel request. Must be the same as the LAC, or authentication will fail. Only actually be used if the LAC requests authentication.

+
+

The secret used by l2tpns for authenticating tunnel +request. Must be the same as the LAC, or authentication will fail. Only +actually be used if the LAC requests authentication.

l2tp_mtu (int)
-

MTU of interface for L2TP traffic (default: 1500). Used to set link MRU and adjust TCP MSS.

+
+

MTU of interface for L2TP traffic (default: 1500). Used +to set link MRU and adjust TCP MSS.

-
ppp_restart_time (int); ppp_max_configure (int); ppp_max_failure (int)
-

PPP counter and timer values, as described in §4.1 of RFC1661.

+
mp_mrru (int)
+
+

MRRU for MP traffic (default: 1614). Can be set to 0 to +disable MP negociation.

-
primary_dns (ip address); econdary_dns (ip address)
-

Whenever a PPP connection is established, DNS servers will be sent to the user, both a primary and a secondary. If either is set to 0.0.0.0, then that one will not be sent.

+
ppp_restart_time (int); ppp_max_configure +(int); ppp_max_failure (int)
+
+

PPP counter and timer values, as described in §4.1 of RFC1661.

-
primary_radius (ip address); secondary_radius (ip address)
-

Sets the RADIUS servers used for both authentication and accounting. If the primary server does not respond, then the secondary RADIUS server will be tried.

+
primary_dns (ip address); econdary_dns (ip +address)
+
+

Whenever a PPP connection is established, DNS servers will be sent to +the user, both a primary and a secondary. If either is set to 0.0.0.0, +then that one will not be sent.

+
+
primary_radius (ip address); +secondary_radius (ip address)
+
+

Sets the RADIUS servers used for both authentication and accounting. +If the primary server does not respond, then the secondary RADIUS server +will be tried.

-

In addition to the source IP address and identifier, the RADIUS server must include the source port when detecting duplicates to suppress (in order to cope with a large number of sessions coming on-line simultaneously l2tpns uses a set of udp sockets, each with a separate identifier).

+

In addition to the source IP address and identifier, the RADIUS +server must include the source port when detecting duplicates +to suppress (in order to cope with a large number of sessions coming +on-line simultaneously l2tpns uses a set of udp sockets, +each with a separate identifier).

-
primary_radius_port (short); secondary_radius_port (short)
-

Sets the authentication ports for the primary and secondary RADIUS servers. The accounting port is one more than the authentication port. If no RADIUS ports are given, the authentication port defaults to 1812, and the accounting port to 1813.

+
primary_radius_port (short); +secondary_radius_port (short)
+
+

Sets the authentication ports for the primary and secondary RADIUS +servers. The accounting port is one more than the authentication port. +If no RADIUS ports are given, the authentication port defaults to 1812, +and the accounting port to 1813.

radius_accounting (boolean)
-

If set to true, then RADIUS accounting packets will be sent. This means that a Start record will be sent when the session is successfully authenticated, and a Stop record will be sent when the session is closed.

+
+

If set to true, then RADIUS accounting packets will be sent. This +means that a Start record will be sent when the session is successfully +authenticated, and a Stop record will be sent when the session is +closed.

radius_interim (int)
-

If radius_accounting is on, defines the interval between sending of RADIUS interim accounting records (in seconds).

+
+

If radius_accounting is on, defines the interval between +sending of RADIUS interim accounting records (in seconds).

radius_secret (string)
-

This secret will be used in all RADIUS queries. If this is not set then RADIUS queries will fail.

+
+

This secret will be used in all RADIUS queries. If this is not set +then RADIUS queries will fail.

radius_authtypes (string)
-

A comma separated list of supported RADIUS authentication methods (pap or chap), in order of preference (default pap).

+
+

A comma separated list of supported RADIUS authentication methods +(pap or chap), in order of preference (default +pap).

-
radius_bind_min (short); radius_bind_max (short)
-

Define a port range in which to bind sockets used to send and receive RADIUS packets. Must be at least RADIUS_FDS (64) wide. Simplifies firewalling of RADIUS ports (default: dynamically assigned).

+
radius_bind_min (short); radius_bind_max +(short)
+
+

Define a port range in which to bind sockets used to send and receive +RADIUS packets. Must be at least RADIUS_FDS (64) wide. Simplifies +firewalling of RADIUS ports (default: dynamically assigned).

radius_dae_port (short)
-

Port for DAE RADIUS (Packet of Death/Disconnect, Change of Authorization) requests (default: 3799).

+
+

Port for DAE RADIUS (Packet of Death/Disconnect, Change of +Authorization) requests (default: 3799).

allow_duplicate_users (boolean)
-

Allow multiple logins with the same username. If false (the default), any prior session with the same username will be dropped when a new session is established.

+
+

Allow multiple logins with the same username. If false (the default), +any prior session with the same username will be dropped when a new +session is established.

guest_account (string)
-

Allow multiple logins matching this specific username.

+
+

Allow multiple logins matching this specific username.

bind_address (ip address)
-

When the tun interface is created, it is assigned the address specified here. If no address is given, 1.1.1.1 is used. Packets containing user traffic should be routed via this address if given, otherwise the primary address of the machine.

+
+

When the tun interface is created, it is assigned the address +specified here. If no address is given, 1.1.1.1 is used. Packets +containing user traffic should be routed via this address if given, +otherwise the primary address of the machine.

peer_address (ip address)
-

Address to send to clients as the default gateway.

+
+

Address to send to clients as the default gateway.

send_garp (boolean)
-

Determines whether or not to send a gratuitous ARP for the bind_address when the server is ready to handle traffic (default: true). This value is ignored if BGP is configured.

+
+

Determines whether or not to send a gratuitous ARP for the +bind_address when the server is ready to handle traffic (default: +true). This value is ignored if BGP is configured.

throttle_speed (int)
-

Sets the default speed (in kbits/s) which sessions will be limited to. If this is set to 0, then throttling will not be used at all. Note: You can set this by the CLI, but changes will not affect currently connected users.

+
+

Sets the default speed (in kbits/s) which sessions will be limited +to. If this is set to 0, then throttling will not be used at all. Note: +You can set this by the CLI, but changes will not affect currently +connected users.

throttle_buckets (int)
-

Number of token buckets to allocate for throttling. Each throttled session requires two buckets (in and out).

+
+

Number of token buckets to allocate for throttling. Each throttled +session requires two buckets (in and out).

accounting_dir (string)
-

If set to a directory, then every 5 minutes the current usage for every connected use will be dumped to a file in this directory. Each file dumped begins with a header, where each line is prefixed by #. Following the header is a single line for every connected user, fields separated by a space.

-

The fields are username, ip, qos, uptxoctets, downrxoctets. The qos field is 1 if a standard user, and 2 if the user is throttled.

+
+

If set to a directory, then every 5 minutes the current usage for +every connected use will be dumped to a file in this directory. Each +file dumped begins with a header, where each line is prefixed by +#. Following the header is a single line for every +connected user, fields separated by a space.

+

The fields are username, ip, qos, uptxoctets, downrxoctets. The qos +field is 1 if a standard user, and 2 if the user is throttled.

dump_speed (boolean)
-

If set to true, then the current bandwidth utilization will be logged every second. Even if this is disabled, you can see this information by running the uptime command on the CLI.

+
+

If set to true, then the current bandwidth utilization will be logged +every second. Even if this is disabled, you can see this information by +running the uptime command on the CLI.

multi_read_count (int)
-

Number of packets to read off each of the UDP and TUN fds when returned as readable by select (default: 10). Avoids incurring the unnecessary system call overhead of select on busy servers.

+
+

Number of packets to read off each of the UDP and TUN fds when +returned as readable by select (default: 10). Avoids incurring the +unnecessary system call overhead of select on busy servers.

scheduler_fifo (boolean)
-

Sets the scheduling policy for the l2tpns process to SCHED_FIFO. This causes the kernel to immediately preempt any currently running SCHED_OTHER (normal) process in favour of l2tpns when it becomes runnable. Ignored on uniprocessor systems.

+
+

Sets the scheduling policy for the l2tpns process to +SCHED_FIFO. This causes the kernel to immediately preempt +any currently running SCHED_OTHER (normal) process in +favour of l2tpns when it becomes runnable. Ignored on +uniprocessor systems.

lock_pages (boolean)
-

Keep all pages mapped by the l2tpns process in memory.

+
+

Keep all pages mapped by the l2tpns process in +memory.

icmp_rate (int)
-

Maximum number of host unreachable ICMP packets to send per second.

+
+

Maximum number of host unreachable ICMP packets to send per +second.

packet_limit (int)
-

Maximum number of packets of downstream traffic to be handled each tenth of a second per session. If zero, no limit is applied (default: 0). Intended as a DoS prevention mechanism and not a general throttling control (packets are dropped, not queued).

+
+

Maximum number of packets of downstream traffic to be handled each +tenth of a second per session. If zero, no limit is applied (default: +0). Intended as a DoS prevention mechanism and not a general throttling +control (packets are dropped, not queued).

cluster_address (ip address)
-

Multicast cluster address (default: 239.192.13.13). See Clustering for more information.

+
+

Multicast cluster address (default: 239.192.13.13). See Clustering for more information.

cluster_port (udp port)
-

UDP cluster port (default: 32792). See Clustering for more information.

+
+

UDP cluster port (default: 32792). See Clustering for more information.

cluster_interface (string)
-

Interface for cluster packets (default: eth0)

+
+

Interface for cluster packets (default: eth0)

cluster_mcast_ttl (int)
-

TTL for multicast packets (default: 1).

+
+

TTL for multicast packets (default: 1).

cluster_hb_interval (int)
-

Interval in tenths of a second between cluster heartbeat/pings.

+
+

Interval in tenths of a second between cluster heartbeat/pings.

cluster_hb_timeout (int)
-

Cluster heartbeat timeout in tenths of a second. A new master will be elected when this interval has been passed without seeing a heartbeat from the master.

+
+

Cluster heartbeat timeout in tenths of a second. A new master will be +elected when this interval has been passed without seeing a heartbeat +from the master.

cluster_master_min_adv (int)
-

Determines the minimum number of up to date slaves required before the master will drop routes (default: 1).

+
+

Determines the minimum number of up to date slaves required before +the master will drop routes (default: 1).

ipv6_prefix (ipv6 address)
-

Enable negotiation of IPv6. This forms the the first 64 bits of the client allocated address. The remaining 64 come from the allocated IPv4 address and 4 bytes of 0s.

+
+

Enable negotiation of IPv6. This forms the the first 64 bits of the +client allocated address. The remaining 64 come from the allocated IPv4 +address and 4 bytes of 0s.

BGP

-

BGP routing configuration is entered by the command: router bgp as where as specifies the local AS number.

-

Subsequent lines prefixed with neighbour peer define the attributes of BGP neighhbours. Valid commands are: neighbour peer remote-as as neighbour peer timers keepalive hold

-

Where peer specifies the BGP neighbour as either a hostname or IP address, as is the remote AS number and keepalive, hold are the timer values in seconds.

+

BGP routing configuration is entered by the command: router bgp as +where as specifies the local AS number.

+

Subsequent lines prefixed with neighbour peer define the attributes +of BGP neighhbours. Valid commands are: neighbour peer remote-as as +neighbour peer timers keepalive hold

+

Where peer specifies the BGP neighbour as either a hostname or IP +address, as is the remote AS number and keepalive, hold are the timer +values in seconds.

Access Lists

-

Named access-lists are configured using one of the commands: ip access-list standard name ip access-list extended name

-

Subsequent lines prefixed with permit or deny define the body of the access-list. Standard access-list syntax:

-

{permit|deny} {host|source source-wildcard|any} [{host|destination destination-wildcard|any}]

+

Named access-lists are configured using one of the commands: ip +access-list standard name ip access-list extended name

+

Subsequent lines prefixed with permit or +deny define the body of the access-list. Standard +access-list syntax:

+

{permit|deny} {host|source +source-wildcard|any} [{host|destination +destination-wildcard|any}]

Extended access-lists:

-

{permit|deny} ip {host|source source-wildcard|any} {host|destination destination-wildcard|any} [fragments]

-

{permit|deny} udp {host|source source-wildcard|any} [{eq|neq|gt|lt} port|range from to] {host|destination destination-wildcard|any} [{eq|neq|gt|lt} port|range from to] [fragments]

-

{permit|deny} tcp {host|source source-wildcard|any} [{eq|neq|gt|lt} port|range from to] {host|destination destination-wildcard|any} [{eq|neq|gt|lt} port|range from to] [{established|{match-any|match-all} {+|-}{fin|syn|rst|psh|ack|urg} ...|fragments]

+

{permit|deny} ip {host|source +source-wildcard|any} {host|destination +destination-wildcard|any} [fragments]

+

{permit|deny} udp {host|source +source-wildcard|any} +[{eq|neq|gt|lt} +port|range from to] {host|destination +destination-wildcard|any} +[{eq|neq|gt|lt} +port|range from to] [fragments]

+

{permit|deny} tcp {host|source +source-wildcard|any} +[{eq|neq|gt|lt} +port|range from to] {host|destination +destination-wildcard|any} +[{eq|neq|gt|lt} +port|range from to] +[{established|{match-any|match-all} +{+|-}{fin|syn|rst|psh|ack|urg} +...|fragments]

users

-

Usernames and passwords for the command-line interface are stored in this file. The format is username:password where password may either by plain text, an MD5 digest (prefixed by $1salt$) or a DES password, distinguished from plain text by the prefix {crypt}.

-

The username enable has a special meaning and is used to set the enable password.

+

Usernames and passwords for the command-line interface are stored in +this file. The format is username:password where password may either by +plain text, an MD5 digest (prefixed by +$1salt$) or a DES password, distinguished from +plain text by the prefix {crypt}.

+

The username enable has a special meaning and is used to +set the enable password.

-

If this file doesn't exist, then anyone who can get to port 23 will be allowed access without a username or password.

+

If this file doesn't exist, then anyone who can get to port 23 will +be allowed access without a username or password.

ip_pool

-

This file is used to configure the IP address pool which user addresses are assigned from. This file should contain either an IP address or a CIDR network per line. e.g.:

+

This file is used to configure the IP address pool which user +addresses are assigned from. This file should contain either an IP +address or a CIDR network per line. e.g.:

192.168.1.1
 192.168.1.2
 192.168.1.3
 192.168.4.0/24
 172.16.0.0/16
 10.0.0.0/8
-

Keep in mind that l2tpns can only handle 65535 connections per process, so don't put more than 65535 IP addresses in the configuration file. They will be wasted.

+

Keep in mind that l2tpns can only handle 65535 +connections per process, so don't put more than 65535 IP addresses in +the configuration file. They will be wasted.

build-garden

-

The garden plugin on startup creates a NAT table called "garden" then sources the build-garden script to populate that table. All packets from gardened users will be sent through this table. Example:

+

The garden plugin on startup creates a NAT table called "garden" then +sources the build-garden script to populate that table. All +packets from gardened users will be sent through this table. +Example:

iptables -t nat -A garden -p tcp -m tcp --dport 25 -j DNAT --to 192.168.1.1
 iptables -t nat -A garden -p udp -m udp --dport 53 -j DNAT --to 192.168.1.1
 iptables -t nat -A garden -p tcp -m tcp --dport 53 -j DNAT --to 192.168.1.1
@@ -204,17 +406,33 @@ iptables -t nat -A garden -p icmp -m icmp --icmp-type echo-request -j DNAT --to
 iptables -t nat -A garden -p icmp -j ACCEPT
 iptables -t nat -A garden -j DROP

Operation

-

A running l2tpns process can be controlled in a number of ways. The primary method of control is by the Command-Line Interface (CLI).

-

You can also remotely send commands to modules via the nsctl client provided.

-

There are also a number of signals that l2tpns understands and takes action when it receives them.

+

A running l2tpns process can be controlled in a number of ways. The +primary method of control is by the Command-Line Interface (CLI).

+

You can also remotely send commands to modules via the +nsctl client provided.

+

There are also a number of signals that l2tpns understands and takes +action when it receives them.

Command-Line Interface

-

You can access the command line interface by telneting to port 23. There is no IP address restriction, so it's a good idea to firewall this port off from anyone who doesn't need access to it. See for information on restricting access based on a username and password.

-

The CLI gives you real-time control over almost everything in the process. The interface is designed to look like a Cisco device, and supports things like command history, line editing and context sensitive help. This is provided by linking with the libcli library. Some general documentation of the interface is here.

-

After you have connected to the telnet port (and perhaps logged in), you will be presented with a hostname> prompt.

-

Enter help to get a list of possible commands, or press ? for context-specific help.

+

You can access the command line interface by telneting to port 23. +There is no IP address restriction, so it's a good idea to firewall this +port off from anyone who doesn't need access to it. See for information on restricting access based on +a username and password.

+

The CLI gives you real-time control over almost everything in the +process. The interface is designed to look like a Cisco device, and +supports things like command history, line editing and context sensitive +help. This is provided by linking with the libcli library. Some +general documentation of the interface is here.

+

After you have connected to the telnet port (and perhaps logged in), +you will be presented with a hostname> prompt.

+

Enter help to get a list of possible commands, or press +? for context-specific help.

A brief overview of the more important commands follows:

show session [ID]

-

: Detailed information for a specific session is presented if you specify a session ID argument.

+

: Detailed information for a specific session is presented if you +specify a session ID argument.

If no ID is given, a summary of all connected sessions is produced.
 Note that this summary list can be around 185 columns wide, so you
 should probably use a wide terminal.
@@ -238,10 +456,14 @@ The columns listed in the summary are:
   `CLI`          The Calling-Line-Identification field provided during the session setup. This field is generated by the LAC.   
   -------------- -------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------

show users; show user username

-

: With no arguments, display a list of currently connected users. If an argument is given, the session details for the given username are displayed.

+

: With no arguments, display a list of currently connected users. If +an argument is given, the session details for the given username are +displayed.

show tunnel [ID]
-

Produce a summary list of all open tunnels, or detail on a specific tunnel ID.

+
+

Produce a summary list of all open tunnels, or detail on a specific +tunnel ID.

The columns listed in the summary are:

@@ -251,7 +473,8 @@ The columns listed in the summary are: - + @@ -259,68 +482,102 @@ The columns listed in the summary are: - + - +
HostnameThe hostname for the tunnel as provided by the LAC. This has no relation to DNS, it is just a text field.The hostname for the tunnel as provided by +the LAC. This has no relation to DNS, it is just a text field.
IP
StateTunnel state: Free, Open, Dieing, OpeningTunnel state: Free, Open, Dieing, +Opening
SessionsThe number of open sessions on the tunnelThe number of open sessions on the +tunnel
show pool
-

Displays the current IP address pool allocation. This will only display addresses that are in use, or are reserved for re-allocation to a disconnected user.

-

If an address is not currently in use, but has been used, then in the User column the username will be shown in square brackets, followed by the time since the address was used:

+
+

Displays the current IP address pool allocation. This will only +display addresses that are in use, or are reserved for re-allocation to +a disconnected user.

+

If an address is not currently in use, but has been used, then in the +User column the username will be shown in square brackets, followed by +the time since the address was used:

IP Address      Used  Session User
 192.168.100.6     N           [joe.user] 1548s
show radius
-

Show a summary of the in-use RADIUS sessions. This list should not be very long, as RADIUS sessions should be cleaned up as soon as they are used. The columns listed are:

+
+

Show a summary of the in-use RADIUS sessions. This list should not be +very long, as RADIUS sessions should be cleaned up as soon as they are +used. The columns listed are:

- + - + - + - + - +
RadiusThe ID of the RADIUS request. This is sent in the packet to the RADIUS server for identificationThe ID of the RADIUS request. This is sent +in the packet to the RADIUS server for identification
StateThe state of the request: WAIT, CHAP, AUTH, IPCP, START, STOP or NULLThe state of the request: WAIT, CHAP, +AUTH, IPCP, START, STOP or NULL
SessionThe session ID that this RADIUS request is associated withThe session ID that this RADIUS request is +associated with
RetryIf a response does not appear to the request, it will retry at this time. This is a Unix timestampIf a response does not appear to the +request, it will retry at this time. This is a Unix timestamp
TryRetry count. The RADIUS request is discarded after 3 retriesRetry count. The RADIUS request is +discarded after 3 retries
show running-config
-

This will list the current running configuration. This is in a format that can either be pasted into the configuration file, or run directly at the command line.

+
+

This will list the current running configuration. This is in a format +that can either be pasted into the configuration file, or run directly +at the command line.

show counters
-

Internally, counters are kept of key values, such as bytes and packets transferred, as well as function call counters. This function displays all these counters, and is probably only useful for debugging.

-

You can reset these counters by running clear counters.

+
+

Internally, counters are kept of key values, such as bytes and +packets transferred, as well as function call counters. This function +displays all these counters, and is probably only useful for +debugging.

+

You can reset these counters by running +clear counters.

show cluster
-

Show cluster status. Shows the cluster state for this server (Master/Slave), information about known peers and (for slaves) the master IP address, last packet seen and up-to-date status. See Clustering for more information.

+
+

Show cluster status. Shows the cluster state for this server +(Master/Slave), information about known peers and (for slaves) the +master IP address, last packet seen and up-to-date status. See Clustering for more information.

write memory
-

This will write the current running configuration to the config file startup-config, which will be run on a restart.

+
+

This will write the current running configuration to the config file +startup-config, which will be run on a restart.

snoop user IP port

-

: You must specify a username, IP address and port. All packets for the current session for that username will be forwarded to the given host/port. Specify no snoop username to disable interception for the session.

+

: You must specify a username, IP address and port. All packets for +the current session for that username will be forwarded to the given +host/port. Specify no snoop username to disable +interception for the session.

If you want interception to be permanent, you will have to modify
 the RADIUS response for the user. See [Interception](#interception).

throttle user [in|out] rate

-

: You must specify a username, which will be throttled for the current session to rate Kbps. Prefix rate with in or out to set different upstream and downstream rates.

+

: You must specify a username, which will be throttled for the +current session to rate Kbps. Prefix rate with in or +out to set different upstream and downstream rates.

Specify `no throttle
         username` to disable throttling for the current session.
 
@@ -328,13 +585,18 @@ If you want throttling to be permanent, you will have to modify the
 RADIUS response for the user. See [Throttling](#throttling).
drop session
-

This will cleanly disconnect the session specified by session ID.

+
+

This will cleanly disconnect the session specified by session ID.

drop tunnel
-

This will cleanly disconnect the tunnel specified by tunnel ID, as well as all sessions on that tunnel.

+
+

This will cleanly disconnect the tunnel specified by tunnel ID, as +well as all sessions on that tunnel.

uptime
-

This will show how long the l2tpns process has been running, and the current bandwidth utilization:

+
+

This will show how long the l2tpns process has been +running, and the current bandwidth utilization:

17:10:35 up 8 days, 2212 users, load average: 0.21, 0.17, 0.16
 Bandwidth: UDP-ETH:6/6  ETH-UDP:13/13  TOTAL:37.6   IN:3033 OUT:2569

The bandwidth line contains 4 sets of values:

@@ -342,85 +604,123 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 UDP-ETH -The current bandwidth going from the LAC to the ethernet (user uploads), in mbits/sec. +The current bandwidth going from the LAC +to the ethernet (user uploads), in mbits/sec. ETH-UDP -The current bandwidth going from ethernet to the LAC (user downloads). +The current bandwidth going from ethernet +to the LAC (user downloads). TOTAL -The total aggregate bandwidth in mbits/s. +The total aggregate bandwidth in +mbits/s. IN and OUT -Packets/per-second going between UDP-ETH and ETH-UDP. +Packets/per-second going between UDP-ETH +and ETH-UDP.

These counters are updated every second.

configure terminal
-

Enter configuration mode. Use exit or ^Z to exit this mode.

+
+

Enter configuration mode. Use exit or ^Z to +exit this mode.

The following commands are valid in this mode:

load plugin name

-

: Load a plugin. You must specify the plugin name, and it will search in /usr/lib/l2tpns for name.so. You can unload a loaded plugin with remove plugin name.

+

: Load a plugin. You must specify the plugin name, and it will search +in /usr/lib/l2tpns for name.so. You can unload +a loaded plugin with +remove plugin name.

set ...
-

Set a configuration variable. You must specify the variable name, and the value. If the value contains any spaces, you should quote the value with double (") or single (') quotes.

-

You can set any configuration value in this way, although some may require a restart to take effect. See .

+
+

Set a configuration variable. You must specify the variable name, and +the value. If the value contains any spaces, you should quote the value +with double (") or single (') quotes.

+

You can set any configuration value in this way, although some may +require a restart to take effect. See .

router bgp ...
-

Configure BGP. See BGP.

+
+

Configure BGP. See BGP.

ip access-list ...
-

Configure a named access list. See Access Lists.

+
+

Configure a named access list. See Access Lists.

nsctl

-

nsctl sends messages to a running l2tpns instance to be control plugins.

-

Arguments are command and optional args. See nsctl(8).

-

Built-in command are load_plugin, unload_plugin and help. Any other commands are passed to plugins for processing by the plugin_control function.

+

nsctl sends messages to a running l2tpns +instance to be control plugins.

+

Arguments are command and optional args. See +nsctl(8).

+

Built-in command are load_plugin, +unload_plugin and help. Any other commands are +passed to plugins for processing by the plugin_control +function.

Signals

-

While the process is running, you can send it a few different signals, using the kill command.

+

While the process is running, you can send it a few different +signals, using the kill command.

killall -HUP l2tpns

The signals understood are:

SIGHUP
-

Reload the config from disk and re-open log file.

+
+

Reload the config from disk and re-open log file.

SIGTERM; SIGINT
-

Stop process. Tunnels and sessions are not terminated. This signal should be used to stop l2tpns on a cluster node where there are other machines to continue handling traffic. See Clustering

+
+

Stop process. Tunnels and sessions are not terminated. This signal +should be used to stop l2tpns on a cluster node where there +are other machines to continue handling traffic. See Clustering

SIGQUIT
-

Shut down tunnels and sessions, exit process when complete.

+
+

Shut down tunnels and sessions, exit process when complete.

Throttling

-

l2tpns contains support for slowing down user sessions to whatever speed you desire. The global setting throttle_speed defines the default throttle rate.

-

To throttle a sesion permanently, add a Cisco-AVPair RADIUS attribute. The autothrotle module interprets the following attributes:

+

l2tpns contains support for slowing down user sessions +to whatever speed you desire. The global setting +throttle_speed defines the default throttle rate.

+

To throttle a sesion permanently, add a Cisco-AVPair +RADIUS attribute. The autothrotle module interprets the +following attributes:

- + - + - - + + - + @@ -429,25 +729,54 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569
throttle=yesThrottle upstream/downstream traffic to the configured throttle_speed.Throttle upstream/downstream traffic to +the configured throttle_speed.
throttle=rateThrottle upstream/downstream traffic to the specified rate Kbps.Throttle upstream/downstream traffic to +the specified rate Kbps.
`lcp:interface-config#1=service-policy inputAlternate (Cisco) format: throttle upstream/downstream to specified rate Kbps.`lcp:interface-config#1=service-policy +inputAlternate (Cisco) format: throttle +upstream/downstream to specified rate Kbps.
rate`
`lcp:interface-config#2=service-policy output`lcp:interface-config#2=service-policy +output
-

You can also enable and disable throttling an active session using the throttle CLI command.

+

You can also enable and disable throttling an active session using +the throttle CLI command.

Interception

-

You may have to deal with legal requirements to be able to intercept a user's traffic at any time. l2tpns allows you to begin and end interception on the fly, as well as at authentication time.

-

When a user is being intercepted, a copy of every packet they send and receive will be sent wrapped in a UDP packet to a specified host.

-

The UDP packet contains just the raw IP frame, with no extra headers. The script scripts/l2tpns-capture may be used as the end-point for such intercepts, writing the data in PCAP format (suitable for inspection with tcpdump).

-

To enable or disable interception of a connected user, use the snoop and no snoop CLI commands. These will enable interception immediately.

-

If you wish the user to be intercepted whenever they reconnect, you will need to modify the RADIUS response to include the Vendor-Specific value Cisco-AVPair="intercept=ip:port". For this feature to be enabled, you need to have the autosnoop module loaded.

+

You may have to deal with legal requirements to be able to intercept +a user's traffic at any time. l2tpns allows you to begin +and end interception on the fly, as well as at authentication time.

+

When a user is being intercepted, a copy of every packet they send +and receive will be sent wrapped in a UDP packet to a specified +host.

+

The UDP packet contains just the raw IP frame, with no extra headers. +The script scripts/l2tpns-capture may be used as the +end-point for such intercepts, writing the data in PCAP format (suitable +for inspection with tcpdump).

+

To enable or disable interception of a connected user, use the snoop and no snoop +CLI commands. These will enable interception immediately.

+

If you wish the user to be intercepted whenever they reconnect, you +will need to modify the RADIUS response to include the Vendor-Specific +value Cisco-AVPair="intercept=ip:port". For this feature to +be enabled, you need to have the autosnoop module +loaded.

Plugins

-

So as to make l2tpns as flexible as possible, a plugin API is include which you can use to hook into certain events.

-

There are a some standard modules included which may be used as examples: autosnoop, autothrottle, garden, sessionctl, setrxspeed, snoopctl, stripdomain and throttlectl.

-

When an event occurs that has a hook, l2tpns looks for a predefined function name in every loaded module, and runs them in the order the modules were loaded.

-

The function should return PLUGIN_RET_OK if it is all OK. If it returns PLUGIN_RET_STOP, then it is assumed to have worked, but that no further modules should be run for this event.

-

A return of PLUGIN_RET_ERROR means that this module failed, and no further processing should be done for this event.

+

So as to make l2tpns as flexible as possible, a plugin +API is include which you can use to hook into certain events.

+

There are a some standard modules included which may be used as +examples: autosnoop, autothrottle, +garden, sessionctl, setrxspeed, +snoopctl, stripdomain and +throttlectl.

+

When an event occurs that has a hook, l2tpns looks for a +predefined function name in every loaded module, and runs them in the +order the modules were loaded.

+

The function should return PLUGIN_RET_OK if it is all +OK. If it returns PLUGIN_RET_STOP, then it is assumed to +have worked, but that no further modules should be run for this +event.

+

A return of PLUGIN_RET_ERROR means that this module +failed, and no further processing should be done for this event.

Use this with care.

-

Most event functions take a specific structure named param_event, which varies in content with each event. The function name for each event will be plugin_event, so for the event timer, the function declaration should look like:

+

Most event functions take a specific structure named +param_event, which varies in content with each event. The +function name for each event will be plugin_event, so for +the event timer, the function declaration should look like:

int plugin_timer(struct param_timer *data);
-

A list of the available events follows, with a list of all the fields in the supplied structure:

+

A list of the available events follows, with a list of all the fields +in the supplied structure:

@@ -464,20 +793,25 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - - + - + @@ -487,7 +821,9 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -512,7 +848,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -522,7 +859,9 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -542,12 +881,15 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + - + @@ -562,7 +904,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -577,7 +920,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -592,8 +936,11 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - @@ -615,17 +962,22 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + - + - + @@ -650,7 +1002,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -665,7 +1018,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -680,7 +1034,8 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569 - + @@ -706,28 +1061,76 @@ Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569
plugin_init

Called when the plugin is loaded. A pointer to a struct containing function pointers is passed as the only argument, allowing the plugin to call back into the main code.

-

Prior to loading the plugin, l2tpns checks the API version the plugin was compiled against. All plugins should contain:

+

Called when the plugin is loaded. A pointer to a struct +containing function pointers is passed as the only argument, allowing +the plugin to call back into the main code.

+

Prior to loading the plugin, l2tpns checks the API +version the plugin was compiled against. All plugins should contain:

int

plugin_api_version = PLUGIN_API_VERSION;

 s truct pluginfuncs *
See pluginfuncs structure in plugin.h for available functions.See pluginfuncs structure in plugin.h for +available functions.
plugin_doneCalled when the plugin is unloaded or l2tpns is shutdown.Called when the plugin is unloaded or l2tpns is +shutdown. void
plugin_pre_authCalled after a RADIUS response has been received, but before it has been processed by the code. This will allow you to modify the response in some way.Called after a RADIUS response has been received, but before it has +been processed by the code. This will allow you to modify the response +in some way. struct plug in param_pre_auth *
int protocolAuthentication protocol: 0xC023 for PAP, 0xC223 for CHAP.Authentication protocol: 0xC023 for PAP, +0xC223 for CHAP.
plugin_post_authCalled after a RADIUS response has been received, and the basic checks have been performed. This is what the garden module uses to force authentication to be accepted.Called after a RADIUS response has been received, and the basic +checks have been performed. This is what the garden module +uses to force authentication to be accepted. struct plugi n param_post_auth *
short auth_allowedInitially true or false depending on whether authentication has been allowed so far. You can set this to 1 or 0 to force authentication to be accepted or rejected.Initially true or false depending on whether authentication has been +allowed so far. You can set this to 1 or 0 to force authentication to be +accepted or rejected.
int protocolAuthentication protocol: 0xC023 for PAP, 0xC223 for CHAP.Authentication protocol: 0xC023 for PAP, +0xC223 for CHAP.
plugin_new_sessionCalled after a session is fully set up. The session is now ready to handle traffic.Called after a session is fully set up. The session is now ready to +handle traffic. struct plugin param_new_session *
plugin_kill_sessionCalled when a session is about to be shut down. This may be called multiple times for the same session.Called when a session is about to be shut down. This may be called +multiple times for the same session. struct plugin p aram_kill_session *
plugin_control

Called in whenever a nsctl packet is received. This should handle the packet and form a response if required.

-

Plugin-specific help strings may be included in the output of nsctl help by defining a NULL terminated list of strings as follows:

+

Called in whenever a nsctl packet is received. This +should handle the packet and form a response if required.

+

Plugin-specific help strings may be included in the output of +nsctl help by defining a NULL terminated list +of strings as follows:

char

*plugin_control_hel p[] = { …, NULL };

 struct plu gin param_control *
int responseResponse from control message (if handled): should be either NSCTL_RES_OK or NSCTL_RES_ERR.Response from control message (if handled): should be either +NSCTL_RES_OK or NSCTL_RES_ERR.
char *additionalAdditional information, output by nsctl on receiving the response.Additional information, output by nsctl on receiving +the response.
plu gin_radius_responseCalled whenever a RADIUS response includes a Cisco-AVPair value. The value is split into key=value pairs. Will be called once for each pair in the response.Called whenever a RADIUS response includes a +Cisco-AVPair value. The value is split into +key=value pairs. Will be called once for each pair in the +response. struct plugin para m_radius_response *
plugin_radius_resetCalled whenever a RADIUS CoA request is received to reset any options to default values before the new values are applied.Called whenever a RADIUS CoA request is received to reset any +options to default values before the new values are applied. struct p aram_radius_reset *
pl ugin_radius_accountCalled when preparing a RADIUS accounting record to allow additional data to be added to the packet.Called when preparing a RADIUS accounting record to allow additional +data to be added to the packet. struct par am_radius_account *
uint8_t **packetPointer to the end of the currently assembled packet buffer. The value should be incremented by the length of any data added.Pointer to the end of the currently assembled packet buffer. The +value should be incremented by the length of any data added.

Walled Garden

-

A "Walled Garden" is implemented so that you can provide perhaps limited service to sessions that incorrectly authenticate.

-

Whenever a session provides incorrect authentication, and the RADIUS server responds with Auth-Reject, the walled garden module (if loaded) will force authentication to succeed, but set the walled_garden flag in the session structure, and adds an iptables rule to the garden_users chain to cause all packets for the session to traverse the garden chain.

-

This doesn't just work. To set this all up, you will to setup the garden nat table with the build-garden script with rules to limit user's traffic.

-

For example, to force all traffic except DNS to be forwarded to 192.168.1.1, add these entries to your build-garden script:

+

A "Walled Garden" is implemented so that you can provide perhaps +limited service to sessions that incorrectly authenticate.

+

Whenever a session provides incorrect authentication, and the RADIUS +server responds with Auth-Reject, the walled garden module (if loaded) +will force authentication to succeed, but set the +walled_garden flag in the session structure, and adds an +iptables rule to the garden_users chain to +cause all packets for the session to traverse the garden +chain.

+

This doesn't just work. To set this all up, you will to +setup the garden nat table with the build-garden script with rules to limit +user's traffic.

+

For example, to force all traffic except DNS to be forwarded to +192.168.1.1, add these entries to your build-garden +script:

iptables -t nat -A garden -p tcp --dport ! 53 -j DNAT --to 192.168.1.1
 iptables -t nat -A garden -p udp --dport ! 53 -j DNAT --to 192.168.1.1
-

l2tpns will add entries to the garden_users chain as appropriate.

-

You can check the amount of traffic being captured using the following command:

+

l2tpns will add entries to the garden_users +chain as appropriate.

+

You can check the amount of traffic being captured using the +following command:

iptables -t nat -L garden -nvx

Filtering

-

Sessions may be filtered by specifying Filter-Id attributes in the RADIUS reply. filter.in specifies that the named access-list filter should be applied to traffic from the customer, filter.out specifies a list for traffic to the customer.

+

Sessions may be filtered by specifying Filter-Id +attributes in the RADIUS reply. filter.in specifies that +the named access-list filter should be applied to traffic from the +customer, filter.out specifies a list for traffic to the +customer.

Clustering

-

An l2tpns cluster consists of one* or more servers configured with the same configuration, notably the multicast cluster_address and the cluster_port

+

An l2tpns cluster consists of one* or more servers +configured with the same configuration, notably the multicast +cluster_address and the cluster_port

*A stand-alone server is simply a degraded cluster.

-

Initially servers come up as cluster slaves, and periodically (every cluster_hb_interval/10 seconds) send out ping packets containing the start time of the process to the multicast cluster_address on cluster_port.

-

A cluster master sends heartbeat rather than ping packets, which contain those session and tunnel changes since the last heartbeat.

-

When a slave has not seen a heartbeat within cluster_hb_timeout/10 seconds it "elects" a new master by examining the list of peers it has seen pings from and determines which of these and itself is the "best" candidate to be master. "Best" in this context means the server with the highest uptime (the highest IP address is used as a tie-breaker in the case of equal uptimes).

-

After discovering a master, and determining that it is up-to-date (has seen an update for all in-use sessions and tunnels from heartbeat packets) will raise a route (see Routing) for the bind_address and for all addresses/networks in ip_pool.

-

Any packets recieved by the slave which would alter the session state, as well as packets for throttled or gardened sessions are forwarded to the master for handling. In addition, byte counters for session traffic are periodically forwarded.

-

The master, when determining that it has at least one* up-to-date slave will drop all routes (raising them again if all slaves disappear) and subsequently handle only packets forwarded to it by the slaves.

+

Initially servers come up as cluster slaves, and periodically (every +cluster_hb_interval/10 seconds) send out ping packets +containing the start time of the process to the multicast +cluster_address on cluster_port.

+

A cluster master sends heartbeat rather than ping packets, which +contain those session and tunnel changes since the last heartbeat.

+

When a slave has not seen a heartbeat within +cluster_hb_timeout/10 seconds it "elects" a new master by +examining the list of peers it has seen pings from and determines which +of these and itself is the "best" candidate to be master. "Best" in this +context means the server with the highest uptime (the highest IP address +is used as a tie-breaker in the case of equal uptimes).

+

After discovering a master, and determining that it is up-to-date +(has seen an update for all in-use sessions and tunnels from heartbeat +packets) will raise a route (see Routing) for the +bind_address and for all addresses/networks in +ip_pool.

+

Any packets recieved by the slave which would alter the session +state, as well as packets for throttled or gardened sessions are +forwarded to the master for handling. In addition, byte counters for +session traffic are periodically forwarded.

+

The master, when determining that it has at least one* up-to-date +slave will drop all routes (raising them again if all slaves disappear) +and subsequently handle only packets forwarded to it by the slaves.

*Configurable with cluster_master_min_adv

-

Multiple clusters can be run on the same network by just using different multicast cluster_address. However, for a given host to be part of multiple clusters without mixing the clusters, cluster_port must be different for each cluster.

+

Multiple clusters can be run on the same network by just using +different multicast cluster_address. However, for a given +host to be part of multiple clusters without mixing the clusters, +cluster_port must be different for each cluster.

Routing

-

If you are running a single instance, you may simply statically route the IP pools to the bind_address (l2tpns will send a gratuitous arp).

-

For a cluster, configure the members as BGP neighbours on your router and configure multi-path load-balancing. Cisco uses maximum-paths ibgp for IBGP. If this is not supported by your IOS revision, you can use maximum-paths (which works for EBGP) and set as_number to a private value such as 64512.

+

If you are running a single instance, you may simply statically route +the IP pools to the bind_address (l2tpns will +send a gratuitous arp).

+

For a cluster, configure the members as BGP neighbours on your router +and configure multi-path load-balancing. Cisco uses +maximum-paths ibgp for IBGP. If this is not supported by +your IOS revision, you can use maximum-paths (which works +for EBGP) and set as_number to a private value such as +64512.

diff --git a/docs/html/practical-vpns.html b/docs/html/practical-vpns.html index 6b0af2b..03c1e03 100644 --- a/docs/html/practical-vpns.html +++ b/docs/html/practical-vpns.html @@ -1,54 +1,95 @@

Overview of VPNs and IPsec

Virtual Private Networks

-

The purpose of a VPN is to create a secure channel ontop of an un-secure medium, where a computer or a device are put in each end-point in order to establish communication, each of these end-points are often reffered to as Point of Presense, or POP. This kind of a communication allows the capability of creating a Virtual Private Network, which is accesable over a medium such as the Internet and thus, extend the physical boundaries of an existing local network.

+

The purpose of a VPN is to create a secure channel ontop of an +un-secure medium, where a computer or a device are put in each end-point +in order to establish communication, each of these end-points are often +reffered to as Point of Presense, or POP. This kind of a communication +allows the capability of creating a Virtual Private Network, which is +accesable over a medium such as the Internet and thus, extend the +physical boundaries of an existing local network.

VPNs have three forms:

Site-To-Site VPNs
-

these setups exist in order to extend the local network to create a much bigger LAN over the Internet.

+
+

these setups exist in order to extend the local network to create a +much bigger LAN over the Internet.

Network-To-Host or Remote access VPNs
-

where a central VPN server is able to achieve multiple connections, often reffered to as RoadWarrior VPNs. (This setup is very common among ISPs)

+
+

where a central VPN server is able to achieve multiple connections, +often reffered to as RoadWarrior VPNs. (This setup is very common among +ISPs)

Network-To-Network
-

extranet VPNs allow secure connections within branches and business partners, they are an extension of a Site-To-Site VPNs.

+
+

extranet VPNs allow secure connections within branches and business +partners, they are an extension of a Site-To-Site VPNs.

site to site
shows a Site-To-Site VPN diagram.

-

IP/VPNs are connections which are based upon IP tunnels. A tunnel is a way to encapsulate an IP packet inside another IP packet or some other type of packet. Why do we need tunneling? A Virtual Private Network is identified by IANA's private IP assignments and so such packet can not go beyond the uplink Internet interface.

-

tunneling process
+

IP/VPNs are connections which are based upon IP tunnels. A tunnel is +a way to encapsulate an IP packet inside another IP packet or some other +type of packet. Why do we need tunneling? A Virtual Private Network is +identified by IANA's private IP assignments and so such packet can not +go beyond the uplink Internet interface.

+


shows the tunneling process.

Several tunneling protocols are available for manifesting VPNs.

L2F
-

Layer 2 Forwarding, an older implementation which assume position at the link layer of the OSI. It has no encryption capabilities and hence, deprecated.

+
+

Layer 2 Forwarding, an older implementation which assume position at +the link layer of the OSI. It has no encryption capabilities and hence, +deprecated.

L2TP
-

Layer 2 Tunneling Protocol, still no encryption capabilities.

+
+

Layer 2 Tunneling Protocol, still no encryption capabilities.

PPTP
-

Point-to-Point Tunneling Protocol, and yet again, no encryption.

+
+

Point-to-Point Tunneling Protocol, and yet again, no encryption.

-

As seen, the requirement of encryption enhancement is urgent in order to assure authentication, data integrity and privacy. IPsec solves this by providing a suite of security measures implemented at layer 3.

+

As seen, the requirement of encryption enhancement is urgent in order +to assure authentication, data integrity and privacy. IPsec solves this +by providing a suite of security measures implemented at layer 3.

IP Security Suite (IPsec)

-

VPN Security is now appearing, this complex things. How so? VPN tunnels by themselves are easily maintained by single-standalone tools like pppd, l2tpns, stunnel and others. Involving security with VPNs though requires more:

+

VPN Security is now appearing, this complex things. How so? VPN +tunnels by themselves are easily maintained by single-standalone tools +like pppd, l2tpns, stunnel and others. Involving security with VPNs +though requires more:

-

Keys are secrets being shared by two end-points to provide a secure mean of communication against a third-party connection from sniffing the actual data.

+

Keys are secrets being shared by two end-points to provide a secure +mean of communication against a third-party connection from sniffing the +actual data.

-

Different ways to handle key management include RADIUS (Remote Authentication Dial In User Service) systems which provide AAA (Authentication, Authorization and Accounting). Another solution is ISAKMP/Oackly - Internet Security Association and Key Management Protocol. This solution requires you to posess one of the following:

+

Different ways to handle key management include RADIUS (Remote +Authentication Dial In User Service) systems which provide AAA +(Authentication, Authorization and Accounting). Another solution is +ISAKMP/Oackly - Internet Security Association and Key Management +Protocol. This solution requires you to posess one of the following:

-

The more requirements you meet the more secure is the medium, once established. Let's review, something we have is like a certificate, it proves who we are. Something we know, is a key, a secret password which we were told in a whisper, and something we are is our-fingerprint which identifies ourselves from other individuals.

+

The more requirements you meet the more secure is the medium, once +established. Let's review, something we have is like a certificate, it +proves who we are. Something we know, is a key, a secret password which +we were told in a whisper, and something we are is our-fingerprint which +identifies ourselves from other individuals.

IPsec in Depth

-

IPsec consists of two main protocols, an Authentication Header and Encapsulation Security Payload, also known as AH and ESP. Although it is not bound to these and can be extended (and often is) to other standarts such as

+

IPsec consists of two main protocols, an Authentication Header and +Encapsulation Security Payload, also known as AH and ESP. Although it is +not bound to these and can be extended (and often is) to other standarts +such as

-

We'll be deploying an IKE daemon to handle the key management, which uses the Diffie- Hellman cryptography protocol in order to allow two parties to establish a connection based upon a shared secret key that both parties posess. (Authentication within IKE is handled by MD5 hashing)

-

IKE is responsible for authentication of two IPsec parties, negotiation of keys for encryption algorithms and security associations. This process is commonly regarded as two phases:

+

We'll be deploying an IKE daemon to handle the key management, which +uses the Diffie- Hellman cryptography protocol in order to allow two +parties to establish a connection based upon a shared secret key that +both parties posess. (Authentication within IKE is handled by MD5 +hashing)

+

IKE is responsible for authentication of two IPsec parties, +negotiation of keys for encryption algorithms and security associations. +This process is commonly regarded as two phases:

Phase 1: IKE Security Association
-

The IKE daemon authenticates against the peers in order to achieve a secure channel, according to the Diffie-Hellman key agreement.

+
+

The IKE daemon authenticates against the peers in order to achieve a +secure channel, according to the Diffie-Hellman key agreement.

Phase 2: IKE IPsec Negotiation
-

After achieving an authenticated channel, the parties now negotiate a secure transform (the way to encrypt and secure the medium) where the sender is offering his/hers transform set after which the receiver decides upon one. An IPsec session can now safely begin.

+
+

After achieving an authenticated channel, the parties now negotiate a +secure transform (the way to encrypt and secure the medium) where the +sender is offering his/hers transform set after which the receiver +decides upon one. An IPsec session can now safely begin.

-

Just to be clear, a Security Association is an agreed relation between two parties which describes how they will use security services (from IPsec) to communicate.

+

Just to be clear, a Security Association is an agreed relation +between two parties which describes how they will use security services +(from IPsec) to communicate.

IPsec Modes

IPsec can operate in two different modes:

Transport mode
-

takes place when two devices (like a station and a gateway (now considered a host)) are establishing a connection which upon they both support IPsec.

+
+

takes place when two devices (like a station and a gateway (now +considered a host)) are establishing a connection which upon they both +support IPsec.

Tunnel mode
-

we require tunnel mode when we proxy IPsec connetions between two stations behind the IPsec gateway. For example, in a Site-to-Site VPN a tunnel mode lives, since it exists in order to provide the stations behind these gateways runing the VPN/IPsec to communicate securely. In this situation, both end-points are runing an IPsec software.

+
+

we require tunnel mode when we proxy IPsec connetions between two +stations behind the IPsec gateway. For example, in a Site-to-Site VPN a +tunnel mode lives, since it exists in order to provide the stations +behind these gateways runing the VPN/IPsec to communicate securely. In +this situation, both end-points are runing an IPsec software.

-

In definition, a tunnel mode IPsec is better secured than transport. Without going too deep into the ins-and-outs of the technical side, transport mode doesn't encapsulate the actual IP layer but only the tcp/udp (Transport layer of the OSI) where-as a tunnel mode encapsulate both the Transport layer and the IP layer into a new IP packet.

-

To summarize, we need VPNs for data-exchange methods and a set of IPsec tools for security reasons.

+

In definition, a tunnel mode IPsec is better secured than transport. +Without going too deep into the ins-and-outs of the technical side, +transport mode doesn't encapsulate the actual IP layer but only the +tcp/udp (Transport layer of the OSI) where-as a tunnel mode encapsulate +both the Transport layer and the IP layer into a new IP packet.

+

To summarize, we need VPNs for data-exchange methods and a set of +IPsec tools for security reasons.

VPN Deployment

I've assembled another diagram to view the actual VPN setup.
vpn deployment
-gives a general description of how the network will be layed out in real-world scenario.

-

We notice that a single Linux box is acting as a Gateway and has all the services included with it. This is a bad idea from a security prespective but it's easy to just deploy the FreeRADIUS and MySQL servers on another machine. Of course the L2TPns and the rest of the IPsec tools suite would have to remain on the Gateway box (not necessarily the Firewall).

+gives a general description of how the network will be layed out in +real-world scenario.

+

We notice that a single Linux box is acting as a Gateway and has all +the services included with it. This is a bad idea from a security +prespective but it's easy to just deploy the FreeRADIUS and MySQL +servers on another machine. Of course the L2TPns and the rest of the +IPsec tools suite would have to remain on the Gateway box (not +necessarily the Firewall).

vpn process
-attempts to explain the actual process that the VPN takes and to detail the place that each of that application-in-charge takes place.

+attempts to explain the actual process that the VPN takes and to detail +the place that each of that application-in-charge takes place.

Requirements

The Toolbox

-

Following is a description of the requirements you will have to meet:

+

Following is a description of the requirements you will have to +meet:

A Linux box
-

preferably a 2.4.27 kernel or higher.

-

Debian is the chosen distribution which means we'll be using apt-get for installation, but I'll also focus on basic source tarballs installation.

+
+

preferably a 2.4.27 kernel or higher.

+

Debian is the chosen distribution which means we'll be using apt-get +for installation, but I'll also focus on basic source tarballs +installation.

Dependencies:

  • ipsec configuration in the kernel
L2TPns
-

an L2TP PPP Termination tool.

+
+

an L2TP PPP Termination tool.

Dependencies:

  • libcli 1.8.0 or greater

    • @@ -108,48 +188,66 @@ attempts to explain the actual process that the VPN takes and to detail the plac
FreeRADIUS
-

For authentication, and accounting.

+
+

For authentication, and accounting.

MySQL
-

To act as a back-end database for the RADIUS.

+
+

To act as a back-end database for the RADIUS.

OpenSwan
-

Provides the ipsec suite package.

+
+

Provides the ipsec suite package.

Kernel Support

-

Debian stock kernel 2.4.27 and up are ipsec compatible although if you think otherwise check for the kernel-patch-openswan package.

+

Debian stock kernel 2.4.27 and up are ipsec compatible although if +you think otherwise check for the kernel-patch-openswan package.

Installation

L2TPns

Installation

-

L2TPns is a layer 2 tunneling protocol network server (LNS). It supports up to 65535 concurrent sessions per server/cluster plus ISP features such as rate limiting, walled garden, usage accounting, and more.

+

L2TPns is a layer 2 tunneling protocol network server (LNS). It +supports up to 65535 concurrent sessions per server/cluster plus ISP +features such as rate limiting, walled garden, usage accounting, and +more.

-

In a personal note - L2TPns is highly configurable for many cases, and extremely reliable for production/commerical use.

+

In a personal note - L2TPns is highly configurable for many cases, +and extremely reliable for production/commerical use.

Step 1:
-

Make sure you have libcli-1.8 development package installed:

+
+

Make sure you have libcli-1.8 development package installed:

# apt-cache search libcli
 libcli-dev - emulates a cisco style telnet command-line interface (dev files)
 libcli1 - emulates a cisco style telnet command-line interface
 # apt-get install libcli-dev
Step 2:
-

Download the source from SourceForge.

+
+

Download the source from SourceForge.

Step 3:
-

Build and install: make && make install

+
+

Build and install: make && make install

-

Alternately, you can skip these steps and simply apt-get install l2tpns.

+

Alternately, you can skip these steps and simply +apt-get install l2tpns.

-

On RPM-based distributions, you should be able to make packages from the libcli and l2tpns source tarballs with rpmbuild -ta.

+

On RPM-based distributions, you should be able to make packages from +the libcli and l2tpns source tarballs with +rpmbuild -ta.

-

Once compiliation is done you will have l2tpns in /usr/sbin/l2tpns, and all configuration files can be found in /etc/l2tpns/.

+

Once compiliation is done you will have l2tpns in +/usr/sbin/l2tpns, and all configuration files can be found +in /etc/l2tpns/.

Configuration

-

The only configuration that L2TPns takes is centralized in the configuration file /etc/l2tpns/startup-config.

+

The only configuration that L2TPns takes is centralized in the +configuration file /etc/l2tpns/startup-config.

set debug 2                               # Debugging level
 set log_file "/var/log/l2tpns"            # Log file: comment out to use stderr, use
                                           # "syslog:facility" for syslog
@@ -170,38 +268,75 @@ load plugin "sessionctl"                  # Drop/kill sessions
 load plugin "autothrottle"                # Throttle/snoop based on RADIUS
 load plugin "throttlectl"                 # Control throttle/snoop with nsctl
 load plugin "snoopctl"
-

This is the trimmed down version of probably most of the common configuration and even some extra options.

-

Important configuration options are highlited and you should adjust these to meet your network needs. We can deploy all of the environment into one box which is of course not a very good idea from a security point of view, but will function just fine. Moreover, we will be using aliased IP addresses so once you've decided to move the FreeRADIUS daemon to another computer on the LAN it will be fairly easy and won't take too much configuration into it.

-

Next, we need to setup the IP pool that L2TPns will provide to each VPN client. The configuration file is located at /etc/l2tpns/ip_pool and should look like the following:

+

This is the trimmed down version of probably most of the common +configuration and even some extra options.

+

Important configuration options are highlited and you should adjust +these to meet your network needs. We can deploy all of the environment +into one box which is of course not a very good idea from a security +point of view, but will function just fine. Moreover, we will be using +aliased IP addresses so once you've decided to move the FreeRADIUS +daemon to another computer on the LAN it will be fairly easy and won't +take too much configuration into it.

+

Next, we need to setup the IP pool that L2TPns will provide to each +VPN client. The configuration file is located at +/etc/l2tpns/ip_pool and should look like the following:

172.16.21.0/24
-

Of course you can change this pool to anything else (IANA IPs assigned for private internets only) just make sure it is not conflicting with your current LAN network addresses. This means that if you've assigned addresses of 192.168.0.1 and 192.168.0.2 to your LAN boxes you can't have a pool of 192.168.0.1/24 defined since L2TPns will try to route those addresses from the tun device, which is needless to say a bad idea...

+

Of course you can change this pool to anything else (IANA IPs +assigned for private internets only) just make sure it is not +conflicting with your current LAN network addresses. This means that if +you've assigned addresses of 192.168.0.1 and 192.168.0.2 to your LAN +boxes you can't have a pool of 192.168.0.1/24 defined since L2TPns will +try to route those addresses from the tun device, which is needless to +say a bad idea...

Next up, creating the access-list for L2TPns.

Add a username and password into /etc/l2tpns/users:

admin:12345
-

The password may either be plain-text as above, or encrypted with MD5 or DES (to distinguish DES from plain-text passwords, prefix the value with {crypt}).

-

L2TPns utilizes a terminal connection on port 23 which you would feel very comfortable in if you have worked with routers and switches devices before. The terminal provides control over the ppp termination which is why we've created an account to log on to.

+

The password may either be plain-text as above, or encrypted with MD5 +or DES (to distinguish DES from plain-text passwords, prefix the value +with {crypt}).

+

L2TPns utilizes a terminal connection on port 23 which you would feel +very comfortable in if you have worked with routers and switches devices +before. The terminal provides control over the ppp termination which is +why we've created an account to log on to.

IPsec

Installation

-

User-space IPsec tools for various IPsec implementations exist for linux, among them is the port of KAME's libipsec, setkey, and racoon. Others are the OpenSWAN (a successor to the FreeSWAN project).

+

User-space IPsec tools for various IPsec implementations exist for +linux, among them is the port of KAME's libipsec, setkey, and racoon. +Others are the OpenSWAN (a successor to the FreeSWAN project).

Getting IPsec installed is fairly easy with Debian:

# apt-get install openswan
-

The OpenSWAN project provides packages for RPM-based distributions.

-

Alternately, you may download the source from the OpenSWAN project:

+

The OpenSWAN project provides packages for RPM-based +distributions.

+

Alternately, you may download the source from the OpenSWAN +project:

# tar xvzf openswan-2.4.4.tar.gz
 # cd openswan-2.4.4
 # ./configure && make && make install

Configuration

-

OpenSWAN acts as the IKE daemon (remember IKE? it's job is to authenticate between the two peers and negotiate a secure medium). We will be setting up the IKE daemon as a RoadWarrior configuration, a term for remote access VPNs.

-

We desire this approach for compatibilty because after our VPN solution will be complete any user from a Windows machine will be easily ready to connect without any 3rd party applications, same for Linux.

-

Configuration files are placed in /etc/ipsec.d/, /etc/ipsec.conf and /etc/ipsec.secrets.

-

Let's start by choosing the remote client and it's PSK (Private Shared Key) /etc/ipsec.secrets:

+

OpenSWAN acts as the IKE daemon (remember IKE? it's job is to +authenticate between the two peers and negotiate a secure medium). We +will be setting up the IKE daemon as a RoadWarrior configuration, a term +for remote access VPNs.

+

We desire this approach for compatibilty because after our VPN +solution will be complete any user from a Windows machine will be easily +ready to connect without any 3rd party applications, same for Linux.

+

Configuration files are placed in /etc/ipsec.d/, +/etc/ipsec.conf and /etc/ipsec.secrets.

+

Let's start by choosing the remote client and it's PSK (Private +Shared Key) /etc/ipsec.secrets:

hostname_or_ipaddress %any : PSK "mysecretkeyisverylong"
-

This is an IP/key pair. The IP or FQDN defines the local peer (like a SOHO branch), then the remote host. Here we defined %any for all hosts, though it's possible to define only a specific IP. At last, we define the key associated with it.

-

A better way to create a key is to utilize /dev/random for creating a unique key.

+

This is an IP/key pair. The IP or FQDN defines the local peer (like a +SOHO branch), then the remote host. Here we defined %any for all hosts, +though it's possible to define only a specific IP. At last, we define +the key associated with it.

+

A better way to create a key is to utilize /dev/random for creating a +unique key.

# dd if=/dev/random count=16 bs=1 2>/dev/null | xxd -ps
-

Next, let's prepare the configuration file /etc/ipsec.conf:

+

Next, let's prepare the configuration file +/etc/ipsec.conf:

version 2.0
 config setup
      nat_traversal=yes
@@ -218,88 +353,146 @@ conn l2tp
      auto=add
 
 include /etc/ipsec.d/examples/no_oe.conf
-

In this file we have first defined version 2 which is a must, then enabled NAT Traversal. To understand the importance of this feature think of the following scenario: A remote user attempts to connect while he's behind a router and therefore NATed. The router has to de-encapsulate the packet, change things and then build it up again and send it. IPsec doesn't like other people messing with it's packet. That's why we solve this issue with NAT Traversal.

-

Next up we configure authentication type (certificates, psk, rsa keys, etc) then the left and right peers. The default mode OpenSWAN takes is tunnel unless told otherwise. I won't go into in-depth explanation of every method, you can take a quick look at /etc/ipsec.d/examples for more explanation and other variations of working with RSA keys, Certificates, host-to-host, and more.

+

In this file we have first defined version 2 which is a must, then +enabled NAT Traversal. To understand the importance of this feature +think of the following scenario: A remote user attempts to connect while +he's behind a router and therefore NATed. The router has to +de-encapsulate the packet, change things and then build it up again and +send it. IPsec doesn't like other people messing with it's packet. +That's why we solve this issue with NAT Traversal.

+

Next up we configure authentication type (certificates, psk, rsa +keys, etc) then the left and right peers. The default mode OpenSWAN +takes is tunnel unless told otherwise. I won't go into in-depth +explanation of every method, you can take a quick look at +/etc/ipsec.d/examples for more explanation and other +variations of working with RSA keys, Certificates, host-to-host, and +more.

In summary:

FreeRADIUS

-

The VPN setup needs to authenticate against something, that is the users database which we chose to be a FreeRADIUS server backed with a MySQL database.

+

The VPN setup needs to authenticate against something, that is the +users database which we chose to be a FreeRADIUS server backed with a +MySQL database.

Installation

-

FreeRADIUS is the premiere open source RADIUS server. While detailed statistics are not available, we believe that FreeRADIUS is well within the top 5 RADIUS servers world-wide, in terms of the number of people who use it daily for authentication. It scales from embedded systems with small amounts of memory, to systems with millions of users. It is fast, flexible, configurable, and supports more authentication protocols than many commercial servers.

+

FreeRADIUS is the premiere open source RADIUS server. While detailed +statistics are not available, we believe that FreeRADIUS is well within +the top 5 RADIUS servers world-wide, in terms of the number of people +who use it daily for authentication. It scales from embedded systems +with small amounts of memory, to systems with millions of users. It is +fast, flexible, configurable, and supports more authentication protocols +than many commercial servers.

Installing on Debian:

# apt-get install freeradius freeradius-mysql
-

From source: Download the latest freeradius package from freeradius.org

+

From source: Download the latest freeradius package from freeradius.org

# tar xvzf freeradius.tar.gz
 # cd freeradius
 # ./configure && make && make install

Configuration

-

This will appear a bit complex but it isn't, it's just a lot of configuration.

-

Following are the configurations you need to have in your /etc/freeradius/ files.

-

In this section I will not give you a dump of the configuration since they are very long and mostly default. I'll just post which changes to make.

-

We haven't yet configured MySQL, but it'll come afterwards, don't worry.

-

Make the following changes to the file /etc/freeradius/sql.conf:

+

This will appear a bit complex but it isn't, it's just a lot of +configuration.

+

Following are the configurations you need to have in your +/etc/freeradius/ files.

+

In this section I will not give you a dump of the configuration since +they are very long and mostly default. I'll just post which changes to +make.

+

We haven't yet configured MySQL, but it'll come afterwards, don't +worry.

+

Make the following changes to the file +/etc/freeradius/sql.conf:

server = "192.168.0.1"
 login = "radius"
 password = "12345678"
-

Add the following to the file /etc/freeradius/clients.conf:

+

Add the following to the file +/etc/freeradius/clients.conf:

client 192.168.0.1 {
     secret    = my_secret
     shortname = localhost
     nastype   = other
 }
-

Don't confuse the secret directive there with IPsec. RADIUS server are using secret keys also to identify their allowed NAS (Network Access Servers), these are the clients that talk to the RADIUS server.

-

Also, change the client 127.0.0.1 {} directive to hold the secret "my_secret" like we configured for 192.168.0.1 to avoid conflicts.

-

Uncomment the sql directive in the authorize, accounting, and session sections of /etc/freeradius/radiusd.conf.

-

Now for populating FreeRADIUS with MySQL. If you don't know or haven't set root password for MySQL you can do it now with:

+

Don't confuse the secret directive there with IPsec. RADIUS server +are using secret keys also to identify their allowed NAS (Network Access +Servers), these are the clients that talk to the RADIUS server.

+

Also, change the client 127.0.0.1 {} directive to hold +the secret "my_secret" like we configured for 192.168.0.1 to avoid +conflicts.

+

Uncomment the sql directive in the +authorize, accounting, and +session sections of +/etc/freeradius/radiusd.conf.

+

Now for populating FreeRADIUS with MySQL. If you don't know or +haven't set root password for MySQL you can do it now with:

# mysqladmin -u root password password_here

Then add the following to /root/.my.cnf:

[mysqladmin]
 user = root
 password = password_here
-

Create the radius database, using the schema given in /usr/share/doc/freeradius/examples/db_mysql.sql.gz.

+

Create the radius database, using the schema given in +/usr/share/doc/freeradius/examples/db_mysql.sql.gz.

-

It may be necessary to modify the column definition of id in the nas table, removing DEFAULT '0' such that the definition reads:

+

It may be necessary to modify the column definition of +id in the nas table, removing +DEFAULT '0' such that the definition reads:

id int(10) NOT NULL auto_increment,
# mysqladmin create radius
 # mysql radius
 mysql> source db_mysql.sql
 mysql> GRANT ALL ON * TO 'radius'@'localhost' IDENTIFIED BY 'radius_password';
-

All the configuration is now done. Let's add a user to our VPN database.

+

All the configuration is now done. Let's add a user to our VPN +database.

# mysql radius
 mysql> INSERT INTO radcheck values (0, "test", "User-Password", "==", "1234");
-

We have now created a user in the database of username test and password 1234.

-

Testing the RADIUS setup is simple using the radtest utility provided with it.

+

We have now created a user in the database of username +test and password 1234.

+

Testing the RADIUS setup is simple using the radtest utility provided +with it.

# radtest
 Usage: radtest user passwd radius-server[:port] nas-port-number secret [ppphint] [nasname]
 # radtest test 1234 192.168.0.1 1812 my_secret
-

radtest sends an Access-Request to the RADIUS server and expects an Access-Accept back from it. If you're not getting an Access-Accept from the RADIUS you're advised to check the configuration again and see what you might have missed.

+

radtest sends an Access-Request to the RADIUS server and expects an +Access-Accept back from it. If you're not getting an Access-Accept from +the RADIUS you're advised to check the configuration again and see what +you might have missed.

Firewall Configuration

-

We need to apply a few things to iptables configuration and kernel networking.

-

First off, we need to accept VPN-specific packets through the firewall. Of course you will have to adjust the rules to fits you needs, in this case, ppp0 is the Internet interface.

+

We need to apply a few things to iptables configuration and kernel +networking.

+

First off, we need to accept VPN-specific packets through the +firewall. Of course you will have to adjust the rules to fits you needs, +in this case, ppp0 is the Internet interface.

# iptables --append INPUT --in-interface  ppp0 -p udp --dport 1701 -j ACCEPT
 # iptables --append INPUT --in-interface  ppp0 -p udp --dport 500 -j ACCEPT
 # iptables --append INPUT --in-interface  ppp0 -p udp --dport 4500 -j ACCEPT
 # iptables --append INPUT --in-interface  ppp0 -p 50 -j ACCEPT
-

If you haven't setup your Linux box as a gateway yet then you have to allow forwarding/masqing for the boxes on the LAN (and therefore for the VPN clients):

+

If you haven't setup your Linux box as a gateway yet then you have to +allow forwarding/masqing for the boxes on the LAN (and therefore for the +VPN clients):

# iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
 # iptables --append FORWARD --in-interface eth0 -j ACCEPT
 # echo 1 > /proc/sys/net/ipv4/ip_forward

References

VPN Reference
-

+
+

L2TPns Project
-

+
+

OpenSWAN Project
-

+
+

diff --git a/docs/manpages/l2tpns.8 b/docs/manpages/l2tpns.8 index ecb9dad..e6e0cb3 100644 --- a/docs/manpages/l2tpns.8 +++ b/docs/manpages/l2tpns.8 @@ -1,5 +1,19 @@ -.\" Automatically generated by Pandoc 2.9.2.1 +.\" Automatically generated by Pandoc 3.0.1 .\" +.\" Define V font for inline verbatim, using C font in formats +.\" that render this, and otherwise B font. +.ie "\f[CB]x\f[]"x" \{\ +. ftr V B +. ftr VI BI +. ftr VB B +. ftr VBI BI +.\} +.el \{\ +. ftr V CR +. ftr VI CI +. ftr VB CB +. ftr VBI CBI +.\} .TH "L2TPNS" "8" "January 31, 2021" "Layer 2 tunneling protocol network server (LNS)" "" .hy .SH NAME diff --git a/docs/manpages/nsctl.8 b/docs/manpages/nsctl.8 index 21c3baa..5916e84 100644 --- a/docs/manpages/nsctl.8 +++ b/docs/manpages/nsctl.8 @@ -1,5 +1,19 @@ -.\" Automatically generated by Pandoc 2.9.2.1 +.\" Automatically generated by Pandoc 3.0.1 .\" +.\" Define V font for inline verbatim, using C font in formats +.\" that render this, and otherwise B font. +.ie "\f[CB]x\f[]"x" \{\ +. ftr V B +. ftr VI BI +. ftr VB B +. ftr VBI BI +.\} +.el \{\ +. ftr V CR +. ftr VI CI +. ftr VB CB +. ftr VBI CBI +.\} .TH "NSCTL" "8" "January 31, 2021" "Manage running l2tpns instance" "" .hy .SH NAME diff --git a/docs/manpages/startup-config.5 b/docs/manpages/startup-config.5 index ccc3143..e039c15 100644 --- a/docs/manpages/startup-config.5 +++ b/docs/manpages/startup-config.5 @@ -1,5 +1,19 @@ -.\" Automatically generated by Pandoc 2.9.2.1 +.\" Automatically generated by Pandoc 3.0.1 .\" +.\" Define V font for inline verbatim, using C font in formats +.\" that render this, and otherwise B font. +.ie "\f[CB]x\f[]"x" \{\ +. ftr V B +. ftr VI BI +. ftr VB B +. ftr VBI BI +.\} +.el \{\ +. ftr V CR +. ftr VI CI +. ftr VB CB +. ftr VBI CBI +.\} .TH "STARTUP-CONFIG" "5" "January 31, 2021" "Configuration file for l2tpns" "" .hy .SH NAME @@ -19,7 +33,7 @@ Comments are indicated by either the character # or !. .PP Settings are specified with .PP -\f[B]set\f[R] \f[C]variable\f[R] \f[C]value\f[R] +\f[B]set\f[R] \f[V]variable\f[R] \f[V]value\f[R] .PP A list of the possible configuration directives follows. Each of these should be set by a line like: @@ -34,7 +48,7 @@ Each of these should be set by a line like: .PD \f[B]set\f[R] \f[I]boolean\f[R] \f[I]true\f[R] .PP -The following \f[C]variables\f[R] may be set: +The following \f[V]variables\f[R] may be set: .PP \f[B]accounting_dir\f[R] (string) .IP @@ -367,7 +381,7 @@ Simplifies firewalling of RADIUS ports (default: dynamically assigned). \f[B]random_device\f[R] (string) .PP Path to random data source (default /dev/urandom). -Use \[dq]\[dq] to use the rand() library function. +Use \[lq]\[rq] to use the rand() library function. .PP \f[B]scheduler_fifo\f[R] (boolean) .PP