As said, the interface for incoming VPN connections can also be the LAN interface. So no further interface is necessary for your goal, just one.

For openvpn server set up, the wizard will guide you through and there are also some tutorials in this forum and in the pfSense docs:
https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

No one has any clue?

@Pitchoun511:

I have found nothing that resolve my problem

I just went through the procedure in the thread I linked earlier on two 2.2.1 boxes and it worked fine, or rather well enough for me to get in and fix a problem preventing a remote host from routing out correctly. If you are still having problems, I suggest you look over that and then post some specifics of your config.

I see the same behavior on an Alix box we have.  The upgrade to 2.2.1 did nothing to fix this issue.
OpenVPN settings:
AES-128-CBC (128-bit)
SHA1 (160 bit)

I've checked the throughput via the command line (openssl commands), and I can set up ipsec tunnels and verify that the HIFN 7955 card is working - IPSEC I see great throughput, low CPU utilization.

OpenVPN - 100% CPU at about 6Mbps of throughput.

Something doesn't work correctly.

Perfect.  Thanks for the great explanation.

@robi:

Don't think you need to NAT on both ends. You should be able to create a single 1:1 NAT on the VPN server side between 192.168.53.0/24 and 192.168.1.0/24. All the VPN clients (which I presume are simple Windows clients on home PCs or laptops) can see 192.168.53.0/24 ast it would be 192.168.1.0/24.

No idea how you imagine this to work, really. So, you get traffic from the VPN server side's LAN via VPN. Won't ever reply back via VPN. It's like NAT reflection backwards.

Read this:
https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni

Performance Improvement

The performance improvement expected with the use of AES-NI would depend on the applications and how much of the application time is spent in encryption and decryption. At the algorithm level, using AES-NI can provide significant speedup of AES. For non-parallel modes of AES operation such as CBC-encrypt AES-NI can provide a 2-3 fold gain in performance over a completely software approach. For parallelizable modes such as CBC-decrypt and CTR, AES-NI can provide a 10x improvement over software solutions.

Just look at the routing tables and see what's going on. netstat -rn and probably something else on windows.

Hi jimp,

your sentence "Both should use the same certs, but different tunnel networks" was the right answer to make that work!
Thank you a lot :)

Cheers

Thanks for the reply…

I only have windows firewall... haven't tried disabling it. But when I did, its working!

Make the OpenVPN server listen on the failover gateway group Register with a dynamic DNS provider (if not already).
3)Add a Dynamic DNS entry to update the name based on Failover Gateway Group Setup the OpenVPN client systems to use the dynamic name to connect

@phil.davis:

Our subnet here is 10.0.0.0/16 and the tunnel networks are 10.0.2.0/24 and 10.0.3.0/24

Whatever worked previously must have been by luck. OpenVPN tunnel network should not overlap with any other local networks on your pfSense (or in your intranet).

Change the tunnel networks to outside of 10.0.0.0/16 - e.g. make them 10.1.2.0/24 and 10.1.3.0/24

Then if there is still a problem we can think further.

Well that sorted it, thanks. Must have been something odd in the set up for that static gateway.

@kejianshi:

Making subnets arbitrarily huge is a mistake.

Noted, bit more work needs to be done on this network.

Hi,

Solved it, had to assign an interface, assigned VPN1 to ovpnc1, added no ip configuration what so ever. That automatically created a gateway interface under system - routing, then in the firewall rules, I could use that gateway, and the it worked :)

The primary files that I'm transferring are .mkv files and Acronis True Image backup files .tib

The .tib files are around 400GB and get pushed every 14 days.

The .mkv files are around 30GB or so and get accessed as needed.

Before I had a VPN setup, I was using FileZilla FTP over TLS to an older firewall with forwarded ports. Said firewall forwarded the ports to a 2012 R2 VM running an FTP site with IIS.

I suppose I could still do that if need be…

The NAT is only in effect when the traffic is being routed out that interface.  That's the standard method of NAT when Multi-WAN.

This is probably the PIA pushed default route AGAIN.

Check the Don't pull routes checkbox in your PIA client config.  It will then be up to you to policy route traffic to PIA.

I have no idea what that rule is on your PIA interface.  Delete it.

You need to policy route traffic by matching it on the interface it is RECEIVED ON (DMZ, whatever the 192.168.2.0/24 interface is) and set the GATEWAY to PIA for that traffic.  Read the tutorial again.

https://doc.pfsense.org/index.php/What_is_policy_routing

@SLIMaxPower:

So it looks like afterall I will have to pay for a VPN.

Most likely yes. I'm aware of no such service being free.

Let's say I want AU traffic to go through an AU server, and the remaining go through an International server (same VPN provider) and gaming to bypass VPN altogether how to I accomplish this ?

By very careful configuration. ;)

Your requirements aren't exactly simple and straightforward so I'm not sure someone is willing to give you a complete tutorial on everything. It's usually much easier to get assistance when you present a specific problem you run into when trying to configure something yourself.

What I would do if it was me:
1. Search the forum for threads about these kinds of configurations. I have noticed several lately so they shouldn't be to hard to find.
2. Research the market for possible anonymizing VPN-providers. Check the suppliers recommendations on client-side configuration, maybe some of them even have specific examples for pfSense?
3. Try to configure it myself or hire someone to do it for me.
4. Return here with more specific questions if something is still unclear when the above homework was done.

PIA has the equivalent of your "Force all client generated traffic through the tunnel" setting.  This amounts to them pushing a default route to you.  So, naturally, all traffic is going to go to them when it's connected.

Add route-nopull; to the advanced settings of the PIA client instance or, if on 2.2, just check the Don't pull routes checkbox and bounce the VPN.

It will then be up to you to policy route the traffic you want to go to PIA.

This is the default route:

Internet:
Destination        Gateway            Flags      Netif Expire
0.0.0.0/1          y.y.y.5            UGS      ovpnc2

Ah ha.  The additional data I see being returned to me is because the Azure Multi-Factor Authentication server is NOT backended by Active Directory directly, but through a Network Policy Server running RADIUS - and returning client options that the OpenVPN client doesn't accept, apparently.  I started another thread on how to setup 2 factor using Azure MFA and OpenVPN using the results I've found troubleshooting this week.  Thanks for you response!

Unless you are a network supergenius, keep things on /24s just for simplicity until you really have a great understanding of subnets and subnet masks.