Configuring an OpenVPN Multisite VPN Bridge Using Public Key Infrastructure (PKI)


This article covers a case-scenario in which two offices, each with a dedicated pfSense router, join together as one logical network using OpenVPN.

TUN and TAP are virtual network kernel devices, i.e. they are not backed by hardware network adapters (e.g. pci, pci-e card).

TAP is short for network tap:

  • Simulates an Ethernet device
  • Operates with layer 2 packets such as Ethernet frames

TUN is short for network tunnel:

  • Simulates a network layer device
  • Operates with layer 3 packets such as IP packets

TAP is used to create a network bridge, while TUN is used with routing.

I’ve worked with two modes of OpenVPN: Routing (TUN) and Bridging (TAP)
Routing: From what I gather, this is better for a network tunnel between client(s) where primarily point-to-point connections are required.
Bridging: From what I gather, this is better for a network tunnel between network(s) wherein ALL traffic, including broadcasts, is a requirement.
This document covers OpenVPN in Bridging (TAP) mode.
Note: From what I researched, you cannot bridge different subnets.
Bridging can only connect two segments which use the same IP subnet.
To connect different subnets you need to use IP routing.

The network configuration in this document allows broadcasts to span the network bridge.
As such, broadcasts like DHCP will traverse the bridge both ways.
Possible problems this might present:
When started, each DHCP client broadcasts a DHCP discover message (DHCPDISCOVER) to its local subnet in an attempt to find a DHCP server.
Because DHCP clients use broadcasts during their initial startup, you cannot predict which server will respond to the DHCP discover request of a client if more than one DHCP server is active on the same subnet.
This can lead to unexpected results.
One searing example is a client picking up default gateways belonging to a network that lies across the bridge.
Imagine a client from Florida using the default gateway from the site in New Jersey! No Bueno.
Luckily, there is a workaround. Block DHCP traffic from traversing the network bridge.
The instructions for this are included in the document.

The Big Picture


The network we’re working with is, with a network mask of, or 172.16.0/16.
This is essentially one giant network.
This allows for a wide range of Private IP Addresses: 172.16.(1-254).(1-254) all under one broadcast domain.
This is what I needed for my setup.
Network configuration illustrated above: two different subnets that are part of the same broadcast domain.

Create Certificate Authority

  1. Login to the web admin
  2. Click System –> Cert Manager
  3. From the CAs leaf, click the Plus button
  4. Give it descriptive name.
  5. Method: ‘Create an internal Certificate Authority‘, leave Key length and Lifetime to default.
  6. Fill in the rest of the fields as you see fit.
  7. Click Save
  8. Once this is done, we need to create our certificates for the OpenVPN server as well as any users/sites we want to connect.

Create the Server Certificate

  1. The process for creating a Cert for the server and users are almost identical. Let’s create the Server Certificate.
  2. The OpenVPN server (pfsense) must have its own cert as well as any users.
  3. Click the Certificates leaf, click the plus button.
  4. In the Method Drop down box make sure it says "Create an Internal Certificate"
  5. Give a descriptive name. A good idea is to specify server/username
  6. In the Certificate Authority drop down choose the CA you just created.
  7. In Certificate Type drop down specify whether this Cert is for the server or a user. In this case, it is a ‘Server Certificate’
  8. Fill out the rest of the info for location.
  9. Click Save

Create the User Certificate(s)

  1. Repeat the previous process, but selecting ‘User Certificate’ for the Certificate Type. Create as many certs as you need ensuring that all are based off the original CA created earlier.
  2. Click Save

Create a Certificate Revocation List


Its a good idea to create a revocation list.
Doing so allows for easily revoking client connections should the need arise.
No need to disable the OpenVPN server entirely, or delete any client certificates, or manually kill connections, nothing ugly.
To create a revocation list:
Click the Cert Revocation leaf
Press the plus button next to the CA you created.
Method: Create an internal Cert Revo list.
Give it a name and verify the CA is in the drop down box.
Click Save.
You’ll notice a new line with an edit button.
This is where you can revoke or restore certificates for users.
Congrats, you should now have the PKI in place!

Install Package: OpenVPN Bridge Fix


There is no tunnel network when using tap/bridging mode, yet the PfSense 2.0 gui required you to enter one.
This essentially wouldn’t allow you to do this through the gui.
Thankfully after user ‘jadams’ brought this to their attention, they released a package to fix this problem.
To install this package:

  1. Click System —> Packages
  2. Click the Available Packages Tab
  3. Install the OpenVPN tap Bridging Fix package

OpenVPN Server Setup – Section:General Information

  1. Click VPN —> OpenVPN
  2. In the Server leaf, click the plus button to add a server.
  3. Disables the server: unchecked (obviously)
  4. Server Mode: Remote Access (SSL/TLS)
  5. Protocol: UDP
  6. Device Mode: TAP
  7. Interface: WAN
  8. Local port: 1194 (default port but you can choose whatever port you like)
  9. Description: *************

OpenVPN Server Setup – Section:Cryptographic Settings

  1. TLS Authentication: Check both check boxes
  2. Peer Certificate Authority: Use the CA we created earlier
  3. Peer Revoke List: use the revoke list creates earlier
  4. Server Certificate: This is where you use the Server Certificate created earlier, NOT any of the User certs
  5. DH Parameters Length: I set mine to 1024
  6. Encryption Algorithm: I used AES-128-CBC
  7. Hardware Crypto: I used the BSD Cryptodev engine, as the system is on an Intel Atom with 2GB of RAM
  8. Cert Depth: One

OpenVPN Server Setup – Section:Tunnel Settings


Note:Here’s a classic Catch-22: If you want to bridge the OpenVPN tunnel with your LAN, you must first create the bridge, BUT, you can’t create the Bridge without first creating the OpenVPN tunnel!
Solution: Proceed with OpenVPN Server setup without enabling any bridge functionality.
Then, once that is complete, you create the bridge, revisit the OpenVPN server settings, and enable the option.
Ok, now back to Tunnel Settings:

  1. Tunnel Network: leave Blank. No tunnel network with Bridging (see info at top if you’re curious as to why)
  2. Bridge DHCP: This box may not yet be available (Catch-22, we revisit after we setup this OpenVPN tunnel and create the bridge)
  3. Bridge Interface: Again, we revisit after we setup this OpenVPN tunnel and create the bridge. This will be set to your LAN interface.
  4. Server DHCP Start/Stop: You can specify an IP range here. However since its bridging you can leave it blank. Your internal DHCP server will take care of it. I left these blank. One thing to keep in mind is that a client’s IP will not be displayed on the Dashboard Widget if you leave the range blank. I’ll be bringing this up on the PfSense forums.
  5. Redirect Gateway: SEE NOTE AT THE END
  6. Concurrent Connections: self explanatory, I left this blank.
  7. Compression: I checked this
  8. TOS: I left unchecked
  9. Inter-client communication: If you want different remote clients to be able to talk to each other check this box
  10. Duplicate connections: This will allow different people with the same certs you give them to connect. Not recommended, but I’m sure theres instances where it might be required.

OpenVPN Server Setup – Section:ClientSettings

  1. Dynamic IP: checked
  2. Address Pool: unchecked
  3. DNS Default domain: if you have one enter it here
  4. DNS Servers: specify up to 4
  5. NTP Server: you can specify up to 2
  6. Wins Server: if you have one

OpenVPN Server Setup – Section:Advanced Settings


Here you can setup additional routes. I left this blank.
This is the last section in the OpenVPN Server setup.
Click the Save button.

Create the LAN/OpenVPN Bridge


Click Interfaces —> Assign
Press the + button to add an interface
It will probably show up as OPT1, in the drop down box choose your OpenVPN instance
goto Interfaces —> OPT1
Enable the Interface
Give it a better description
Leave the rest default.
While still in the Interfaces —> Assign click the Bridges tab
Press the plus button to create a bridge.
Choose TWO or more interfaces you want to bridge (e.g. your LAN, and the interface we just made for your OpenVPN server) by clicking on them using the CTRL button
Give it a description

Create OpenVPN LAN Bridge

  1. Click Interfaces —> Assign
  2. Click the plus button to add an interface.
  3. It will probably show up as OPT1 in the drop down box.
  4. Choose the interface matching the OpenVPN instance you want to bridge.
  5. Click Interfaces —> OPT1
  6. Enable the Interface, give it a more appropriate description (e.g. OpenVPN)
  7. Leave the rest default.
  8. Click Save
  9. Click Interfaces —> Assign
  10. Click the Bridges leaf.
  11. Press the plus button to create a bridge.
  12. Choose TWO interfaces you want to bridge (your LAN, and the interface we just made for your OpenVPN server) by clicking on them using the CTRL button.
  13. Give it an appropriate description and click SAVE.

OpenVPN Server Setup (Revisit) – Section:Tunnel Settings – DHCP Start/DHCP End


Bridge DHCP: If and Only If (IFF) you correctly configured the bridge, OpenVPN bridge options should now be available.
Place a check mark on “Allow clients on the bridge to obtain DHCP”
Bridge Interface: Set this your LAN interface.
Click Save at the bottom.
Note: The image in this step illustrates using an ip address range as the DHCP Start and DHCP End,
but you can leave these blank if you plan on having IP Addresses assigned by the default DHCP Server settings on the pfSense box (if applicable)
or by a dedicated DHCP server on your network.
In my case, I set the address to a scope of 15 IP Addresses that lay OUTSIDE of my DHCP server’s IP Address range.

Server Firewall Rule: Allow OpenVPN Connection to WAN Port

  1. Click Firewall —> Rules
  2. Click the WAN leaf, click the plus button to add a rule.
  3. Action: Pass
  4. Disabled: unchecked
  5. Interface: WAN
  6. Protocol: UDP
  7. Source: any
  8. Destination: WAN Address
  9. Destination Port Range: This is the port of your OpenVPN server (Mine is set to the default 1194)
  10. Give it a description (e.g. ‘Allow OpenVPN to WAN’)
  11. Click Save

Server Firewall Rule: Open the Floodgates, Allow All Bridged OpenVPN Traffic

  1. Click Firewall —> Rules
  2. Click the OpenVPN leaf, click the plus button to add a rule.
  3. Action: Pass
  4. Disabled: unchecked
  5. Interface: OpenVPN
  6. Protocol: any
  7. Source: any
  8. Destination: any
  9. Destination Port Range: any
  10. Give it a description (e.g. Allow OpenVPN Traffic from Clients)
  11. Click Save


  1. Click the leaf corresponding to your OpenVPN Tap Interface (e.g. OPENVPNTAP,OVPN)
  2. Do the same as you did for the OpenVPN Leaf

Export Certificate for Use On the Client Router(s): CA Certs

  1. Click System > Cert Manager
  2. To export CA Cert and Key: click on the first downward pointing triangle.
  3. As a guide, when you hover over it, the text label is ‘Export CA …’, Save File

Export Certificate for Use On the Client Router(s): User Certs

  1. Click System > Cert Manager
  2. To Export User Cert and Key: click on the first downward pointing triangle.
  3. As a guide, when you hover over it, the text label is ‘Export Cert/Key’, Save File.
  4. You’ll also need the TLS Authentication token from the server, as this will be pasted into the Cryptographic Settings on the client side.
  5. On the OpenVPN Server, click the Server configuration (VPN > OpenVPN > Server leaf), copy the TLS Authentication.
  6. It’s up to you how you will get this TLS Authentication and these exported files to the client end(s) (e.g. in an email to yourself, or copying onto a USB stick for transfer)

Export Certificate for Use On the OpenVPN Clients (e.g. Windows)


You can connect to the PFSense OpenVPN Server via desktop clients like Windows, Mac OSX, and Ubuntu Linux
It is easiest to go about this by installing the OpenVPN Client Export Utility
Click System –> Packages
Click the Available Packages leaf
Click the plus sign to install the OpenVPN Client Export Utility
Once installation is complete, Click VPN –> OpenVPN
If the package was installed successfully, you should see the Client Export leaf. Click it.
Click ‘Configuration archive’ for the corresponding user, in my case RemoteSite1
You will be prompted to save a .zip archive containing the necessary files for connection on the client end. Save the file.
The Configuration Archive should contain at least three of these file types:
It’s up to you how you will get this Configuration Archive to the client end(s) (e.g. in an email to yourself, or copying onto a usb stick for transfer)

Client Side(s): Import the Certificates (CA Certs)


Now on the client router, Click System > Cert Manager
Click the CAs leaf, add new one.
Method: Import an existing Certificate Authority
Enter as Descriptive name the name of the certificate from the first server, in my case ‘MainOffice’
Using a text editor, open the Server cert file, in my case ‘MainOffice.crt’
Simply copy / paste the content of the file into the Certificate Data field.
We are NOT pasting anything into the second field (Certificate Private Key …)
Click Save

Client Side(s): Import the Certificates (User Certs)


Click the Certificates leaf, add new one.
Method: Import an existing Certificate
Enter as Descriptive name the name of the client router, in my case ‘RemoteSite1’
Using a text editor, open the Client cert file, in my case ‘RemoteSite1.crt’
Simply copy / paste the content of the file into the Certificate Data field.
Using a text editor, open the Client private key file, in my case ‘RemoteSite1.key’
Simply copy / paste the content of the file into the Private Key Data field.
Click Save

OpenVPN Client Setup – Section: General Information

  1. Click VPN —> OpenVPN
  2. In the Client leaf, click the plus button to add a client.
  3. Disables this client unchecked (obviously)
  4. Server Mode: Peer to Peer (SSL/TLS)
  5. Protocol: UDP
  6. Device Mode: TAP
  7. Interface: WAN
  8. Local port: blank
  9. Server host or address: enter in the OpenVPN Server WAN IP Address or Registered DNS. Note: If you’re using a dynamic hostname (e.g. *.dyndns), make sure to check the Server host name resolution box.
  10. For All Proxy options, I didn’t need these so I left them blank
  11. Server host name resolution: From what I gather, you check this box if the server is using a dynamic addresses (e.g. *
  12. Set an appropriate Description (e.g. Site to Site OpenVPN Bridge with MainOffice)

OpenVPN Client Setup – Section: Cryptographic Settings

  1. Enable authentication of TLS packets: Checked
  2. Automatically Generate a shared TLS authentication key: Unchecked
  3. Paste into the TLS Authentication field the TLS Authentication value from the server.
  4. Peer Certificate Authority: Set this to the Server CA
  5. Client Certificate: Set this to the Client Cert
  6. Encryption algorithm: Set this to match that of the Server
  7. Hardware Crypto: Set this to match that of the Server

OpenVPN Client Setup – Section: Tunnel Settings

  1. Compression: Checked
  2. All else is default
  3. Advanced: blank
  4. Click Save

Add Routings To Other Networks (Optional)


If you intend to push routes to networks not part of the bridge, you’ll need to do specify the options in the advanced section ==>>

The above will push these static routes to any clients that successfully establish a VPN connection.

(Optional) Client-Specific Overrides


Client-specific overrides allow settings to be pushed on a per-client basis.

The above picture illustrates assigning a different gateway to “client johndoe-crt”
push “route-gateway”

Verify OpenVPN Client Connections


( Optional) Block DHCP Packets From Traversing the Bridge


If you plan on keeping DHCP Scopes contained to their own sites, you should enable a firewall rule to disallow DHCP Traffic across the OpenVPN bridge.

Note:{pFsense uses Packet Filter as its firewall. Packet Filter is governed by rules that are Evaluated from Top to Bottom, on a “first match wins” basis.
For this reason, any block rules you want in place should be positioned before the allow rules.


  1. Click Firewall ==>> Rules
  2. Click the OpenVPN leaf
  3. Click the plus button to add a rule
  4. Action: Block
  5. Disabled: unchecked
  6. Interface: OpenVPN
  7. Protocol: UDP (Both IPV4 and IPV6)
  8. Source: any
  9. Source Port Range: Set range to 67-68
  10. Destination: any
  11. Destination Port Range: Set range to 67-68
  12. Give it a description (e.g. Block DHCP Traffic)
  13. Click Save


Network Connectivity is Lost Across Bridge


Scenario: Upgraded pfSense from 2.1 to 2.1.2
Removed and regenerated all certs
Enabled Active Directory Authentication
Problem: Once I got the client connected, I could not ping the gateway or any machine on my network
I noticed that ipconfig results showed no gateway definition. Turns out that’s normal
Head scratching … wtf
For a shitz and giggles I removed and readded members interfaces to the Bridge configuration.
Once I saved, voila. Worked. WTF?
TLS Error: TLS object -> incoming plaintext read error
EDIT: This should have been fixed in the latest pfSense build.



For the OpenVPN Client configuration, make sure you’re using the correct Peer Certificate Authority (CA)
This should be set to the CA you imported


Fumanchu. "The Hand of FuManChu." Site-to-site Ethernet Bridge over OpenVPN (2 of 2). Web. 26 Feb. 2012. <>.
Fumanchu. "The Hand of FuManChu." Site-to-site Bridged Ethernet Using OpenVPN (1 of 2). Web. 26 Feb. 2012. <>.
Lepalaan, Filipp. "NetBoot Over OpenVPN." OpenVPN Bridging: Netboot over VPN. Web. 26 Feb. 2012. <>.
Gibson, Steve. "GRC | OpenVPN HOWTO Guide: Routing vs Bridging ." OpenVPN: Step-by-Step HowTo Guide. Web. 26 Feb. 2012. <>.
"OpenVPN Tunnels and Bridges." Shoreline Firewall. 30 July 2011. Web. 26 Feb. 2012. <>.
"OpenVPN Client Export Files in PfSense 2.0RC." PfSense Forum. Web. 26 Feb. 2012. <>.
"How to Configure OpenVPN (lockup Version)." Lockup. Web. 26 Feb. 2012. <>.
"Pfsense 2.0.1 OpenVPN Bridging Guide – [H]ard|Forum." [H]ard|Forum. Web. 26 Feb. 2012. <>.
Stefcho. "Stefcho’s Blog." Routing Road Warrior’s Clients through a Site-To-Site VPN with PfSense 2.0 RC1 and OpenVPN. Web. 26 Feb. 2012. <>.
Stefcho. "Stefcho’s Blog." PfSense 2.0 RC1 Configuration of OpenVPN Server for Road Warrior with TLS and User Authentication. Web. 26 Feb. 2012. <>.
Vana, Yaron, and Idit Michael. "How to Simulate WAN in VMware?" Vvirtual’s Blog. Web. 26 Feb. 2012. <>.

Notes About Wireless Frequencies

802.11 a/b/g/n?

Originally described as clause 17 of the 1999 specification, the OFDM waveform at 5.8 GHz is now defined in clause 18 of the 2012 specification and provides protocols that allow transmission and reception of data at rates of 1.5 to 54Mbit/s. It has seen widespread worldwide implementation, particularly within the corporate workspace. While the original amendment is no longer valid, the term “802.11a” is still used by wireless access point (cards and routers) manufacturers to describe interoperability of their systems at 5.8 GHz, 54Mbit/s.
The 802.11a standard uses the same data link layer protocol and frame format as the original standard, but an OFDM based air interface (physical layer). It operates in the 5 GHz band with a maximum net data rate of 54 Mbit/s, plus error correction code, which yields realistic net achievable throughput in the mid-20 Mbit/s.[10]

Since the 2.4 GHz band is heavily used to the point of being crowded, using the relatively unused 5 GHz band gives 802.11a a significant advantage. However, this high carrier frequency also brings a disadvantage: the effective overall range of 802.11a is less than that of 802.11b/g. In theory, 802.11a signals are absorbed more readily by walls and other solid objects in their path due to their smaller wavelength and, as a result, cannot penetrate as far as those of 802.11b. In practice, 802.11b typically has a higher range at low speeds (802.11b will reduce speed to 5.5 Mbit/s or even 1 Mbit/s at low signal strengths). 802.11a also suffers from interference,[11] but locally there may be fewer signals to interfere with, resulting in less interference and better throughput.
imma try to disect that right now

As a real-world example, wireless VOIP phones would benefit from 802.11a due to the relatively low lag rates.
During telphonic communication, lag in response time is experienced as blank, static, silence, etc in the conversation.


Description URL IEEE 802.11

Adding a Network Card to CentOS Linux

Detect & Configure The New Network Adapter

1. Determine existing network interfaces

ifconfig -a
2. Change directory to the network scripts folder
cd /etc/sysconfig/network-scripts
3. Clone the existing eth0 device network script
cp ifcfg-eth0 ifcfg-eth1 # this assumes the old card was eth0 and the new one is eth1
4. Get the Hardware Address for the eth1 network card, again this assumes the new card is eth1
grep eth1 /etc/udev/rules.d/70-persistent-net.rules
#you can get fancy and use awk and cut to isolate the string containing the Hardware Address
grep eth1 /etc/udev/rules.d/70-persistent-net.rules | awk -F"," '{print $4}' | cut -d= -f3
5. Replace all occurences of eth0 with eth1 in the new network configuration script
sed -i 's/eth0/eth1/g' ifcfg-eth1 # or edit it by hand and change eth0 to eth1 where it appears
6. Edit the eth1 network configuration script and replace the Hardware Address with the one in the 70-persistent-net-rules file
vi ifcfg-eth1
7. Bring the eth1 interface up
ifup eth1

CentOS 6 64-bit on ESXi 5.0 – No Network After Cloning

Scenario: Installed CentOS 6.x x86_64 on VMWare ESXI 5.5

Upon login, noticed no NICS detected

see:{Centos 6.2 set static IP@

see:{Settimg up a new network device in CentOS@

Regenerate the Persistent Network Rules Using udevadm

[code language=””]
#Regenerate the file using udevadm
rm -f /etc/udev/rules.d/70-persistant-net.rules
udevadm trigger –action=add

Manually Verify and Correct NIC Device


[code language=”bash”]
#1. Verify problem (no ethNn present)
#2. Verify system detects ethernet hardware
dmesg | grep -e ‘vmx\|eth’
#3. Verify ethernet driver is loaded
lspci | grep -i ethernet
#4. If not already present, create generic eth0 config file
vi /etc/sysconfig/network-scripts/ifcfg-eth0
#If there is already a UUID line, Delete it, save, exit
#5. If this system was cloned, you’ll need to remove the old MAC address reference.
#See next step

Manually Correct NIC MAC Address After Cloning


After cloning a CentOS 6.x machine, you may find that connectivity is limited to only the loopback (127.x.x.x) interface

This is likely because the system has retained the MAC address specification of the machine from which it was cloned

You can correct this by modifying the Persistent Network Rules File

[code language=”bash”]
vi /etc/udev/rules.d/70-persistant-net.rules

Configure NIC Device Using System Config Network Utility


1. Launch the System Network Configuration Utility

[code language=”bash”]

2. Choose ‘Device configuration’ in the dialog

3. Fill in settings accordingly (e.g. Name:eth0;Device:eth0;DHCP:enabled. Press OK

You’ll be taken back to the original dialog

4. Press Save&Quit. Restart networking services

Settings should persist even after reboot