@marcosm Okay I see what you're saying. With this option turned on, when you kill radvd, it basically sends a weird "okay, good night and good luck" message on its way out the door which clients will hopefully pick up and expire their discovered prefixes (The manpage says "encourage") If they hear it. Cool trick (and not a thing I've ever seen real Cisco routers do), and maybe radvd could be extended to continue sending that expired prefix notification even after a restart, if it can pick up that stale prefix from somewhere, but this post is about OpenVPN. OpenVPN clients don't listen to RA's. They use their own internal DHCPv6-like implementation (where the server tracks and assigns ips), and which subnet the server uses is never magically picked up from the interface, since it's not on the interface. Unless I'm misunderstanding you?

It's only ignored, not a fatal error, so it's not critical to remove yet. They do not have a timeline for its removal, so there's no hurry to change it at the moment. We usually drop options to "legacy" when they cause a failure or otherwise have a negative impact. Leaving them in place as they are now increases the compatibility of the generated configuration files with a wider range of OpenVPN client versions.

@Autourdupc said in OpenVPN issue when unautorized login attempt: One side, external : LAN2 with NAS2 -> Freebox (router) -> WAN Other side, office : LAN1 with NAS1 -> pfsense (router) -> Freebox (router) -> WAN Purpose : NAS1 sends backup to NAS2 Replace 'Freebox' with 'Livebox' and you have exactly my same setup. I backup my work Synology diskstation to my home Syno diskstation, using Hyper Backup on one side (work) and the counterpart 'The Vault' at the home side. Since I have fiber at home and at work, this has became a usable option. Renting 10 Tera somewhere was way more expensive. Previous upload speeds (VDSL) made this nearly impossible anyway. I used OpenVPN in the beginning ... but then I started to think : the communication channel is 'ssh' and the distance isn't that far. SSH means : traffic is TLS encrypted. The data copied are already encrypted Macrium Reflect backup files. Do I really need an encrypted VPN channel over an encrypted channel with data already encrypted ? Btw : the data is company related (a hotel) and we don't store private client info, maybe just their name, and their bills and so on. Since I stopped using VPN, my backups always terminate every night, and it takes some 60 minute s or so to transfer something like 250 Gbytes. I do use OpenVPN for remote admin access. Just UDP. Never had any issues with that. The only 'VPN' "errors" I see are these : [image: 1778046306704-e46a8a08-5bbd-4e60-8c34-9876e6a2fd1e-image.png] and these are, imho, just packets from scanners trying. The OpenVPN isn't restarted.

@Gertjan Thanks, I appreciate your research. That was a while ago when I got services working as I expected. Once I was confident, I understood what the expected SMB handshake should look like, I could see there was a ton of congestion, and the packets were just getting dropped. I don't remember exactly what I uninstalled or disabled to improve SMB traffic, however. Assigning the ovpns1 to an interface is an interesting choice. I believe configuring firewall rules on the OpenVPN tab may achieve a similar result.

@Gertjan Are there by any chance any other logs I can check?

After the adjustment, it has been working well for some time now, and the issue appears to be resolved.

i have the exact same problem as you do and pfsense has set it to dynamic and grayed out the option to change it to static and netgate support wont help at all

@Gertjan Previously, swapping locations would sometimes still get TLS errors, but that was due to not separating the CA authorities, like you did in your photo. Thanks for capturing that. Now, as of 11 April at least one .ovpn file (chosen at random) downloaded without the second CA. Fortunately, by offering just the CA 3 that matches your photo, it all works again. The authority now expires in 2124, and certificate 2066 as you documented. With that, reviewed all settings, and that finally resolved the TLS errors/cert expirations/or connection failures. ExpressVPN / pfSense immediately connect. Everything is looking great. ***While at it, another major company has Certs expiring this summer too (related to secure UEFI keys for booting). So, ensure auto update / latest updates are on for systems/devices before the expiration this summer. Auto update seems to be the preferred route.

@Manhbkas270495 Read the documentation https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/index.html And read about iroute. This is what you need

@Gertjan Ah haha Noted. And thank you so much for the help.

@sgw this is the way to do it. And no it's not scary.

And it still fails the same way? Check the states in pfSense when you're trying to connect. Do you see the incoming state on WAN? If you don't see a state do you see blocked traffic in the firewall log?

@ToTalChaos1010 I installed 2.8.1 and restored working configuration from 2.7.2 OpenVPN client got error: write UDPv4: Permission denied (fd=5,code=13) I was unable to find out why, but the problem was solved just by deleting OpenVPN client and make a new one from scratch.

okay, thought it might be just a typo... Is your openVPN server running on pfsense itself? What are your rules for the openVPN Interface? Your openVPN tunnel IP range is 10.8.0.0/24 (?)), so your vpn client gets some out of there... As @Gertjan said: make sure your openVPN inteface has the rules needed to ping and reach your LAN (192.168.4.0/24)... Also as @johnpoz said...do you have your vms and servers and other stuff behind another firewall? VMs i.E with proxmox server and there firewall active? NAS running with its own firewall active? Then go there and allow either your VPN tunnel net or (better imho) give your VPN client a static IP (iE 10.8.0.2/24) and allow just that one...(and others, if needed). :)

@Gertjan My assumption is #3686 was not implemented as outlined, and that functionality was implemented as "nas-port" - which unfortunately isn't recognized by Windows Server NPS as far as I can see.