In a previous article, I described how to install pfSense in a vCloud tenant to become its gateway. In this article I will show you how to create a stretched lan between this firewall, and another one installed at a customer site.
A stretched LAN is a connection between two sites where you can use the same IP addresses at both sites, without involving routing in between. This configuration has some pros over routing (there are also cons, but it’s not the scope of this article), like the fact you can move virtual machines from one site to the other without changing its IP address.
This configuration will use OpenVPN bridging capabilites. OpenVPN is one of the best VPN solutions around (if not the best), it’s included in pfSense, it’s free and opensource, and if you have doubts about its ability to scale and manage corporate VPNs, I have many big customers using it, in sectors like banking also where security is a primary goal.
Configure the customer pfSense
I usually configure the server part of OpenVPN at customer site. This is not mandatory, you can choose one of the two sites to act as server and the other one as client, for me it’s only a matter of clearness since this is the site that will probably have also roadwarriors connections.
Go to VPN -> OpenVPN section, and in the Server Tab add a new server connection, like this one:
Let’s explain the configuration I chose (other settings can be left at default):
– Server Mode is “Peer to Peer (Shared Key), this is needed for site to site VPN. The two sites will have the same shared key to cypher the tunnel.
– Device Mode needs to be configured as TAP (tun is for routing mode)
– Interface WAN: we want to connect via wan interfaces the two pfSense appliances
– Shared key: you can choose to auto-generate it, and then copy it to the other pfSense
– Tunnel Network: set a value that is not in use in none of the two sites, this will be used only inside the OpenVPN tunnel. I set /29 subnet since this tunnel is only going to have two IPs, one per site
You do not need to set any other parameter, like local/remote networks etc.
Now go to Interfaces -> assign -> click the + symbol to add an interface and choose the ‘ovpns1’ from the drop down (this is the openvpn tap interface for the OpenVPN server we just setup):
Now go to Interface -> OPT1 and check the box “enable this interface”. You can also rename it to OVPN or something else for simplicity.
Go to Interfaces -> Assign. Open the “Bridges” Tab and hit the + Button to add a new bridge. A bridge is made between two interfaces, so you will select both LAN and OPENVPN to create the new bridge. You do not need any advanced setting:
Now that the bridge is up and running, we must create the related firewall rules to let the traffic flow through. This is another cool feature of pfSense: you can apply whatever rule you want over the bridge, so you can filter the type of traffic you want to reach the other side. You will see an example soon:
This first rule must be created in the WAN section, since it allows the remote site OpenVPN to connect to this site.
You will now need a similar rule unter “openvpnbridge” interface (the TAP device) to allow all traffic:
From here on, all rules to manage traffic flow will be created in the “OpenVPN” bridge interface. The first one will allow all traffic:
As an example, the second rule deny DHCP traffic to cross the bridge, so VMs in vCloud tenant cannot receive an automatic IP from a DHCP server running at the primary site (the assigned gateway would be wrong). You can create more complex rules at your will. Remember pfSense reads all rules and always apply the more restrictive one, regardless of the order.
Now let’s move on to the other site of the bridge!
Configure pfSense in vCloud
Configuration is almost the same as in the primary site, you will have to create the OpenVPN connection in the “Client” section. Here the configuration will be like this:
There are some configuration you MUST have equal to the other site:
Server Mode: Peer to Peer: Shared Key
Device Mode: tap
Server Host or address: input the public IP of Firewall1 here
Server port: 1194
Shared key: paste key here from Firewall1
Encryption: match it with Firewall1
Tunnel Network: 10.0.8.0/29 (same as on Firewall1)
Again, go to Interfaces -> Assign -> hit the + Button and select ovpnc1 as the network port for the new OPT1 interface.
Go to Interfaces -> OPT1, and enable this interface, you can also rename it to something more readable like OVPN if you like.
Next, as you did on the server side, go to Interfaces -> assign -> bridges -> hit the + and add both LAN and OVPN to BRIDGE0.
Navigate to Firewall > Rules, and create a new rule under WAN with these settings:
dest port range: OpenVPN (1194)
Navigate to the rule under OpenVPN (the Bridge0 interface), you will already find a rule to allow ALL traffic: proto * src * dest *.
In the OVPN interface (the OpenVPN tap interface), you can create a first rule to allow all traffic through it, like this:
From here, as you did in the server site, you can create other rules to restrict traffic you do not want to cross the bridge between the two sites, like the DHCP rule you created before.
At this point, you should be able to ping addresses from both sites of the bridge. Even if there is no other VMs in the vCloud tenant, you can ping the LAN interface of the pfSense deployed in vCloud. In my test environment, local pfSense is 192.168.0.10 and ping statistics shows typical LAN speeds:
while the LAN inferface of the remote pfSense is 192.168.0.200, connected via a 2mbits ADSL line:
That’s it! From here you can enjoy your new stretched LAN 🙂