5. Connecting things

5.1.1.1. Kernel configuration

To make fully use of the VLAN link you're about to set up, your kernel will need support for a number of things. The relevant bits out of $KERNEL_SOURCE/.config are below. The support for most, if not all, of these components can be either in module (<M>) form or compiled in (<y>), depending on your preference. This is the minimum requirement for getting things to work.

CONFIG_NETFILTER=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IPSEC=m
CONFIG_IPSEC_AUTH_HMAC_MD5=y
CONFIG_IPSEC_AUTH_HMAC_SHA1=y
CONFIG_IPSEC_ESP=y
CONFIG_IPSEC_ENC_3DES=y
CONFIG_IPSEC_IPCOMP=y
     

As you can see, it basically boils down to support for Netfilter/iptables, GRE tunnels and IPSec. Support for TCP/IP networking is implied. X.509 support in your FreeS/WAN implementation is assumed, no further kernel configuration is required for that to work. For more information on adding X.509 certificate support to FreeS/WAN, see the References section.

5.1.1.2. FreeS/Wan configuration

First thing to do is set up the x509 infrastructure, so that FreeS/Wan is able to find everything it needs.

Just for convenience the list of files used in this part of the configuration (assuming sane default names):

/etc/ipsec.d/private/myKey.pem
/etc/ipsec.secrets
/etc/x509cert.der
/etc/ipsec.d/cacerts/vpnCA.pem
/etc/ipsec.d/crls/vpnCRL.pem
     

Move the earlier generated private key file to /etc/ipsec.d/private/myKey.pem and modify /etc/ipsec.secrets so that it reads something like:

:RSA myKey.pem "my_uberl33t_passphrase"
     

on the first line of the file. This is necessary to unlock the private key which was encrypted with a passphrase when it was generated. Using this format will make FreeS/Wan assume all keyed connections will use certificates, with the indicated private key to match. For security reasons you can now chmod 600 both the myKey.pem en ipsec.secrets file, so only root can read or write to it.

Depending on which format you receive your X.509 certificate back, you either need to convert it or simply copy it to its proper location. This is because the default FreeS/Wan looks for is /etc/x509cert.der, which as the name implies needs to be your certificate in DER format. The VLAN CA sends both recognised forms (DER and PEM) back, but just in case “man x509” tells you how to convert from one format to another. In short; /etc/x509cert.der needs to be the X.509 certificate the CA signed for you in DER format (item 1). Item 2 is the CA's own public certificate, which goes in /etc/ipsec.d/cacerts/. Just copy it there and FreeS/Wan will find it. The last item you received is the list which contains all the certificates which the CA signed, but marked invalid at a later date. This file goes in /etc/ipsec.d/crls/.

The first step after setting up all the certificate stuff is to get a point-to-point IPSec link going with a NAP. This process is similar to setting up a regular IPSec link as per the FreeS/Wan documentation, with the little difference that instead of a reference to the public RSA key of both ends, there will now be a reference to the identifying DN of their X.509 certificates. Assuming that the NAP you connect to is “right” and you are “left”, your /etc/ipsec.conf should look something like the below code snippet:

config setup
 interfaces=%defaultroute
 klipsdebug=none
 plutodebug=none
 plutoload=%search
 plutostart=%search
 uniqueids=yes
conn vlan-link
 right=a.b.c.d
 rightnexthop=e.f.g.h
 rightid="C=CC, O=VLAN, E=admin@vlan.NAP"
 rightrsasigkey=%cert
 left=%defaultroute
 leftid="C=CC, O=VLAN_CLIENTNET, E=admin@vlan.clientnet"
 leftrsasigkey=%cert
 compress=yes
 authby=rsasig
 auto=start
 type=transport
     

This is a very basic configuration, but is likely to work, assuming firewalls and such are configured to allow the traffic needed (protocol 50 and port 500/udp), and your setup is fairly straightforward. Add complexity as needed for your environment.

Given that all we need out of the ipsec link is a point-to-point encrypted channel to pass GRE over, transport mode suffices, which explains the “type=transport” in the configuration.

5.1.2.1. Kernel Configuration

As in the previous sections on Linux IPSec, the relevant bits out of $KERNEL_SOURCE/.config are listed below. The support for most, if not all, of these components can be either in module (<M>) form or compiled in (<y>), depending on your preference. This is the minimum requirement for getting things to work:

CONFIG_IP_MULTICAST=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_NET_KEY=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_NETFILTER=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_DEFLATE=y
     

Breaking it down, it amounts to adding support for Netfilter, GRE, IPSec and the Cryptographic API. Again, being able to set all these options implies having TCP/IP networking support enabled.

5.1.2.2. The IPSec trick

We'll place all the keys and certificates under /etc/certs, with the difference that your own x509 certificate is now copied to /etc/certs/myCert.pem. So everything now looks as follows:

/etc/certs/myKey.pem
/etc/certs/myCert.pem
/etc/certs/napCert.pem
     

The /etc/certs/napCert.pem file is the x.509 certificate of the NAP you're connecting to.

#!/sbin/setkey -f
flush;
spdflush;
spdadd a.b.c.d w.x.y.w any -P in ipsec
  esp/transport//require;
spdadd w.x.y.z. a.b.c.d any -P out ipsec
  esp/transport//require;
      

path certificate "/etc/certs";
listen
{
 isakmp w.x.y.z;
}
remote a.b.c.d
{
 exchange mode main;
 my_identifier asn1dn;
 peer_identifier asn1dn;
 peers_certfile "napCert.pem";
 certificate_type x509 "myCert.pem" "myKey.pem";
 proposal {
  encryption_algorithm 3des;
  hash_algorithm sha1;
  authentication_method rsasig;
  dh_group 2;
 }
}
sainfo address w.x.y.z any address a.b.c.d any
{
 pfs_group 2;
 encryption_algorithm 3des;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}
      

5.1.4.1. Static

The easiest way to get your traffic routed to the VLAN is by adding a static route into your kernel routing table.

ip route add 10.64.0.0/14 via 10.64.25.1 dev vlan-link
     

However, for that to work, you will also need to convince the NAP admin to add a (static) route for your subnet into the NAP host's routing tables. This is an administrative burden, and error prone, so VLAN makes use of dynamic routing protocols to pass around routing information.

5.1.4.2. OSPF

OSPF is implemented in Linux with Zebra, or more recently, Quagga. Its configuration format has a lot of similarities with Cisco's IOS, so if you're a network admin, you'll feel right at home. Using Zebra's ospfd the following configuration can be used:

interface vlan-link
 ip ospf network point-to-point
!
router ospf
 ospf router-id 10.64.25.1
 redistribute kernel route-map vlan-filter
 redistribute connected route-map vlan-filter
 network 10.64.25.1/32 area 0
 network 10.64.0.1/32 area 0
!
access-list vlan-net permit 10.64.0.0/14
!
route-map vlan-filter permit 10
 match ip address vlan-net
!
     

Don't forget to save any changes you make to /etc/zebra/ospfd.conf. Hopefully the routers on either end of the GRE tunnel will see eachother right away which saves troubleshooting. Check with the zebra command (in the zebra console interface, telnet localhost 2604):

sh ip ospf neighbor
     

Which should produce something that looks like:

Neighbor ID     Pri   State           Dead Time   Address         Interface           RXmtL RqstL DBsmL
10.64.0.1         1   Full/DROther    00:00:38    10.64.0.1       vlan-link:10.64.25.1     0     0     0
     

The “Full/DROther” indicates a full OSPF relation between both routers. You can verify the distribution of routes with typing:

ip route show
     

in your shell, which should yield a rather large routing table with lots of “proto zebra” entries.

5.1.4.3. BGP