Set up OpenVPN server on FreeBSD running PF packet filter firewall and run VPN client on Windows 7 and FreeBSD 8.2

Set up OpenVPN server on FreeBSD running PF packet filter firewall and run VPN client on Windows 7 and FreeBSD 8.2

OpenVPN is a free and open source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses a custom security protocol[2] that utilizes SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL)

My server has two WAN connections from two different ISP, so the setting in this tutorial allows the VPN clients to connect to the VPN server with my two public IP addresses. However, you can still use this tutorial to set up the OpenVPN server with a single WAN interface.

If you need help on how to set up multiple WAN interfaces with two different ISP:
http://gala4th.blogspot.com/2011/10/multiple-default-routes-gateways-with.html

Running OpenVPN in different scenarios:
1. Single OpenVPN instance on single interface.
2. Multiple OpenVPN instances on single interface. Ex: you want different rules for each set of VPN clients.
3. Single OpenVPN instance on each of multiple interfaces.
4. Multiple OpenVPN instance on each of multiple interfaces.

We will set up OpenVPN in "Single OpenVPN instance on each of multiple interfaces" scenario.

Install OpenVPN:
# cd /usr/ports/security/openvpn
# make config-recursive
# make config-recursive
# make config-recursive

Note: run "make config-recursive" few times. You may enable a dependency the first time through that has its own configuration options.

# make install

# mkdir /usr/local/etc/openvpn

This /usr/local/etc/rc.d/openvpn script supports running multiple instances of openvpn. To run additional instances link this script to something like:

For example:
# ln -s openvpn openvpn_foo

and define additional openvpn_foo_* variables in one of:
/etc/rc.conf, /etc/rc.conf.local or /etc/rc.conf.d/openvpn_foo

A list of avaiable interface on my server:

# ifconfig -l | tr ' ' '\n'
wan0 // IP 11.11.11.11. First WAN interface for my first ISP.
wan1 // IP 22.22.22.22. Second WAN interface for my second ISP.
dmz0 // IP 192.168.100.1 and 192.168.100.2. DMZ interface.
lan0 // IP 192.168.200.1 and 192.168.200.2. LAN interface.
tun0 // IP 10.8.0.1. First VPN interface for VPN clients connecting to first WAN interface.
tun1 // IP 10.9.0.1. Second VPN interface for VPN clients connecting to second WAN interface.

# vim /etc/rc.conf
ifconfig_wan0="inet 11.11.11.11 netmask 255.255.255.0"
ifconfig_wan1="inet 22.22.22.22 netmask 255.255.255.0"

ifconfig_dmz0="inet 192.168.100.1 netmask 255.255.255.0"
ifconfig_dmz0_alias0="inet 192.168.100.2 netmask 255.255.255.255"

ifconfig_lan0="inet 192.168.200.1 netmask 255.255.255.0"
ifconfig_lan0_alias0="inet 192.168.200.2 netmask 255.255.255.255"

// Note: do this if you want to run one instance of OpenVPN on each of two interfaces.
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_wan0
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_wan1

Sample configuration files can be found in:
# ls -l /usr/local/share/doc/openvpn/sample-config-files

Copy the OpenVPN config file
# cp /usr/local/share/doc/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/openvpn_wan0.conf

# cp /usr/local/share/doc/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/openvpn_wan1.conf

Note: The reason why we need to rename the config filename from server.conf to openvpn_foo.conf is because the /usr/local/etc/rc.d/openvpn script supports running multiple instances of openvpn. The openvpn script will try to read the config from the SCRIPT_NAME.conf. For example:

If you are startup script is called /usr/local/etc/rc.d/openvpn_wan0, it will read config file from /usr/local/etc/openvpn/openvpn_wan0.conf.

Edit OpenVPN config file:
# vim /usr/local/etc/openvpn/openvpn_wan0.conf
### Specify device
dev tun

### Which local IP address should OpenVPN
### listen on? (optional)
local 11.11.11.11

### Certificates for VPN Authentication
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key # This file should be kept secret

### Diffie hellman parameters
dh /usr/local/etc/openvpn/keys/dh1024.pem

### Server and client IP and Pool
### The server will take 10.8.0.1 for itself,
### the rest will be made available to clients.
server 10.8.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

### Routes to push to the client.
### The specified network will be added automatically on the VPN client.
push "route 192.168.0.0 255.255.255.0"

### Enable compression on the VPN link.
### If you enable it here, you must also
### enable it in the client config file.
comp-lzo

### Make the link more resistant to connection failures
keepalive 10 120
persist-tun
persist-key

### optional ?
#ping-timer-rem

# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on non-Windows systems.
# By specifying 'nobody' OpenVPN service privileges are
# dropped to nobody. This increases system security.
user nobody
group nobody

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
;log openvpn.log
log-append /var/log/openvpn_wan0.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

For openvpn_wan1.conf, most settings are similar to the previous openvpn_wan0.conf file, except:

# vim /usr/local/etc/openvpn/openvpn_wan1.conf
### Which local IP address should OpenVPN
### listen on? (optional)
local 22.22.22.22

### Server and client IP and Pool
### The server will take 10.9.0.1 for itself,
### the rest will be made available to clients.
server 10.9.0.0 255.255.255.0

log-append /var/log/openvpn_wan1.log

Review the difference between openvpn_wan0.conf and openvpn_wan1.conf:
# diff /usr/local/etc/openvpn/openvpn_wan0.conf /usr/local/etc/openvpn/openvpn_wan1.conf

Logging
# touch /var/log/openvpn_wan0.log
# touch /var/log/openvpn_wan1.log

Rotate OpenVPN log files:
# vim /etc/newsyslog.conf
/var/log/openvpn_wan0.log 600 9 100000 * JC /var/run/openvpn_wan0.pid
/var/log/openvpn_wan1.log 600 9 100000 * JC /var/run/openvpn_wan1.pid

# /etc/rc.d/newsyslog restart

Copy easy-rsa script to the home directory
# cp -r /usr/local/share/doc/openvpn/easy-rsa ~
# find ~/easy-rsa/ -type d -print0 | xargs -0 -I @ chmod 700 @
# find ~/easy-rsa/ -type f -print0 | xargs -0 -I @ chmod 400 @

Make sure these scripts are executable:
# find ~/easy-rsa/2.0/ -type f -print0 | xargs -0 -I @ chmod u+x @

Change follow lines in vars file to reflect your setting:
# cd ~/easy-rsa/2.0/
# vim ~/easy-rsa/2.0/vars
### These are the default values for fields
### which will be placed in the certificate.
### Don't leave any of these fields blank.
export KEY_COUNTRY="CA"
export KEY_PROVINCE="BC"
export KEY_CITY="Vancouver"
export KEY_ORG="Fort-Funston Ltd"
export KEY_EMAIL="me@myhost.mydomain"
export KEY_CN="CommonName_Can_Be_YourName_or_HostName"
export KEY_NAME="YourName"
export KEY_OU="UnitName_or_DepartmentName"
export PKCS11_MODULE_PATH="dummy"
export PKCS11_PIN="A_RANDOM_PASSWORD"

Very Important Step for FreeBSD/TCSH users. FreeBSD ships with tcsh as its native shell, at the time of writing the following scripts do not work. To get around this you must drop down to a bourne shell. To do this just type the following at a prompt:

# sh
# cd ~/easy-rsa/2.0/

Now you can carry on with building the certificates, once you have built them you can exit back out to tcsh.

Sourcing the vars file and other scripts:
# . vars
# ./clean-all
# ./build-ca

You will have to answer a few questions on the last step, once this has been done your CA certs will be created in the keys subdirectory.

Generate certificate & key for server:
# ./build-key-server server
A challenge password []: LEAVE IT BLANK AND PRESS ENTER
An optional company name []: LEAVE IT BLANK AND PRESS ENTER

Again answer the questions and the certs will be placed in the keys subdirectory.

Generate certificates & keys for 3 clients (each client will require their own certificates, if multiple clients log in with the same certs then they will be assigned the same ips and will kick each other off the network):

Generating client certificates is very similar to the previous step. You need to ensure that all your details are the same as for the CA, apart from the common name, which needs to be different for each client. For the sake of clarity this should relate to person who is assigned this vpn certificate. All of these details can be found in keys/server.crt for the server and keys/client*.crt for the client details.

# ./build-key client1
# ./build-key client2
# ./build-key client3

Generate Diffie Hellman parameters

Diffie Hellman parameters must be generated for the OpenVPN server:

# ./build-dh

Exit the sh shell:
# exit

Now move the whole keys directory to /usr/local/etc/openvpn:

# mv ~/easy-rsa/2.0/keys /usr/local/etc/openvpn/

Protect our certificate keys directory and config files for only root can see it.
# find /usr/local/etc/openvpn/keys/ -type d -print0 | xargs -0 -I @ sh -c 'chmod 700 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/keys/ -type f -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/ccd -type d -print0 | xargs -0 -I {} chmod 755 {}
# find /usr/local/etc/openvpn/ccd -type f -print0 | xargs -0 -I {} chmod 644 {}
# find /usr/local/etc/openvpn/ -type f -name '*.conf' -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'

Note: ccd directory and files under the ccd directory must be readable.

You need to edit /etc/rc.conf if you set up single instance of OpenVPN with single interface:

Note: I have commented out following lines because I set to start OpenVPN daemon in /etc/rc.local later.

# vim /etc/rc.conf
#openvpn_wan0_enable="YES"
#openvpn_wan0_configfile="/usr/local/etc/openvpn/openvpn_wan0.conf"

#openvpn_wan1_enable="YES"
#openvpn_wan1_configfile="/usr/local/etc/openvpn/openvpn_wan1.conf"

We will be using the setfib command to run our utilities with an different routing table: 

Note: You do not need the setfib command if you are hosting your OpenVPN server with single WAN interface.

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rtable0
# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rtable1

Edit sshd_config.* config file:
# vim /etc/ssh/sshd_config.rtable0
### IP address of first WAN interface
ListenAddress 11.11.11.11
### IP address of DMZ interface
ListenAddress 192.168.100.1
### IP address of LAN interface
ListenAddress 192.168.200.1

# vim /etc/ssh/sshd_config.rtable1
### IP address of second WAN interface
ListenAddress 22.22.22.22
### IP address of DMZ interface
ListenAddress 192.168.100.2
### IP address of LAN interface
ListenAddress 192.168.200.2

Note: Multiple ListenAddress options are permitted.

Note: you can let sshd to listen to the IP address of the tunnel interface. However, I do not recommend you do so. Because if OpenVPN did not start properly, sshd will have problem to start as well (because it could not listen to the specified IP address).

Edit rc.local:
# vim /etc/rc.local
### add first routing table for first WAN interface for first ISP network.
/usr/sbin/setfib 0 /sbin/route delete default
/usr/sbin/setfib 0 /sbin/route add default 11.11.11.11

### add second routing table for second WAN interface for second ISP network.
/usr/sbin/setfib 1 /sbin/route delete default
/usr/sbin/setfib 1 /sbin/route add default 22.22.22.22

### start OpenVPN on the first WAN interface.
/usr/sbin/setfib 0 /usr/local/etc/rc.d/openvpn_wan0 onestart

### start OpenVPN on the second WAN interface.
/usr/sbin/setfib 1 /usr/local/etc/rc.d/openvpn_wan1 onestart

### Use different routing table for each sshd daemon.
### Note: we need to start SSH after OpenVPN started
### since the IP address of tunnel interface (for VPN) has been listened by sshd,
### which is defined in the sshd_config.rtable0 and sshd_config.rtable1 config file.
### Note: make sure the line 'sshd_enable="YES"' has bee commented out
### or removed from /etc/rc.conf file. We will start sshd in /etc/rc.local file.
/usr/sbin/setfib 0 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable0
/usr/sbin/setfib 1 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable1

### Flush PF rules after OpenVPN and SSH daemons started
### Note: the reason is because there are some settings related to these VPN
### interface tun0 and tun1. So we need to flush the PF rules after OpenVPN loaded.
/sbin/pfctl -f /etc/pf.conf

Comment out or remove sshd_enable="YES" line in /etc/rc.conf:
# vim /etc/rc.conf
### Note: commented out for multiple WAN routes setup. SSH daemon will be started in /etc/rc.local file.
#sshd_enable="YES"

Let's start OpenVPN server manually now:

# setfib 0 /usr/local/etc/rc.d/openvpn_wan0 onestart
Starting openvpn_wan0.
add net 10.8.0.0: gateway 10.8.0.2

# setfib 1 /usr/local/etc/rc.d/openvpn_wan1 onestart
Starting openvpn_wan1.
add net 10.9.0.0: gateway 10.9.0.2

Make sure the network and the gateway have been correctly added:

# setfib 0 netstat -rn | egrep '10.[8|9].0'
10.8.0.0/24 10.8.0.2 UGS 0 0 tun0
10.8.0.1 link#6 UHS 0 0 lo0
10.8.0.2 link#6 UH 0 0 tun0
10.9.0.1 link#7 UHS 0 0 lo0
10.9.0.2 link#7 UH 0 0 tun1

# setfib 1 netstat -rn | egrep '10.[8|9].0'
10.8.0.2 link#6 UH 0 0 tun0
10.9.0.0/24 10.9.0.2 UGS 0 0 tun1
10.9.0.2 link#7 UH 0 0 tun1

In some cases, the network did not be added successfully, you will need to add the network maually:
# setfib 0 route add 10.8.0.0/24 10.8.0.2
# setfib 1 route add 10.9.0.0/24 10.9.0.2

You should have seen two different IP addresses are listening port 1194:

# netstat -an | grep 1194
udp4 0 0 11.11.11.11.1194 *.*
udp4 0 0 22.22.22.22.1194 *.*

You should have seen two different process IDs are running:

# ls -l /var/run/openvpn*.pid
-rw-r--r-- 1 root wheel 6 Dec 5 15:49 /var/run/openvpn_wan1.pid
-rw-r--r-- 1 root wheel 6 Dec 5 15:44 /var/run/openvpn_wan0.pid

# ifconfig | grep tun
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500

Let's start ssh daemon now:
# /usr/sbin/setfib 0 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable0
# /usr/sbin/setfib 1 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable1

See port 22 is binding to which IP addresses:
# netstat -an | grep 22
tcp4 0 0 11.11.11.11.22 *.* LISTEN
tcp4 0 0 192.168.100.1.22 *.* LISTEN
tcp4 0 0 192.168.200.1.22 *.* LISTEN
tcp4 0 0 10.8.0.1.22 *.* LISTEN
tcp4 0 0 22.22.22.22.22 *.* LISTEN
tcp4 0 0 192.168.100.2.22 *.* LISTEN
tcp4 0 0 192.168.200.2.22 *.* LISTEN
tcp4 0 0 10.9.0.1.22 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN

To show listening/opening TCP port:
# sockstat -Ptcp

To show listening/opening UDP port:
# sockstat -Pudp

Note: man sockstat

Restart the machine and re-check everything is fine after reboot:
# sync; sync; sync; reboot

Edit pf.conf PF firewall setting:
# vim /etc/pf.conf
wan_if0 = "wan0"
wan_if1 = "wan1"

dmz_if = "dmz0"
lan_if = "lan0"

### Note: the reason why we specified VPN network below is because we want to avoid
### PF parse host specification error. Since PF runs before OpenVPN starts,
### PF could not figure it out the VPN network until OpenVPN started.
vpn_if0 = "tun0"
vpn_net0 = '"10.8.0.0/24"'
vpn_if1 = "tun1"
vpn_net1 = '"10.9.0.0/24"'

icmp_types = "{echoreq echorep unreach}"

### [NAT] the VPN connections (for access to the remote secure networks)
nat on $wan_if0 from $vpn_net0to any -> $wan_if0
nat on $wan_if1 from $vpn_net1 to any -> $wan_if1

### [VPN] Inbound from Outside
### Establish VPN connections on each WAN interface.
pass in quick on $wan_if0 proto udp from any to $wan_if0 port 1194 keep state rtable 0
pass in quick on $wan_if1 proto udp from any to $wan_if1 port 1194 keep state rtable 1

### [SSH] Inbound from VPN to ANY
pass in quick log on $vpn_if0 proto tcp from $vpn_net0to any port 22 flags S/SA keep state rtable 0
pass in quick log on $vpn_if1 proto tcp from $vpn_net1 to any port 22 flags S/SA keep state rtable 1

### [SSH] Outbound to LAN
pass out quick log on $lan_if proto tcp from {$dmz_if/24 $lan_if/24 $vpn_if0/24} to $lan_if/24 port 22 flags S/SA keep state rtable 0
pass out quick log on $lan_if proto tcp from {$vpn_net1} to $lan_if/24 port 22 flags S/SA keep state rtable 1

### [SSH] Outbound to DMZ
pass out quick log on $dmz_if proto tcp from {$dmz_if/24 $lan_if/24 $vpn_if0/24} to $dmz_if/24 port 22 flags S/SA keep state rtable 0
pass out quick log on $dmz_if proto tcp from {$vpn_net1} to $dmz_if/24 port 22 flags S/SA keep state rtable 1

### [ICMP] Inbound from VPN
pass in quick on $vpn_if0 proto icmp from $vpn_net0to any icmp-type $icmp_types rtable 0
pass in quick on $vpn_if1 proto icmp from $vpn_net1 to any icmp-type $icmp_types rtable 1

### [ICMP] Inbound from Outside
pass in quick log on $wan_if0 proto icmp from any to $wan_if0 icmp-type $icmp_types rtable 0
pass in quick log on $wan_if1 proto icmp from any to $wan_if1 icmp-type $icmp_types rtable 1

### [ICMP] Outbound to Outside
pass out quick on $wan_if0 proto icmp from $wan_if0 to any icmp-type $icmp_types rtable 0
pass out quick on $wan_if1 proto icmp from $wan_if1 to any icmp-type $icmp_types rtable 1

### [ICMP] Outbound to LAN
pass out quick log on $lan_if proto icmp from {$lan_if $dmz_if/24 $vpn_if0/24} to $lan_if/24 icmp-type $icmp_types rtable 0
pass out quick log on $lan_if proto icmp from {$vpn_net1} to $lan_if/24 icmp-type $icmp_types rtable 1

### [ICMP] Outbound to DMZ
pass out quick log on $dmz_if proto icmp from {$dmz_if $lan_if/24 $vpn_if0/24} to $dmz_if/24 icmp-type $icmp_types rtable 0
pass out quick log on $dmz_if proto icmp from {$vpn_net1} to $dmz_if/24 icmp-type $icmp_types rtable 1

Watch the pflog logged packets in real time:
# tcpdump -n -e -ttt -i pflog0

Watch the icmp packect of an interface:
# tcpdump -ni wan0 icmp
# tcpdump -ni wan1 icmp
# tcpdump -ni dmz0 icmp
# tcpdump -ni tun0 icmp
# tcpdump -ni tun1 icmp

# tcpdump -tt -i tun0

# tail /usr/local/etc/openvpn/openvpn-status.log

# tail /var/log/openvpn_wan0.log

# tail /var/log/openvpn_wan1.log

# tail /var/log/messages

Download OpenVPN 2.2.1 client for Windows:
http://openvpn.net/index.php/open-source/downloads.html

Once this is installed you will need to copy the following files from your server /usr/local/etc/openvpn/keys directory to the Windows PC C:\Program Files\Openvpn\config directory (this should be done in as secure a manner as possible, i.e. USB Stick or floppy rather than email!!!):

ca.crt
client1.crt
client1.key

Note: For the next client you will need to copy the client2.crt and client2.key files to prevent issues later.

Create VPN config file:

create a myvpn.ovpn file in C:\Program Files\Openvpn\config and insert the following:

client
remote nic1.myserver.com 1194
#remote nic2.myserver.com 1194
dev tun
comp-lzo

ca ca.crt
cert client1.crt
key client1.key

# Set log file verbosity.
verb 3

Turn off the firewall for the new Interface:

On Windows XP, the firewall can be accessed by:
Control Panel -> Security Center -> Windows Firewall -> Advanced. In the Network Connection Settings control, uncheck the box corresponding to the TAP-Win32 adapter.

Now right-click the OpenVPN Icon in your Taskbar and click "connect". Once connected try pinging the remote interface and check (using tracert) that the remote network is available. Use tcpdump on the server to check traffic too:

On Windows 7, you must run OpenVPN as an administrator by:

right click on openvpn-gui-1.0.3.exe > Property > Shortcut > Run this program as an administrator

or

right click on openvpn-gui-1.0.3.exe > Property > Compatibility > Run this program as an administrator

cmd> tracert

cmd> ping 10.8.0.1
cmd> ping 10.9.0.1

Use Firewall's VPN IP address to connecto the firewall:
cmd> putty.exe username@10.8.0.1
cmd> putty.exe username@10.9.0.1

Note: If you want to ssh to the IP address of the firewall's LAN/DMZ interface, make sure you do set up your sshd to listen to these IP addresses with proper routing table.

Use FreeBSD as a VPN client:

# cd /usr/ports/security/openvpn
# make config-recursive
# make config-recursive
# make config-recursive

Note: run "make config-recursive" few times. You may enable a dependency the first time through that has its own configuration options.

# make install

Link the openvpn startup script:
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_client

Create OpenVPN directory:
# mkdir -p /usr/local/etc/openvpn/keys

Put following three files to /usr/local/etc/openvpn/keys:
ca.crt
client1.crt
client1.key

Protect our certificate keys directory and config files for only root can see it.
# find /usr/local/etc/openvpn/keys/ -type d -print0 | xargs -0 -I @ sh -c 'chmod 700 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/keys/ -type f -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/ -type f -name '*.conf' -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'

You will need to copy the client.conf instead of server.conf from /usr/local/share/doc/openvpn/sample-config-files directory:
# cp /usr/local/share/doc/openvpn/sample-config-files/client.conf /usr/local/etc/openvpn/openvpn_client.conf

Edit openvpn_client.conf:
# vim /usr/local/etc/openvpn/openvpn_client.conf
client
dev tun
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 11.11.11.11 1194
;remote my-server-2 1194

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/client1.crt
key /usr/local/etc/openvpn/keys/client1.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
ns-cert-type server

# vim /etc/rc.conf
openvpn_client_enable="YES"
openvpn_client_configfile="/usr/local/etc/openvpn/openvpn_client.conf"

Start OpenVPN client:
# /usr/local/etc/rc.d/openvpn_client start

# tail -F /var/log/messages

# ifconfig
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
Opened by PID 98483

Display the full output line of ps process status command:
# ps -auxww | grep openvpn
nobody 1015 /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon openvpn_wan0 --config /usr/local/etc/openvpn/openvpn_wan0.conf --writepid /var/run/openvpn_wan0.pid
nobody 1035 /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon openvpn_wan1 --config /usr/local/etc/openvpn/openvpn_wan1.conf --writepid /var/run/openvpn_wan1.pid

# ls -l /var/run/openvpn*
-rw-r--r-- 1 root wheel 6 Dec 21 12:53 /var/run/openvpn_client.pid

===
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).

push "redirect-gateway def1 bypass-dhcp"
===
Fixed IP addresses for OpenVPN clients

# vim /usr/local/etc/openvpn.conf
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
client-config-dir ccd
route 10.8.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2

# mkdir /usr/local/etc/openvpn/ccd

Modify the permission:
# find /usr/local/etc/openvpn/ccd -type d -print0 | xargs -0 -I {} chmod 755 {}
# find /usr/local/etc/openvpn/ccd -type f -print0 | xargs -0 -I {} chmod 644 {}

The ifconfig push pushes addresses in a /30 network unless you are using
infrastructure mode.

the correct notation should be in a /30 network e.g.

ifconfig-push 10.200.200.9 10.200.200.10
http://openvpn.net/archive/openvpn-users/2007-07/msg00084.html

In default mode openvpn assigns miniature /30 networks to each VPN client:

server
10.8.0.0 : network address
10.8.0.1 : server IP address
10.8.0.2 : virtual remote endpoint; only used for routing
10.8.0.3 : network broadcast address

first client
10.8.0.4 : network address
10.8.0.5 : virtual remote endpoint; non pingable; only used for routing
10.8.0.6 : client IP address
10.8.0.7 : network broadcast address

second client : 10.8.08 - 10.8.0.11
third client : 10.8.012 - 10.8.0.15

etc. So a valid network block for a client is 10.8.0.24 - 10.8.0.27:
10.8.0.24 : network address
10.8.0.25 : virtual remote endpoint; non pingable; only used for routing
10.8.0.26 : client IP address
10.8.0.27 : network broadcast address

to use this network the ccd file needs to contain
Code:
ifconfig-push 10.8.0.26 10.8.0.25

(note that the HOWTO on the openvp.net erroneously swaps the IPs!)
http://forums.openvpn.net/topic8215.html
===
Difference Between TUN and TAP

In computer networking, TUN and TAP are virtual network kernel devices. They are network devices that are supported entirely in software, which is different from ordinary network devices that are backed up by hardware network adapters.

TAP (as in network tap) simulates an Ethernet device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.

Packets sent by an operating system via a TUN/TAP device are delivered to a user-space program that attaches itself to the device. A user-space program may also pass packets into a TUN/TAP device. In this case TUN/TAP device delivers (or "injects") these packets to the operating system network stack thus emulating their reception from an external source.
===
As far as I could see, tap allows netbios broadcast to propagate across the
VPN so Windows clients can find network shares by PC name even if no WINS
server is being used; with tun, either you find network shares in some other
way (by IP or DNS, for example) or you need to have WINS running (which often
amounts to "wins proxy = yes" in smb.conf).

On the other hand, I do not feel comfortable in having VPN clients appear as
if physically attached to the LAN (this is what bridging with TAP amounts to)
and prefer routing with tun as it makes easier to write appropriate firewall
rules for VPN clients.
===
if it's ok to create vpn on layer 3 [ one more hop between subnets ] - go for tun.

if you need to bridge two ethernet segments in two different locations - then use tap. in such setup you can have computers in the same ip subnet [ eg 10.0.0.0/24 ] on both ends of vpn, and they'll be able to 'talk' to each other directly without any changes in their routing tables. vpn will act like ethernet switch. this might sound cool and is useful in some cases but i would advice not to go for it unless you really need it. if you choose such layer 2 bridging setup - there will be a bit of 'garbage' [ that is broadcast packets ] going across your vpn.
===
I always set up tun. Tap is used by ethernet bridging in OpenVPN and introduces an unprecendented level of complexity that is simply not worth bothering with. Usually when a VPN needs to be installed, its needed now, and complex deployments don't come fast.
===
I chose "tap" when setting up a VPN for a friend who owned a small business because his office uses a tangle of Windows machines, commercial printers, and a Samba file server. Some of them use pure TCP/IP, some seem to only use NetBIOS (and thus need Ethernet broadcast packets) to communicate, and some I'm not even sure of.

If I had chosen "tun", I would probably have faced lots of broken services — lots of things that worked while you are in the office physically, but then would break when you went off-site and your laptop couldn't "see" the devices on the Ethernet subnet anymore.

But by choosing "tap", I tell the VPN to make remote machines feel exactly like they're on the LAN, with broadcast Ethernet packets and raw Ethernet protocols available for communicating with printers and file servers and for powering their Network Neighborhood display. It works great, and I never get reports of things that don't work offsite!
===
I started out using tun, but switched to tap since I didn't like the use of a /30 subnet for each PC (I need to support Windows). I found that to be wasteful and confusing.

Then I discovered the "topology subnet" option on the server. Works with the 2.1 RCs (not 2.0), but it gives me all the advantages of tun (no bridging, performance, routing, etc) with the convenience of one (sequential) IP address per (windows) machine.
===
What All Ports Are Rrequired By Domain Controllers And Client Computers?

Active Directory communication takes place using several ports. These ports are required by both client computers and Domain Controllers. As an example, when a client computer tries to find a domain controller it always sends a DNS Query over Port 53 to find the name of the domain controller in the domain.

The following is the list of services and their ports used for Active Directory communication:

UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
TCP and UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.
Opening above ports in Firewall between client computers and domain controllers, or between domain controllers, will enable Active Directory to function properly.

http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/AdminTips/ActiveDirectory/WhatAllPortsAreRrequiredByDomainControllersAndClientComputers.html
===
Reference:
http://blog.ijun.org/2011/12/set-up-openvpn-server-on-freebsd.html
http://kuapp.com/2010/07/01/openvpn-with-freebsd-pf-and-windows-xp.html
http://www.secure-computing.net/wiki/index.php/FreeBSD_OpenVPN_Server/Routed
http://en.wikipedia.org/wiki/TUN/TAP
http://openvpn.net/archive/openvpn-users/2007-02/msg00184.html
http://serverfault.com/questions/21157/should-i-use-tap-or-tun-for-openvpn
http://forums.freebsd.org/showthread.php?t=15213
http://en.wikipedia.org/wiki/OpenVPN