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.

@kpa: Nothing ready to use afaik but OpenVPN has -client-connect and -client-disconnect scripts that are run when client connects/disconnects so it's possible to hack something in those to register/deregister entries to the DNS forwarder/resolver during connect/disconnect. Do note that there is no DHCP used on an OpenVPN connection when the usual settings (tun type tunnel network etc.) are used so the OpenVPN server never sees the hostname of the connecting client, it sees only the CN from the client certificate of the connecting client. In my case at least with any machines I care about reaching I've already set the CN to the same as the hostname (lacking any other ideas what to put) so maybe that will help. I assume this is a server-side script setting?  Is there any documentation on how to do this in pfSense? I'm quite familiar with both networking and bash/sh/csh scripting from work projects but I've never worked with VPNs before (from an administrator point of view, I've only used them as a "client" before) and I'm not sure how I'd properly "save" a script to pfSense.  I assume it has to go in a certain place to be saved thru upgrades/reinstall and then I'd have to reference it there in the openvpn advanced-configuration and somehow it would "find" what clients are connected to register them.

hi just tried it, works alright, thanks for your help whosmatt and kpa  :)

Hum, it's ok with new pfSense 2.3.3 thanks

I got this working. I had way too many rules it seems, I followed a tutorial when I set things up that told me that for every rule I create on one interface like LAN I had to create the mirror on it's destination. I just disabled half my rules and everything is running fine. To opt out the one device I made one rule: Pass, Interface=Wireless, Source=Singlehost-192.168.25.45, Destination=any, Gateway=WAN No extra NAT rules or anything else and it works great

Thanks for the reply. After thinking about it, I too realized that this probably won't work. Oh well.  Much appreciated!

Did you setup the Bridge?