Going to leave a reply here since I figured it out. Turns out layer 3 routing doesn't work with a switch. Which in retrospect obviously it doesn't, switches are level 2. I had previously followed a guide that had me set up an interface group consisting of a few nics I have on the pfsense box. And the guide had me set up an allow all rule on the interface group. And any rules I placed on the interface group doesn't actually redirect packet to gateway according to source. It just doesn't work. But as it turns out, I didin't actually need the allow all rule on the interface group anyways. I deleted the rule on the interface group, and then everything worked as it should on lan0. Again, this should have been obvious in retrospect because the lan0 firewall rule never had any states, but the interface group rule had all the states. Hope this helps someone else.

OK, so all of the answers to the ultimate questions listed  were a 100% match for me.  This is what I had to do:  In pfSense, go to System - Package Manager - Available Packages. Find the package called openvpn-client-export and hit the install button, then confirm.  I wasn't aware that there were additional packages. And now it makes sense why folks who have fresh installs run across this.

Redirect Gateway: is set to Force all client generated traffic through the tunnel. The user when he goes home the traffic is "correctly" redirected through the tunnel The user when he is at a client side the traffic does not redirect through the tunnel. (OpenVPN is on his laptop) What i was wondering is why does it get redirected in his home network and why it does not get redirected at another location. I do understand that it way have to do with network traffic policy’s that exist within the clients network but I just needed a more detailed view on the issue. Thanks for the previous reply.

@Pippin: There is the –float directive. See manual 2.4: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage How that is handled by pfSense firewall. i do not know, just try it. As I read about the float directive, it appears to deal with incoming connections from clients and does not address updating the IP that the OpenVPN service is bound to after a WAN IP change on PFsense.    E.g. if a client is on a laptop connected to a flaky cellular hotsot and the connection breaks briefly causing the hotspot to reconnect and acquires a new public IP … the float directive will allow the client to re-connect and authenticate even though subsequent connections (post reconnect) are coming from a different IP than the initial connection.

True, every day learning more …

You do not need to create user in pfsense to allow for vpn access.  You just need to create a user cert using the CA you setup for your openvpn.

:) No opinions at all? Is this soo bad cfg approach that noone won`t even comment it? :)

@Derelict: Then you are still performing NAT there. Turn that off. Would you be able to explain? Thank you

@johnpoz: I would try the fast i/o option and play with your send/recv buffers while doing your testing  Does that help? It got a little better when enabling fast i/o, It seemed like I got the best speed (~4 Mbit/s) with 2.00 MiB send/receive buffer. I still think I could expect higher speed than this no?

https://forum.pfsense.org/index.php?topic=135680.msg743942#msg743942

@marvosa: What is the LAN subnet on both sides? thanks. fixed by defining "Client Specific Overrides" and``` iroute 192.168.1.0 255.255.255.0;

SUCCESS! Looks like it was me all along. I had left the /8 mask on my LAN Network. So really I was running 10.0.0.0 255.0.0.0 I changed my LAN Interface to 10.0.0.0/24, rebooted DHCP devices (or release/renewed) and suddenly I can access all my local devices. OI! It makes sense to me now because my VPN IP pool was technically WITHIN my LAN network. Ever have one of those days? The last 3 were that for me. Oi… Hope this helps someone else!

Post the server1.conf from the server and the client1.conf from the client, so we can offer a targeted troubleshooting effort. I see one issue right off the bat: I have set "IPv4 Remote Network(s)" on both client and server to use the same IP network. In a routed solution, all LAN subnets have to be unique and non-overlapping… i.e. the server-side LAN has to be different than the client-side LAN, which should be reflected accordingly in the IPv4 Remote network(s) box on both sides.

In order to do the outbound NAT to effectively use an OpenVPN provider you must create an assigned interface. Rules on the OpenVPN tab will only affect inbound traffic (which should be none in almost all cases) not outbound.

Yeah figured give you the good news ;)  Not that its been on the books for a year… heheeh