@vtulin: @jimp: On 2.3.3 we now have an option "No Preference and Adaptive Compression Disabled" which helps when dealing with picky clients. Which will remove accurance of this option in config? Thank you for response. When this option is selected, "comp-lzo" is not in the config, and it adds "comp-noadapt" to disable adaptive compression. OpenVPN can be picky in how the client and server interact across versions and when LZO is not compiled in. If you have no compression options in the configuration at all, it still enables it with adaptive compression because that's the current OpenVPN default (it wasn't always). And if you use "comp-lzo no" the far side won't understand that if it does not have LZO compiled in.

Yes, correct. The outbound NAT translate the packets source IP from origin VPN clients address to the FW2s LAN IP. So when the packets reach your LAN host, it seems the come from FW2 and it will response to FW2 where the destination address of the packets is translated to the VPN clients IP. We've discussed this yesterday here: https://forum.pfsense.org/index.php?topic=120328.0 To use the same VPN tunnel subnet for both connections is definitively not a good idea. But that doesn't matter if you do NAT. Access from a VPN1 client to the FW2 management interface can also be enabled by an outbound NAT rule at FW1. Here you just need to enter the FW2s LAN address at destination.

Firewall rules are generally used to block connections coming into the firewall on an interface. If you want to stop hosts on LAN from making certain connections, then you place those block rules on LAN. If you want to block connections coming in from remote OpenVPN sites, you put those rules on OpenVPN. If you want to block connections going to a remote OpenVPN site, then either block them on the incoming interface (like LAN) or block them at the remote side inbound on OpenVPN. They are the ones "locking their door" against incoming connections. It's possible to block in the outbound direction using floating rules. If you think about the security aspects of what the firewall is supposed to be doing, this is really the only model that makes any sense. https://doc.pfsense.org/index.php/Firewall_Rule_Basics https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

Thanks so much viragomann for the explanation and kpa for the solution. It works as expected now.  :)

You have to set Remote Networks on each side if you use shared key. The new CSS is more adept at hiding fields when they are not appropriate. Even if you could set them they would not work.

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!