I figured it out. It was the Manual Outbound NAT rule generation rules that had to be configured. I used this guide: https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1 But instead of using the WAN interface I had to use the vpn interface which I created from the Openvpn Client connection. Good Luck!

dev tap isn't included in that on purpose because, as you stated, those devices don't support tap. If you load that config into the app it would fail to import or function because of the dev tap line. The way the export package is coded it isn't feasible to disable those export buttons for some VPNs and not others, so we err on the side of not creating invalid configuration files for the platform.

@Mithrondil: I was referring to that AES-256-GCM is not slectable in the Encryption algo rolldown window in pfsense. It isn't supported until OpenVPN 2.4, which is only on pfSense 2.4. And it is in the list there.

Never Mind.    Turns out OpenVPN Interface options must have "any" selected.  It was WAN only before. Is this still safe to chose any? cheers

Thanks will do.  I am not using VPN-> iPsec but instead my client is in VPN->OpenVPN.

The setting for the site-to-site I've suggested above is necessary anyway for correct routing. Look, if you try to access a LAN device on site B from a VPN client on site A, the packet is sent to the site A pfSense, cause of the route which is pushed to the client. Site A directs the packet to site B, cause it also has a route for the site Bs LAN. The packet reach the device on site B, which send its response addressed to an IP in 10.10.210.0/24 back to its default gateway which is site B pfSense. If there is no special route for 10.10.210.0/24 the gateway will send the packet to its upstream gateway, thus to the internet where the packet will be dropped, cause the destination subnet is not routed there. Therefor you need a route on site B which direct packets destined to 10.10.210.0/24 back over site-to-site tunnel to site A.

Hey John, did you ever get this working? I am experiencing a similar issue trying to connect a 2.3 PfSense to a Openvpn server. Thanks Martin

Are you trying to access them by name or IP address? If you are trying to access them by name, try by IP address instead. If that doesn't work, check the local system to be sure it allows connections from outside its subnet. The local system hosting the share may not allow connections from the VPN subnet and may need some adjustments, such as having an exception added to the Windows Firewall or having the Windows Firewall disabled.

I'm an idiot. Problem was me accidentally deleting the port forwarding rule on my router when deleting rules for my camera server/recorder. (I use a separate router instead of the pfSense box serving as router).

Great news! I'll look into adding a GUI knob for that, I have a couple others that need to go in as well and it may be good to have set by default for upgrades to preserve the existing behavior.

@emammadov: But I see that there are two types of SHA256 here: RSA-SHA256 and SHA256. They are the same. http://security.stackexchange.com/questions/91908/using-rsa-sha-as-instead-hmac-in-openvpn

That is not a client connecting/disconnecting. It's the GUI polling information for the widget or openvpn status. Your OpenVPN instance must be set for a verboseness level that logs that info.

Update: Finally I fixed all the outstanding issues. I had to correct some gateways for a few Esxi hosts, add some static routes to multi-NIC servers, adjust some workstation windows firewall rules, and now I can get to all of my LAN destinations. Thank you for your help with this! Also, after updating the OpenVPN client version on my Windows 10 box to 2.4 and adding the "block-outside-dns" parameter, I am getting local LAN DNS resolution instead of my ISP's. I was also able to get my Linux box connected to the VPN with DNS resolution working there also. Functionally this is all that I was looking for and it's working perfectly. Very stable. Ok that's it. Just wanted to say thanks for all of the invaluable knowledge on this board from the contributors in this thread and the many others that I read through as I worked through my issues.

I still have this problem as of today, with pfsense 2.3.2p1. When it happens, about once pr week, I normally log into pfsense by SSH and restarts webconfigurator and PHP-FPM then restarts the OpenVPN in the GUI. That I can live with. But the pain is that the branch office doesn't automatically reconnect to the OpenVPN-server but have to be rebooted every time this happens. I removed the OpenVPN and IPsec widgets but the probmels still occurs. Coffeup25, can you please advise on "dns leakage line added to some config files"? Which config files and which lines shall I look for? Or does somebody know another solution? I read somewhere that it might not be fixed as pfsense 2.4 will use another GUI-system and therefore it will be obsolete. So I presume the error/problem is still there in 2.3.3?

Yes. Upgrade.