*******    ***    ******   *******  ******   **  **    ***    *******
  ***     ** **   **   **  **       **   **  ** **    ** **     ***  
  ***    **   **  ******   *******  **   **  ****    **   **    ***  
  ***    *******  **  **   **       **   **  ** **   *******    ***  
***      **   **  **   **  *******  *****    **  **  **   **    *** 

So, I'm not sure why this is the case, but without setting up ProxyARP in the pfSense virtual IP's menu, setting up OpenVPN the way I want does not work. 

The situation: 

I've got a pfSense router running all the routing responsibilities for my home network. I wanted to be able to set up a bridged OpenVPN segment, as to allow clients to attach themselves to the network but still share the same subnet. 

This seemed easy enough - add a new OpenVPN server instance, tell it to run in "tap - Layer 2 Tap Mode", latch it onto "any" interface, give it a distinct port from my other VPN servers, etc. I copied all the cryptographic settings from another existing VPN instance. Then it came to the server configuration. In the end, I manually wrote the server configuration details in the "Custom Options" box as such: 

#############
server-bridge 10.13.37.1 255.255.255.0 10.13.37.200  10.13.37.210;

route 10.13.37.0 255.255.255.0;
push "route 10.13.37.0 255.255.255.0";

client-to-client;

duplicate-cn;
#############

From here, I saved and started up the VPN. It booted up fine, and then I connected to the VPN on Ubuntu using nmcli. That connected fine. I was able to ping the gateway, get to the internet, but the problem was, I couldn't access anything on the LAN side of the VPN server. 

After some time running tcpdump and checking arp -v, I learned that while the host on the other side of the VPN was receiving packets, it kept asking ARP for a MAC for the IP and not getting a useful response and that it wasn't storing the MAC address and didn't know where to send the reply packet. 

Using this information, I did some research and found that OpenVPN and pfSense does not handle ARP across the bridge well for whichever reason? I would figure it should be able to figure this out by default, but seems that it hasn't.

As a shot in the dark, I went over to the "Firewall > Virtual IPs" page, clicked "Add" and set up a Proxy ARP type on the LAN interface for 10.13.37.0/24 and fed the "Address(es)" field the 10.13.37.0/24 subnet. Save, and suddenly, it worked. 

Process for installing a custom…
A tale of woes setting up…
Setting up unique keys for git…