I assign an addtional interface (ovpnc1 in this case). Activated this (no ip nothing just activated) Then i set an static route to 192.168.50.0/24 on the gatway of this interface.(this was the way of doing this, as i know since years) But my question is, the text in newer Version state like this is not needed any more.

You were right. After dealing with the datacenter's support, we found I could enable IP spoofing on the LAN interface for the pfSense VM and after allowing that, it works fine without NAT.

@Soyokaze: Test with same hosts and ports on your own PC (not from pfsense), Test from both PC and pfsense with different hosts/ports. Did this and was the same but it did give me an idea and found what was the issue. A power surge took one of my ports out on my switch and was stuck in 10MB half duplex which was causing the whole network to go to it. Repalced the switch and good to go. Thank you!

Then I would suggest you put that in as a feature request on redmine or possible the package section.

The firewall can't easily act as both a destination (routing) and a bridge. You would have to manually set a route on each system in your local network, pointing the VPN subnet to the firewall's IP address. When a VPN client tries to contact a server, the server's reply would be going to its default gateway (on the WAN side of the firewall) and not back to the firewall itself. It may also be possible to put a route on the default gateway to point the VPN subnet back to the firewall's IP address, but that would be rather messy. It is nearly always better to NOT bridge, but to do routing. If your ISP provides you with two blocks (one for WAN interconnect, second block routed to the firewall in the first block) then you can do away with bridging and use a proper routed setup instead.

I was able to figure this out. The problem was caused by "Authenticated Users" no longer being included in the Pre-Windows 2000 Compatible access built in security group. This group normally provides read rights to all AD Objects. Previous and existing domain admins were automatically being assigned some of these read permissions. Fixed by giving the pfsense LDAP Active Directory account read access to all users.

Do you actually need separate interfaces? Are they all active at once, or is it meant to fail from one to another? If it's the latter case, you could just add a bunch of "remote x.x.x.x yyyy" lines to the config of the first one. If it's the first case, then there isn't an easy way to automate that currently. (And it's too late for new features on 2.4)

@Derelict: I would be surprised if you saw a difference in speed with AES-NI in use or not with OpenVPN. There is a lot of overhead already there that has nothing to do with crypto operations. If anything you might see less CPU utilization to accomplish the same speeds but that is more difficult to measure. I would expect a measurable but not dramatic speedup moving to GCM and changing from aes256 to aes128. It's worth doing, but won't fundamentally change the performance characteristics of a machine.

You are the best Derelict! Thank you so much.  It seems to be working, but I'll do some full testing tomorrow. I added a rule so that traffic going to my LAN net doesn't use the WAN interface.  I put that at the top.  Then, I followed it with the rule for traffic going any to route out the WAN interface.  Now, I can ping my internal LAN devices as well as pinging external sites.

Anybody please help ? I just want to loadbalance between P2P and Internet but Internet traffic I want to encrypt so I am using open vpn? Any other suggestion please help. Thanks

So you have a pre-shared key site-to-site server, here is only the remote networks option available.

@NasKar: If I change the gateway on the Plex2 rule from WAN to default I can't get out to the internet. Not sure why default doesn't work but it still works with the gateway as WAN. I've mentioned that behaviour and the solution alreade twice. here: https://forum.pfsense.org/index.php?topic=132341.msg733209#msg733209 and here: https://forum.pfsense.org/index.php?topic=132341.msg732814#msg732814 So what are the troubles with that? If your vpn client connection is up, the packets go out this connection, when there's no gateway specified in the appropriate rule. So you also need to add an outbound NAT rule for this traffic (on the vpn clients interface!). How to do, I've described here: https://forum.pfsense.org/index.php?topic=132341.msg733440#msg733440

@viragomann: There's no need for advanced options to pushing routes. This is done by "Local Networks" option. The idea to put a route  in server advance config comes from this guide. It makes the difference, without that route I cannot access internal subnet with the user who has client specific overrides. The client configuration was ok since the beginning, a route print from windows command line shows it knows how to reach 192.168.1.0/24, the IPv4 Local network of the client specific override. Don't know how to check the routes on firewall: it can reach 192.168.5.0/28, the Ipv4 tunnel network configured with OpenVpn server, but I suspect it has no route to 192.168.6.0/28, Ipv4 tunnel network of the client specific override. Adding that route manually traffic flows as expected.

The pfSense Book is now available for just $24.70! vvv

Thanks, but it seems it's "generate, then package" approach, e.g. same file. Anyway, the main purpose of this post was to understand if it was a pfSense issue or not. Believe the answer is "yes". One possible explanation for the different behavior over time is "fix and re-introduce" has happened. Appreciate the link from the bug database and the guidance provided.

I tried other TCP ports and same results….I see the firewall passing the traffic UDP is working as it should...same server config..just different protocols. Can anyone just confirm they have 2.3.4 routing traffic using OpenVPN TCP? (this is a clean install just done...no upgrade from older versions) Need to make sure before the rest of my hair falls out..  :) thx