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?

After looking for some openvpn configurations in /etc/ I possibly could apply from my existing installation, I was searching the forums until I found this thread OpenVPN config file? and realized the configs are stored in /var/etc/openvpn/ so from the webui via menu "diagnostics" - "edit file" its possible to edit your specific config. Looking at the openvpn logs it seems like it works same as it worked on my existing installation. I have to fully set up pfsense to test if the same configuration would work, but so far it looks good. Thanks

If you can't change your router to act as a (bridging) modem, at least you need to be able to add corresponding port-forwards for your openvpn server. Without a possibility to connect to the openvpn server from outside, it won't work. See OpenVPN Networking

@jimp: The new version of the export package includes OpenVPN 2.4 binaries. They will work fine with OpenVPN 2.3.x servers. The message in that description is warning you that if you have an OpenVPN 2.4 server, and the OpenVPN 2.4 server has features enabled that are only in OpenVPN 2.4, then an older OpenVPN 2.3.x client may not work against that server. Thanks for this explication It's ok Have a nice week-end,

Anyone have any ideas??

To answer my own question, it was pulling routes from OpenVPN. I checked the "Don't pull routes: Bars the server from adding routes to the client's routing table" box and everything is working as desired! Routing before: Internet: Destination        Gateway            Flags      Netif Expire 0.0.0.0/1          10.69.0.5          UGS      ovpnc1 default            InternetIPGoesHere      UGS        em0 Routing after: Internet: Destination        Gateway            Flags      Netif Expire default            InternetIPGoesHere      UGS        em0 Special thanks to FPSRogerRamjet for the help!