@viragomann
The router has no GW. It is set in bridge mode.
WAN port not used.
tplink.png

@mode said in OpenVPN Client does not connect after update from 2.4.4 to 2.5.2:

i see it will not be easy to fix this

Easy or not, most pfSense users use the latest version. 2.5.2 CE or equivalent if the use a Netgate device.
My pfSense OpenVPN server access for remote management works fine - using an iphone OpenVPN connect app, or the OpenVPN connect on a remote W10 PC (me at home).

@jimcorkery
NetBIOS is not supported across a peer-to-peer VPN.
As mentions you can provide your internal DNS server to the clients in the OpenVPN access server settings, but the clients may need to use FQDNs to access the remote sites, since they are not joined in the remote domain.

@dennis100 ah if your clients can not do it? Then you have a bit of a problem.. But that is something you would want to implement because it keeps noise away from your vpn.. Only authorized clients to actually even start a conversation with your vpn, etc.

But I find it hard to believe the viscosity client could not do that.. Its basic openvpn stuff.. Maybe not do tls-crypt, but they should be able to do at min tls-auth

edit: so quick google found this, so there might of been a problem with older client, but looks like from that that the viscosity client should for sure support tls-crypt

https://www.sparklabs.com/forum/viewtopic.php?t=2647

Here is tls-auth I found on their site. So clearly they support it, you would just need to set it up
https://www.sparklabs.com/support/kb/article/advanced-configuration-commands/#tls-auth

Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack.

In a nutshell, tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response.

Thank you so much for responding, @viragomann. It was solved

@johnpoz Ok, so I got this fixed. My older install only had a single Data Encryption Algorithms listed under the client side. The new had a bunch listed by default for some reason.

I made the new match the old and this appears to have corrected the issue, as the VPN's are working again.

Note that my REMOTE VPN's continued to work, only my PEER-PEER VPN's stopped working.

MP

I was able to resolve it.
By making Minute Changes on the VPN CLient Profile.

remote <Elastic_IP> 1194 udp //Change WAN IP with elastic IP #verify-x509-name "Netgate VPN Server" name //Comment this Line

@viragomann Looking around and found there is a "reject lease from" option under wan1 interface.

I think for some reason when pfsense reboots, upon restarting, it gets the dhcp of 192.168.0.254 from the ATT Modem. I put in "reject lease from" 192.168.0.254... I'll check tonight if this solves the issue.

Not sure if the ATT Modem's dhcp is passing out it's own ip address while it's asking upstream ATT server for the actual wan ip address.

Maybe someone with ATT can explain why modem's address gets pick up as the wan ip and then later renews to the actual wan ip.

Thanks!

@viragomann Thanks from my side as well... I've been struggling with this exact same problem and the firewall rules underneath the OpenVPN tab were the problem for me as well.

@clickerdeveloper
From what you described, I assume you have already checked "Redirect gateway" in the OpenVPN server settings and you policy route the LAN traffic to the VPN provider.

Hence the VPN gateway might not be your default. So you need also to policy route the OpenVPN clients traffic to the VPN provider. Also you need an outbound NAT rule for the access server VPN tunnel network, if it wasn't added automatically by pfSense.

It is likely that your VPN interface isn't enabled in pfSense. Open Interfaces and select the VPN interface that you added to System > Routing > Gateways and click the Enable box. Click Save.

Navigate to Status > OpenVPN and restart the service. It should show a green check mark and show local, virtual, and remote host addresses.

@wedwards Seems like pfSense honours the defaults from OpenVPN >= 2.6. From the documentation:

In 2.6 and later the default is changed to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 when Chacha20-Poly1305 is available.

@jewilson

I made that change to the client specific override and now OpenVPN Connect is allocating 192.168.2.2 to the client and not 192.168.2.0.

Thanks for the help.

@rduarteoliveira
Thanx for feedback.