Yes, thanks. Completely blew past that setting/working now

NVM I figure it out.

This is a lab VM inside my LAN so bogus IPs but same concept. http://imgur.com/a/nP8jc  Nat and Rules tabs. Have it setup like this in lab environment: OpenVPN (server) >> pfSense >> OpenVPN (client) Server and Client are Ubuntu. Is that what you were looking for?

I don't see that with Viscosity.

That was it. Thank you very much.

Upgrade your OpenVPN client export package again. There was an issue in the posted version temporarily for a few hours.

Are both pfSense boxes the default gateways within their networks?

This is some really strange behavior, but you can try to somewhat mitigate it: move your VPN server to Localhost interface (bind to localhost) and NAT needed port from WAN interface.

Same as you grant any other access in pfSense. Go to Firewall > rules > OpenVPN and modify the allow-any-to-any rule. As source enter the VPN tunnel subnet and at destination the host address you want to allow the access. If you provide DNS to the VPN clients, you have also to add rule for DNS access.

You can use Services Watchdog for pfsense services monitoring, if are having openvpn hang problems, the proccess still is there but unresponsive like a zombi and service chekers does not work, try removing openvpn pluging from main dashboard. https://forum.pfsense.org/index.php?topic=116670.0

@Derelict: Internal LAN is a /16, so something like 10.123.0.0/16, default (LAN) DHCP pool is 10.123.100.0/24 (which can talk to everything else, say, 10.123.1.x just fine), and the OpenVPN pool is 10.123.200.0/24. Once I'm properly off-site where I can test I'll re-check the VPN clients are getting the default gateway. Yeah you need to set your OpenVPN pool/tunnel network to something OUTSIDE your LAN subnet to have any prayer of being able to route to it. Or, more accurately, to have a prayer of anything on LAN being able to route back. (Sorry for the delay in replying.) That was the key, once I changed the OpenVPN pool to not be a sub-set of the LAN, all is well. There was a bit of a red herring in testing as the main target I was using is an L3 switch that (understandably) doesn't allow management traffic from a different subnet. Thanks again, and next time I have a question I'll try and get second set of eyes sanity check first.

Disabling negate rules on both sides of the VPN in System>Advanced>Firewall & NAT fixed the issue as policy routing was not being applied properly. Thanks to PiBa-NL in ##pfsense on freenode!

You may set up 2 separate OpenVPN servers for your user groups which use different tunnel subnets, or you may also do this with only 1 server and configure "client specific overrides" to allocate certain virtual IPs to specific users.

Hero Member you are! Thank you very much!

Stuff to read: https://community.openvpn.net/openvpn/wiki/Hardening And here under > Hardening OpenVPN Security < https://openvpn.net/index.php/open-source/documentation/howto.html

As stated, yes. On a different UDP port. Most would use 1195.

Use something outside that subnet for the tunnel network and put 10.10.0.0/16 in the Local Networks on the server.

THX!!