Good idea- thx

@viragomann - thanks for the response, I really appreciate it. Can you elaborate what you meant by this:

@viragomann said in [Solved] OpenVPN Multiple WAN Asymmetric Routing Issue:

@tman222
I cannot see any benefit at all in directing upstream traffic from VPN clients out on the interface, where the VPN connection comes in.
...

Why would there be no benefit?

Also, a more general question: What is the overall advantage then of going with the port forward / localhost method for multiwan if the interface on the OpenVPN server can setup using the gateway (failover) group? Is the port forward / localhost method a more robust failover method for OpenVPN compared to using the gateway group?

Thanks again for your help.

@frog

Click here :

25a4fba8-25c8-4cbd-a033-8299c3ce8cc8-image.png

I pre entred the needed search termes already.
"openvpn notify"

You'll find some old threads where OpenVPN notifying was created.
Be aware : these were the days of OpenVPN 2.4.x or 2.5.x
Its of course not guaranteed that these instruction still work today - current pfSense version uses OpenVPN 2.6.x.

The good news : OpenVPN is opensource freeware etc, so all you need is the manual ^^

@Cryux

Turned out I had a firewall rule on the client lan that passed any/any but specified the gateway... Removing the gateway specification, setting to default, cleared up all my problems...

@frog yeah you can create aliases with pfblocker and then only allow what is in the alias to connect. I would go more for allow vs block, because normally this is a much smaller list vs trying to block the planet.

But if you just want to block a couple of countries and allow the rest then sure block vs allow.

For example - I currently allow only the US and a few specific IP ranges that might not be US to access any of my services I expose. But if you wanted to allow everyone other than say mexico ;) then that list would be smaller and would be better to block vs allow.

I have a TP-Link Archer as VPN server at my Dad's old house. Can ping & connect to everything in the remote LAN, but can only ping the TP-Link. The TP seems to block it's web access via the VPN, but I think that's a router limitation.

Not really a problem for me, but will check the config & let you know on Sunday when I'm there in case it helps.

No special routes, etc. in the client config. Local = 192.168.123.0/24 and remote = 192.168.2.0/24

@NightlyShark said in OpenVPN and PIA Errors | Reconnecting (Auth Failure | Authenticating | Pulling configuration from server:

@8ayM Does it support AES-NI?

Yes

https://www.intel.com/content/www/us/en/products/sku/97926/intel-atom-processor-c3758-16m-cache-up-to-2-20-ghz/specifications.html

@kistudent

some general guidelines then..

https://docs.netgate.com/pfsense/en/latest/vpn/performance.html#general-advice

@Gertjan @NightlyShark Thanks for your support and advice. Post version upgrade the issue was resolved.

Things are in control now and working well...

Once again thank you everyone.....

@Alessio-Zatta said in Package installer failed (openvpn-export):

So its running on an old PC

That was my initial pfSense experience !
A desktop PC has a build in NIC, so add one more and you're good.

Still today, you should make use of some common knowledge : Make live easy on yourself.
So, these are "the rules" :
If the motherboard has Realtek chipset : pay it a visit in the PC's bios, and select Realtek's most useful option : set it to "Off". Disable it. You just raised the chance of having a perfect "home build router" experience by a lot.
Next rule : No, don't take that USB to NIC adapter. Don't fall into that trap.

Do what needs to be done : get that one or dual Intel NIC, and slap in in your PC.
If you're above average, you check upfront that the card you buy is supported by "FreeBSD". If the card is Intel branded, you'll be good.

Using these rules and pfSense is up on running in .... 5 minutes ?

Later on, you can always activate the Realtek NIC again, and see if it plays nicely. Not all of them are bad.

And again : Wile installing pfSense, you have to assign networks, as a router needs a WAN and a LAN.
You also have to create your own password.
And here it comes : if you use or see a wizard that talks about 'DNS' do not touch your keyboard. Use the mouse, if possible, and enter nothing. Just click on 'Next'.
Next has been chosen by Netgate as the perfect DNS setting.
pfSense will work out of the box.
Up can now see the available package list. and install what you want.

And as "realtek", later on, you can adapt your DNS settings if you want to.
"It will break" but now you can "step back" and it works again.
After the wtf phase, the conclusions that you will make at that moment are very important.

I managed to mitigate this somewhat by changing the configuration of the offending interface to static address assignment. That didn't prevent it from going down, but it did at least keep OpenVPN tunnels not bound to that interface from needing a restart. The WAN interface in question is passed through from an AT&T residential fiber gateway / ONT. It's an Intel I-225 for what that's worth.

I'm not convinced the interface isn't at fault, so I switched over from the igc0 interface to a vlan on my main NIC, which is ix0. That wastes a NBASE-T switch port but works ok so far.

@McMurphy said in Client Specific Overrides Security:

but if all users on on the same VPN server how best to differentiate between users to firewall some and not others?

With firewall rules.

In the CSO you can state a unique virtual IP (tunnel network) for each client. Then you can use this in firewall rules as source to allow certain accesses.

@slu OK, thanks for the suggestions, I will investigate when user is available.

I just also found it on the Tunnelblick website.
https://tunnelblick.net/cTunnelblick4.html

@viragomann
Thank you. Long day and was not thinking.
I was thinking outbound traffic was on port 1194

@labu73
pfSense uses the reply-to tag to route response traffic to public sources back to a non-default gateway. Otherwise it would be routed out on WAN.

The reply-to tag is added by the filter rule, which allows the incoming request packets. So this rule has to be defined on an unique interface.
However, OpenVPN is an interface group including all OpenVPN instances, which are running on pfSense AND rule on interface groups as well as floating rules have precedence over rules on member interfaces. That's why this rule got hits, while the rule in the interface didn't.