VPN, Netfilter and Shorewall — The Basics

TomEastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“GNU Free Documentation
License”.

Gateway-to-gateway traffic vs. Host-to-host traffic.

The purpose of a Virtual Private Network
(VPN) is to provide for secure communication between a set of hosts.
Communication between a pair of hosts connected by a VPN occurs in
stages:

Local-host-to-local-gateway.
This communication is not encrypted; in the case where the traffic
originates on the gateway itself, the communication is local to that
system.

Local-gateway-to-remote-gateway. This
communication is encrypted and can use a tunneling protocol such as
GRE, AH or ESP or a standard protocol such as UDP or TCP. Some VPNs
use multiple protocols; for example PPTP uses TCP port 1723 and GRE
while IPSEC uses UDP port 500 together with ESP or AH.

Remote-gateway-to-remote-host.
This is just the unencrypted traffic described in the first item as it
is delivered to its destination.

Of course, one-way communication generally isn't useful so we need
traffic in the other direction as well.

Remote-host-to-remote-gateway.

Remote-gateway-to-local-gateway.

Local-gateway-to-local-host.

Relationship to Netfilter

When Netfilter is configured on a VPN gateway, each VPN packet goes
through Netfilter twice! Let's first consider outbound traffic:

Local-host-to-local-gateway.
This traffic has a source address in the local network or on the
gateway itself. The destination IP address is that of a remote host;
either the remote gateway itself or a host behind that gateway.

Local-gateway-to-remote-gateway. This
(encrypted) traffic has a source IP address on the gateway and is
addressed to the remote gateway.

Incoming traffic is similar.

What does this mean with Shorewall?

When Shorewall is installed on a VPN gateway system, it categorizes
the VPN-related traffic slightly differently:

Local-host-to-remote-host —
same as Local-host-to-local-gateway
above.

Local-gateway-to-remote-gateway.

Remote-gateway-to-local-gateway.

Remote-host-to-local-host —
same as Local-gateway-to-local-host
above.

Shorewall implements a set of features for dealing with VPN.

The /etc/shorewall/tunnels file. This file
is used to define remote gateways and the type of encrypted traffic
that will be passed between the Shorewall system and those remote
gateways. In other words, the tunnels file deals with Local-gateway-to-remote-gateway and Remote-gateway-to-local-gateway traffic.

The /etc/shorewall/zones file. An entry in
this file allows you to associated a name with the set of hosts behind
the remote gateway (or to the remote gateway itself if it is a
standalone system).

The /etc/shorewall/interfaces and
/etc/shorewall/hosts files. These files are used
to associate a set of remote hosts with the zone name defined in
/etc/shorewall/zones.

The /etc/shorewall/policy and
/etc/shorewall/rules files. These files are used
to define the connections that are permitted between the remote and
local hosts -- in other words, the Local-host-to-remote-host and Remote-host-to-local-host traffic.

Defining Remote Zones

Most VPN types are implemented using a virtual network device such
as pppN (e.g., ppp0), tunN (e.g., tun0), etc. This means that in most
cases, remote zone definition is similar to zones that you have already
defined.

Eliminating the /etc/shorewall/tunnels file

The /etc/shorewall/tunnels file provides no
functionality that could not be implemented using entries in
/etc/shorewall/rules and I have elimination of the
/etc/shorewall/tunnels file as a long-term goal. The
following sections show how entries in
/etc/shorewall/tunnels can be replaced by rules for
some common tunnel types.

The "noah" option causes the rules for protocol 51 to be
eliminated. The "ipsecnat" causes UDP port 4500 to be accepted in both
directions. If no GATEWAY ZONE is given then the last two rules above
are omitted.