30. Tunnelling
ROX™ v2.2 User Guide
303
RuggedBackbone™ RX5000
30.1.1.2. Policy-Based VPNs
RuggedBackbone™ supports the creation of policy-based VPNs, which may be characterized as
follows:
• IPsec network interfaces are not created.
• The routing table is not involved in directing packets to the IPsec later.
• Only data traffic matching the tunnel’s local and remote subnets is forwarded to the tunnel. Normal
traffic is routed by one set of firewall rules and VPN traffic is routed based on separate rules.
• The firewall is configured with a VPN zone of type "IPsec".
• As IPsec packets are received, they are decoded, policy-flagged as IPsec-encoded, and presented
as having arrived directly via the same network interface on which they were originally received.
• Firewall rules must be written to allow traffic to and from VPN tunnels. These are based on the normal
form of source/destination IP addresses and IP protocol and port numbers. These rules, by virtue of
the zones they match, use the policy flagging inserted by netkey and route matching data traffic to
the proper interface.
30.1.1.3. Supported Encryption Protocols
Openswan supports the following standard encryption protocols:
• 3DES (Triple DES) – Uses three DES encryptions on a single data block, with at least two different
keys, to get higher security than is available from a single DES pass. 3DES is the most CPU intensive
cipher.
• AES – The Advanced Encryption Standard protocol cipher uses a 128-bit block and 128, 192 or 256-
bit keys. This is the most secure protocol in use today, and is much preferred to 3DES due to its
efficiency.
30.1.1.4. Public Key And Pre-shared Keys
In public key cryptography, keys are created in matched pairs (called public and private keys). The
public key is made public while the private key is kept secret. Messages can then be sent by anyone
who knows the public key to the holder of the private key. Only the owner of the private key can decrypt
the message.
When you want to use this form of encryption, each router configures its VPN connection to use the
RSA algorithm and includes the public signature of its peer. The RuggedBackbone™’s public signature
is available from the output of the tunnel/ipsec/display-public-key menu.
In secret key cryptography, a single key known to both parties is used for both encryption and decryption.
When you want to use this form of encryption, each router configures its VPN connection to use a secret
pre-shared key. The pre-shared key is configured through the tunnel/ipsec/preshared-key menu.
30.1.1.5. X509 Certificates
When one side of the VPN connection is placed from a dynamic IP (the so-called “roaming client”),
X509 Certificates may be used to authenticate the connection. Certificates are digital signatures that
are produced by a trusted source, namely a Certificate Authority (CA). For each host, the CA creates
an certificate that contains CA and host information and “signs” the certificate by creating a digest of
all the fields in the certificate and encrypting the hash value with its private key. The encrypted digest
is called a "digital signature". The host’s certificate and the CA public key are installed on all gateways
that the host connects to.
When the gateway receives a connection request, it uses the CA public key to decrypt the signature
back into the digest. It then recomputes its own digest from the plain text in the certificate and compares
