New Features of OpenVPN 2.1 and 2.2

Exclusive offer: get 50% off this eBook here
OpenVPN 2 Cookbook

OpenVPN 2 Cookbook — Save 50%

100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network

£18.99    £9.50
by Jan Just Keijser | March 2011 | Cookbooks Networking & Telephony Open Source

This article by Jan Just Keijser, author of OpenVPN 2 Cookbook, will focus on some of the new features found in OpenVPN 2.1 and the upcoming 2.2 release. The upcoming 2.2 release of OpenVPN is mainly a bug-fix release, though a few new directives were introduced. In the last recipe of this article, we will focus on one of them.

In this article, we will cover:

  • Inline certificates
  • Connection blocks
  • Port sharing with an HTTPS server
  • Routing features: redirect-private, allow-pull-fqdn
  • Handing out public IPs
  • OCSP support
  • New for 2.2: the x509_user_name parameter

 

OpenVPN 2 Cookbook

OpenVPN 2 Cookbook

100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network

  • Set of recipes covering the whole range of tasks for working with OpenVPN
  • The quickest way to solve your OpenVPN problems!
  • Set up, configure, troubleshoot and tune OpenVPN
  • Uncover advanced features of OpenVPN and even some undocumented options
        Read more about this book      

(For more resources on OpenVPN, see here.)

Inline certificates

To ease the deployment of OpenVPN configuration, public and private key files, a new feature is available to include all of them in a single file. This is done by integrating the contents of the ca, cert, key, and optionally the tls-auth file into the client configuration file itself. So, in this recipe, we will set up such a configuration file and use it to connect to our standard OpenVPN server.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file basic-udp-server.conf (download code- ch:2) at hand.

How to do it...

  1. First, start the server:

    [root@server]# openvpn --config basic-udp-server.conf

  2. Create the client configuration file:

    client
    proto udp
    remote openvpnserver.example.com
    port 1194
    dev tun
    nobind

    ca [inline]
    cert [inline]
    key [inline]
    tls-auth [inline] 1

    <ca>
    -----BEGIN CERTIFICATE-----
    # insert base64 blob from ca.crt
    -----END CERTIFICATE-----
    </ca>

    <cert>
    -----BEGIN CERTIFICATE-----
    # insert base64 blob from client1.crt
    -----END CERTIFICATE-----
    </cert>

    <key>
    -----BEGIN PRIVATE KEY-----
    # insert base64 blob from client1.key
    -----END PRIVATE KEY-----
    </key>

    <tls-auth>
    -----BEGIN OpenVPN Static key V1-----
    # insert ta.key
    -----END OpenVPN Static key V1-----
    </tls-auth>

    Insert the contents of the ca.crt, client1.crt, client1.key and ta.key files in the configuration. Save it as example12-1-client.conf.

  3. Then, connect the client:

    [root@client]# openvpn --config example12-1-client.conf

How it works...

When OpenVPN parses the configuration directives, ca, cert, key, and tls-auth (and dh for server configuration files), and it finds the value [inline], then an XML-like block must be present later in the configuration file. The contents of this XML-like block are then read and treated in the same manner as when a file is specified. When all the required configuration files or blocks are present, the connection is established.

Note that it is not required to treat all of the above configuration directives in the same manner. It is also possible to only specify an [inline] block for the CA certificate file, as this file tends to be static for all the clients.

Connection blocks

Similar to the inline certificates used in the previous recipe, it is also possible to specify connection blocks. These connection blocks are treated as multiple definitions for remote servers and they are tried in order until a VPN connection is established. The advantage of using a connection block is that for each remote server, server-specific parameters can be specified, such as the protocol (UDP or TCP), the remote port, whether a proxy server should be used , and so on.

In this recipe, we will set up two servers, one listening on a UDP port and the other on a TCP port. We will then configure the OpenVPN client to try the first server using a UDP connection. If the connection cannot be established, the client will attempt to connect to the second server using a TCP connection.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (download code- ch:2) at hand, as well as the server configuration file, example9-7-server.conf (download code- ch:9).

How to do it...

  1. Start both the servers:

    [root@server1]# openvpn --config basic-udp-server.conf

    [root@server2]# openvpn --config example9-7-server.conf

  2. Check the log files to check that both the servers have successfully started.
  3. Create the client configuration file:

    client
    dev tun

    <connection>
    remote openvpnserver1.example.com
    proto udp
    port 1194
    </connection>

    <connection>
    remote openvpnserver2.example.com
    proto tcp
    port 1194
    </connection>

    ca /etc/openvpn/cookbook/ca.crt
    cert /etc/openvpn/cookbook/client1.crt
    key /etc/openvpn/cookbook/client1.key
    tls-auth /etc/openvpn/cookbook/ta.key 1

    ns-cert-type server

    Save it as example12-2-client.conf.

  4. Start the client:

    [root@client]# openvpn --config example12-2-client.conf

  5. After the connection has been established, stop the first OpenVPN process on the server that the client connected to:

    [root@server1]# killall openvpn

    And wait for the client to reconnect. After the default timeout period, the client will reconnect to the alternate server using the TCP protocol.

How it works...

When the OpenVPN client starts up, it attempts to connect to the server specified in the first <connection> block. If that connection fails, it will try the next <connection> block entry and so forth. When an OpenVPN server becomes unavailable or is stopped, the client will automatically restart and try to connect to the first available OpenVPN server again.

The OpenVPN client first parses the global directives, which are specified outside the <connection> blocks. For each block, the global directives are then overruled using block-specific directives. This makes it easier to specify in the <connection> blocks only those parameters that are different for each connection.

There's more...

Connection blocks, as well as inline certificates, are very handy new features introduced in OpenVPN 2.1. A consequence of these features is that the use of the command line to overrule the directives specified in the configuration file becomes harder, if not impossible. There are a few other things to keep in mind when using connection blocks.

Allowed directives inside connection blocks

There are only a few directives allowed inside a connection block:

  • bind
  • connect-retry, connect-retry-max, connect-timeout
  • float
  • http-proxy, http-proxy-option, http-proxy-retry, http-proxy-timeout
  • local lport
  • nobind
  • port
  • proto
  • remote, rport
  • socks-proxy, socks-proxy-retry

All other directives are considered global and can only be specified once.

Pitfalls when mixing TCP and UDP-based setups

Connection blocks make it very easy to mix TCP and UDP-based setups. The downside is that the global parameters specified in the configuration file must be valid for both the TCP and UDP-based setups. This rules out the use of the commonly-used fragment directive, as well as a few other tuning parameters. It is expected that this shortcoming of <connection> blocks will be addressed in a future version of OpenVPN.

OpenVPN 2 Cookbook 100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network
Published: February 2011
eBook Price: £18.99
Book Price: £30.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on OpenVPN, see here.)

Port sharing with an HTTPS server

A common OpenVPN setup to allow road warriors to reach the home office is to have OpenVPN listen on the secure web server (HTTPS) port 443. The downside is that you can no longer use that port on the OpenVPN server to actually host a secure website. OpenVPN 2.1 introduces a new port-sharing directive, enabling dual use of a TCP port. All traffic that is detected as OpenVPN traffic is processed by the OpenVPN server itself, and all other traffic is forwarded to another (local) machine and/or port.

In this recipe, we will set up an OpenVPN server to share TCP port 443 with a web server and we will show that both OpenVPN and a web browser can successfully connect to this server.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the server configuration file, example9-7-server.conf (download code- ch:9), at hand, as well as the client configuration file example9-7.ovpn (download code- ch:9).

On the server computer, a secure web server was running on port 8443.

How to do it...

  1. Create the server configuration file by modifying the example9-7-server.conf file. Change the following line:

    port 1194

    Change it to the following:

    port 443
    port-share localhost 8443

    Save it as example12-3-server.conf.

  2. Start the server:

    [root@server]# openvpn --config example12-3-server.conf

  3. Next, modify the client configuration file example9-7.ovpn by also changing the port to 443. Save the client configuration file as example12-3.ovpn.
  4. Start the client:

    New Features of OpenVPN 2.1 and 2.2

  5. Verify that the client can connect to the VPN server. After the client has connected, start a web browser and browse to:

    <code>https://openvpnserver.example.com</code>

    The OpenVPN server log file will show lines similar to the following:
    ... Re-using SSL/TLS context
    ... TCP connection established with <client-ip>:53356
    ... TCPv4_SERVER link local: [undef]
    ... TCPv4_SERVER link remote: <client-ip>:53356
    ... <client-ip>:53356 Non-OpenVPN client protocol detected

How it works...

When port-share is used, OpenVPN will inspect the incoming traffic on port 443. If this traffic is a part of an OpenVPN session or if it is an initial OpenVPN handshake, then the OpenVPN server processes it by itself. If it is not recognizable as OpenVPN traffic, it is forwarded out to the host and port specified in the port-share directive.

Hence, it is the OpenVPN server process that is always listening on port 443. The web server must be listening on a different host or different port. With this setup, the same port can be used to offer two different services.

There's more...

The web server that OpenVPN forwards its traffic to must be a secure (HTTPS) web server. This is due to the nature of the inbound SSL traffic on the OpenVPN server itself. It is not possible to forward the traffic to a regular (HTTP) web server. If the traffic is forwarded to port 80, the Apache web server used in this recipe, the following error will appear in the web server error log file:

[error] [client 127.0.0.1] Invalid method in request \x16\x03\x01

Routing features: redirect-private, allow-pull-fqdn

In OpenVPN 2.1, some of the routing features are expanded. Most notably, there are new options for the directive redirect-gateway and several new routing directives are available:

  • redirect-private: This option behaves very similar to the redirect-gateway, especially when the new parameters are used, but it does NOT alter the default gateway.
  • allow-pull-fqdn: Allows the client to pull DNS names from the OpenVPN server. Previously, only IP addresses could be pushed or pulled. This option cannot be 'pushed' and needs to be added to the client configuration itself.
  • route-nopull: All the options are pulled by a client from the server, except for the routing options. This can be particularly handy when troubleshooting an OpenVPN setup.
  • max-routes n: Defines the maximum number of routes that may be defined or pulled from a remote server.

In this recipe, we will focus on the redirect-private directive and its parameters, as well as the allow-pull-fqdn parameter.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the configuration file, basic-udp-server.conf (download code- ch:2) at hand, as well as the client configuration file, basic-udp-client.ovpn (download code- ch:2).

How to do it...

  1. Append the following lines to the basic-udp-server.conf file:

    push "redirect-private bypass-dhcp bypass-dns"
    push "route server.example.com"

    Save it as example12-4-server.conf.

  2. Start the server:

    [root@server]# openvpn --config example12-4-server.conf

  3. Append the following line to the client configuration file, basic-udp-client.ovpn, and save it as example12-4.ovpn:

    allow-pull-fqdn

  4. Start the client:

    New Features of OpenVPN 2.1 and 2.2

  5. Watch the routing table after the connection has been established:
    • If the DHCP or DNS server was on a different subnet than the client itself, then a new route will have been added. This is to ensure that DHCP requests still go to the local DHCP server and are not sent over the VPN tunnel.
    • A route for the host server.example.com will have been added.

How it works...

The bypass-dhcp and bypass-dns options for the directives, redirect-gateway and redirect-private, cause the OpenVPN client to add an extra route to the DHCP and DNS servers if they are on a different network. In large-scale networks, the DNS server is often not found on the local subnet that the client is connected to. If the route to this DNS server is altered to go through the VPN tunnel after the client has connected, this will cause at the very least a serious performance penalty. More likely, the entire DNS server will become unreachable.

The allow-pull-fqdn directive enables the use of a DNS name instead of an IP address when specifying a route. Especially, if a dedicated route to a host with a dynamic IP address needs to be made, this is very useful.

There's more...

Apart from the directives explained in this recipe, there are more routing directives available to control if and how routes are added to the client.

The route-nopull directive

The route-nopull directive causes the client to pull all the information from the server but not the routes. This can be very useful for debugging a faulty server setup. It does not mean that no routes are added at all by the OpenVPN client. Only the routes that are specified using push "route" will be ignored.

The 'max-routes' directive

The max-routes directive is introduced in OpenVPN 2.1, as version 2.1 allows an administrator to push many more routes when compared to OpenVPN 2.0. To prevent a client from being overloaded with routes, the option max-routes n is added, where n is the maximum number of routes that can be defined in the client configuration file and/or can pulled from the server.

The default value for this parameter is 100.

OpenVPN 2 Cookbook 100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network
Published: February 2011
eBook Price: £18.99
Book Price: £30.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on OpenVPN, see here.)

Handing out public IPs

With the topology subnet feature that OpenVPN 2.1 offers, it becomes feasible to hand out public IP addresses to connecting clients. For this recipe, we will show how such a setup can be realized. We will use a technique to make the VPN clients appear as if they are a part of the remote network. If a dedicated IP address block is available for the VPN clients, then this is not required. The advantage of using the proxy-arp method is that it allows us to use only part of an expensive public IP address block.

Getting ready

For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client computer was running Windows XP SP3 and OpenVPN 2.1.1. Keep the client configuration file, basic-udp-client.ovpn (download code- ch:2), at hand.

To test this recipe, a public IP address block of 16 addresses was used, but here, we will list a private address block instead (10.0.0.0/255.255.255.240). This block is used as follows:

  • 10.0.0.18 : This is used for the server's VPN IP address
  • 10.0.0.19 : Not available
  • 10.0.0.20 - 10.0.0.25 : Available for VPN clients
  • 10.0.0.26: Not available
  • 10.0.0.27: The LAN address of the OpenVPN server itself
  • 10.0.0.28 - 10.0.0.29 : Not available
  • 10.0.0.30: The router on the remote LAN

How to do it...

  1. Create the server configuration file:

    mode server
    tls-server
    proto udp
    port 1194
    dev tun

    ifconfig 10.0.0.18 255.255.255.240
    ifconfig-pool 10.0.0.20 10.0.0.25
    push "route 10.0.0.27 255.255.255.255 net_gateway"
    push "route-gateway 10.0.0.30"
    push "redirect-gateway def1"

    ca /etc/openvpn/cookbook/ca.crt
    cert /etc/openvpn/cookbook/server.crt
    key /etc/openvpn/cookbook/server.key
    dh /etc/openvpn/cookbook/dh1024.pem
    tls-auth /etc/openvpn/cookbook/ta.key 0

    persist-key
    persist-tun
    keepalive 10 60

    topology subnet
    push "topology subnet"

    script-security 2
    client-connect /etc/openvpn/cookbook/proxyarp-connect.sh
    client-disconnect /etc/openvpn/cookbook/proxyarp-disconnect.sh

    #user nobody
    #group nobody

    daemon
    log-append /var/log/openvpn.log

    Note that this server configuration cannot be run as user nobody. Save the configuration file as example12-5-server.conf.

  2. Next, create the proxyarp-connect.sh script:

    #!/bin/bash
    /sbin/arp -i eth0 -Ds $ifconfig_pool_remote_ip eth0 pub
    /sbin/ip route add ${ifconfig_pool_remote_ip}/32 dev tun0

    Save it as /etc/openvpn/cookbook/proxyarp-connect.sh.

  3. Similarly, for the proxyarp-disconnect.sh script:

    #!/bin/bash
    /sbin/arp -i eth0 -d $ifconfig_pool_remote_ip
    /sbin/ip route del ${ifconfig_pool_remote_ip}/32 dev tun0

    Save it as /etc/openvpn/cookbook/proxyarp-disconnect.sh.

  4. Make sure that both the scripts are executable, then start the server:

    [root@server]# cd /etc/openvpn/cookbook

    [root@server]# chmod 755 proxy-connect.sh proxy-disconnect.sh

    [root@server]# openvpn --config example12-5-server.conf

  5. Next, start the client. The IP address assigned to the client should be 10.0.0.20.
  6. Use the client to browse the Internet and check its IP address by surfing for example to http://www.whatismyip.com.

How it works...

Some notes on the server configuration file, the directives:

ifconfig 10.0.0.18 255.255.255.240
ifconfig-pool 10.0.0.20 10.0.0.25

Set up a pool of (public) IP address for the clients to use. Because not all of these addresses are available in the /28 block, we cannot simply use:

server 10.0.0.18 255.255.255.240

The next statement is to ensure that the VPN server itself is reached via the regular network and not via the VPN tunnel itself:

push "route 10.0.0.27 255.255.255.255 net_gateway"

In order to redirect all traffic via the VPN tunnel, we need to explicitly state the new default gateway and redirect-gateway:

push "route-gateway 10.0.0.30"
push "redirect-gateway def1"

Normally, the following statement will also cause the topology setting to be pushed to the VPN clients:

topology subnet

But, as we're not using the server directive, this does not happen automatically. By explicitly pushing the topology, we ensure that the clients will also use the correct settings.

The client-connect and client-disconnect scripts are very similar to the ones used in the Proxy-ARP recipe (download code- ch:2). By using a handy feature of the Linux arp command, we can make the remote clients appear to be part of the local network.

There's more...

The topology subnet feature was introduced in OpenVPN 2.1. Without this feature, each client would be handed out a miniature /30 network, which means that each client would use up to four public IP addresses. This made the deployment of handing out public IP addresses to VPN clients very expensive.

OCSP support

A little known fact—the client certificate's serial number is present as an environment variable in scripts—allows OpenVPN to support the Online Certificate Status Protocol (OCSP). This recipe will show how OCSP can be set up and be supported by an OpenVPN server.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. For this recipe, the machine on which the CA certificate and private key are stored is ocsp.example.com. The server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the configuration file basic-udp-server.conf (download code- ch:2), at hand, as well as the client configuration file, basic-udp-client.ovpn (download code- ch:2).

How to do it...

  1. First, start an OCSP server by using the PKI (download code- ch:2). On the machine ocsp.example.com run:

    [ocsp]$ cd /etc/openvpn/cookbook
    [ocsp]$ openssl ocsp -index keys/index.txt -port 4444 \
    -CA keys/ca.crt -rsigner keys/ca.crt -rkey keys/ca.key \
    -resp_text

  2. Then, create the server configuration file by adding a line to the basic-udp-server.conf file:

    script-security 2
    tls-verify /etc/openvpn/cookbook/example12-6-ocsp.sh

    Save it as example12-6-server.conf.

  3. Create the tls-verify script:

    #!/bin/bash

    # if the depth is non-zero , continue processing
    [ "$1" -ne 0 ] && exit 0

    cd /etc/openvpn/cookbook
    ocsp_url="http://ocsp.example.com:4444"
    if [ -n "${tls_serial_0}" ]
    then
    status=$(openssl ocsp -issuer ca.crt -CAfile ca.crt \
    -url "$ocsp_url" \
    -serial "0x${tls_serial_0}" 2>/dev/null)
    if [ $? -eq 0 ]
    then
    # debug:
    echo "OCSP status: $status"
    if echo "$status" | grep -Fq "0x${tls_serial_0}: good"
    then
    exit 0
    fi
    else
    # debug:
    echo "openssl ocsp command failed!"
    fi
    fi
    exit 1

    This script is based on the OCSP_verify.sh script that is found in the OpenVPN 2.2 contrib directory. Save it as example12-6-ocsp.sh.

  4. Make sure the script is executable, then start the server:

    [root@server]# chmod 755 example12-6-ocsp.sh

    [root@server]# openvpn --config example12-6-server.conf

  5. Start the OpenVPN client using the basic-udp-client.ovpn configuration file.
  6. Check the log file /var/log/openvpn.log on the OpenVPN server to see the following output:

    OCSP status: 0x02: good

    And the VPN connection will have been established successfully.

How it works...

Because the client's certificate serial number is now present as the environment variable tls_serial_0, it becomes possible to support OCSP. By requesting verification with the OCSP server if a certificate is valid (that is, known and neither revoked nor expired) the server can verify that the client has been issued a valid certificate. This could also have been achieved using a Certificate Revocation List (CRL), but in some cases, an OCSP is more convenient to use, as CRLs need to be periodically updated.

New for 2.2: the 'x509_user_name' parameter

OpenVPN 2.2 is primarily a bug fix release, but there are a few new features added to version 2.2. In this recipe, we will focus on one of these features. The purpose of the x509_user_name parameter is to allow the usage of X509 certificates where the certificate name is not specified by the /CN= element. This can be especially useful when using certificates from a third-party source or when integrating certificates into other authorization systems.

Getting ready

We use the following network layout:

New Features of OpenVPN 2.1 and 2.2

Set up the client and server certificates. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.2-beta3. The client was running Windows XP SP3 and OpenVPN 2.1.3. Keep the configuration file basic-udp-server.conf (download code- ch:2) at hand, as well as the client configuration file, basic-udp-client.ovpn (download code- ch:2).

How to do it...

First, we generate a new certificate using low-level OpenSSL commands. This is because the OpenVPN-supplied easy-rsa scripts do not easily allow us to create a script without a /CN= part.

  1. Generate a new certificate request with a special subject name:

    [server]$ cd /etc/openvpn/cookbook
    [server]$ openssl req -new -nodes -keyout client6.key \
    -out client6.csr -newkey rsa:2048 \
    -subj "/C=NL/O=Cookbook/UID=cookbook"

  2. Create an empty OpenSSL extensions file to ensure that the resulting certificate is an X.509 v3 certificate:

    [server]$ touch openssl-ext.conf

  3. And finally, sign the certificate request using the CA key:

    [server]$ openssl x509 -req -CA keys/ca.crt -CAkey keys/ca.key \
    -in client6.csr -set_serial 0xAA -sha1 -days 1000 \
    -extfile openssl-ext.conf -out client6.crt

  4. Create the server configuration file by adding the followings line to the basic-udp-server.conf file:

    script-security 2
    client-connect /etc/openvpn/cookbook/example12-7-client-connect.sh

    x509-username-field "UID"

    Save it as example12-7-server.conf.

  5. Create the client-connect script:

    #!/bin/bash
    echo "common_name = [$common_name]"

    And, save it as example12-7-client-connect.sh.

  6. Make sure the script is executable, then start the server:

    [root@server]# chmod 755 example12-7-client-connect.sh

    [root@server]# openvpn --config example12-7-server.conf

  7. Copy the client6.crt and client6.key files to the Windows client using a secure channel; for example, using PuTTY's pscp command.
  8. Modify the client configuration file basic-udp-client.ovpn by changing the lines:

    cert /etc/openvpn/cookbook/client2.crt
    key /etc/openvpn/cookbook/client2.key

    to:

    cert /etc/openvpn/cookbook/client6.crt
    key /etc/openvpn/cookbook/client6.key

    Save it as example12-7.ovpn.

  9. Start the OpenVPN client:

    New Features of OpenVPN 2.1 and 2.2

  10. Check the log file /var/log/openvpn.log on the OpenVPN server to see the following output:

    common_name = [cookbook]

How it works...

With the new x509_user_name directive, OpenVPN can extract the connecting client name from a field other than the default /CN= field. In this recipe, the section /UID= was used. When a client connects with a certificate that has a subject section /UID=, the OpenVPN server extracts the client name from this field. This client name is set as the environment variable common_name for most server-side scripts and plugins, such as the client-connect, client-disconnect, and learn-address scripts, as well as the ifconfig-pool-persist file.

Note that it is not possible to use just any /<field>=<name> section as part of an X509 certificate. The <field> must be all uppercase and it must be recognized by OpenSSL itself, as otherwise it is not easily possible to generate a certificate.

There's more...

Let's examine OpenVPN 2.1 behaviour.

OpenVPN 2.1 behaviour

If the above certificate was used when connecting to an OpenVPN 2.1 server, the client would not have been able to connect. Instead, the following log message would appear in the server log file:

VERIFY ERROR: could not extract Common Name from X509 subject string
('/C=NL/O=Cookbook/UID=cookbook') -- note that the Common Name length
is limited to 64 characters

Summary

This article focused on some of the new features found in OpenVPN 2.1 and the upcoming 2.2 release. You learned to use inline certificates, connection blocks, and port-sharing.


The following articles are from the previous version book.

Further resources on this subject:


About the Author :


Jan Just Keijser

Jan Just Keijser is an open source professional from Utrecht, the Netherlands. He has broad experience in IT, ranging from providing user support, system administration, and systems programming to network programming. He has worked for various IT companies since 1989 and has been working mainly on UNIX/Linux platforms since 1995. He was an active USENET contributor in the early 1990s.

Currently, he is employed as a senior scientific programmer in Amsterdam, the Netherlands, at Nikhef, the institute for sub-atomic physics from the Dutch Foundation for Fundamental Research on Matter (FOM). He is working on grid computing and grid application programming, as well as smartcard applications.

His open source interests include all types of Virtual Private Networking, including IPSec, PPTP, and of course, OpenVPN. In 2004 he discovered OpenVPN and has been using it ever since. He has been providing OpenVPN community support since 2004.

Books From Packt


Beginning OpenVPN 2.0.9
Beginning OpenVPN 2.0.9

Alfresco 3 Business Solutions
Alfresco 3 Business Solutions

OpenVPN: Building and Integrating Virtual Private Networks
OpenVPN: Building and Integrating Virtual Private Networks

Mastering phpMyAdmin 3.3.x for Effective MySQL Management
Mastering phpMyAdmin 3.3.x for Effective MySQL Management

Liferay Portal 6 Enterprise Intranets
Liferay Portal 6 Enterprise Intranets

VirtualBox 3.1: Beginner's Guide
VirtualBox 3.1: Beginner's Guide

Building Telephony Systems with OpenSIPS 1.6
Building Telephony Systems with OpenSIPS 1.6

Amazon Web Services: Migrate your .NET Enterprise Application to the Amazon Cloud: RAW
Amazon Web Services: Migrate your .NET Enterprise Application to the Amazon Cloud: RAW


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software