@Hudson-1
So I expect, that pings to public IPs are working.
However, 8.8.8.4 is not a good advice. The server doesn't respond to ping requests obviously. Try 8.8.8.8 instead.

@viragomann
After the latest patch
Fix OpenVPN selecting wrong interface address when VIPs are present (Redmine #14646)
https://redmine.pfsense.org/issues/14646
I could be able to route out my traffic and the OPENVPN client works as it is requested.

@viragomann

thank you, I'll check that out

Fixed !! ...

I am so used to working on smaller 100% fibre based networks with min 1Gbe connectivity.

I forget this is more complex. And takes longer to replicate.

When you try and resolve the namespace it comes up with the primary DNS being the one furthest away that did not have a valid replication.

Thanks John!

Also, even if your client is up-to-date, if your certs use a weak hash like SHA1, then builds of OpenVPN based on OpenSSL 3 will refuse those certificates as well.

Nothing the client or server can do about that, you have to issue new certificates that don't use weak hashes.

If it's the encryption on the PKCS#12 bundle that isn't being read by the OS, you can always install the client manually and then export an inline configuration with the certs inside rather than using PKCS#12, or you can export a PKCS#12 bundle separately from the certificate manager using a higher level of encryption.

Any version of the export package newer than 1.9 should be capable of exporting a stronger PKCS#12 bundle directly in the export package:

https://redmine.pfsense.org/issues/13255

Hi @Stef93
Thanks for the suggestion! However it looks like the client end of the tunnel (10.10.10.2) is NAT'ing the traffic prior to putting it in the tunnel. So by the time it reaches the pfSense OpenVPN NAT Policy it is already NAT'd. I was able to solve the issue by creating a similar NAT Bypass rule using the the GL-iNet NAT interface. And that seems to be working. I appreciate your feedback!

@Stef93 Turned out that I have missed to add a Client Specific Override, but couldn't get it to work anyway.
Reading a bit more on Client Specific Override I found out that changing the tunnel network from /24 to /30 didn't need any override and then I got it working.
Thanks, you lead me to the solution!

@kohenkatz

I've had the same prefix for a few years. It's even survived replacing both the computer I run pfSense on and the cable modem. The IPv4 lease wouldn't survive either. IPv6 uses something called DUID, which is supposed to tell the ISP what your prefix is. I understand some ISPs ignore it. I have no idea what Verizon does. Maybe someone else here knows.

Looking at Logs can see these error too:

ovpn.client/WANPFSENSE:26059 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_9EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:957 0:956 t=1693552393[0] r=[0,64,15,1,1] sl=[3,64,64,528]

I've switched the ovpn.server to TCP protocol, now samba access works fine, also the http://SITEA/login can be loaded!

@big_blue ae3ff397-8c96-487f-91a7-41e3f0e4d517-image.png

656be457-7cc3-44aa-8035-74c9c894412a-image.png

and rules vlan19
5d5ee4cb-f017-44cb-8853-360f2360003c-image.png

be sure to put the first in the list of rules in vlan19
fe53de4a-6bd8-4ff1-bc48-3ae6fd435e30-image.png

6769f515-7213-4b90-9757-b759ee9a4896-image.png

@Jamil-Mungur and how was that exactly.. The dyndns was only updating once a day, or every 12 hours or something and the IP from your isp was changing at 7pm?

Pretty sure the default in pfsense is to update dyndns on IP change.. Was the ttl on the dyndns too long?

@Elyot
Why would you reset the appliance? You should be able to configure it for your needs based on what you actually have.

The linked thread shows you, how to route upstream traffic to a certain gateway. This seems to be, what you need here.

When you set up a VPN, you can decide if you want to use it as default gateway or not. Most VPN providers pushes the default gateway to the client. That means, any upstream traffic is routed over the VPN.

The mentioned policy routing in the other thread gives you an option to direct traffic to another gateway than the default one. If your default gateway is the VPN you can direct certain or all incoming traffic on an interface to the WAN gateway. If your default gateway is the WAN you can direct traffic to the VPN with it.

If you don't want the VPN to be your default gateway go to the OpenVPN client settings and add a check at "Don't pull routes".

@Summer

You resolved this is problem? I have the problem too...

@viragomann

I would call the Ubiquiti/EdgeOS at least a mid-tier product.

My opinion aside, this seems to have worked.

I can send you a gift card?

Thanks