Hello, I have the same problem on a pfsense box. I performed a fresh install on a VM on the same site with exactly the same configuration, and... no errors at all For your information, the log line refers to a return from a "write" call. write is the name of a function; it's a system call. https://man.freebsd.org/cgi/man.cgi?write(2) " The write() system call attempts to write nbytes of data to the object referenced by the descriptor fd from the buffer pointed to by buf. " https://man.freebsd.org/cgi/man.cgi?write(2) So, for the following, fd=6 is the file descriptor where we're trying to write, and code=13 is the error code retrieved just after the write call, which returned -1. " Upon successful completion, the number of bytes which were written is returned. Otherwise, a -1 is returned, and the global variable errno is Set to indicate the error. We learn that code 13 matches the description EACCES 13 Permission denied Either the process is not authorized to write to the file not helfull but : It's a permission issue; we're not supposed to be able to touch that from the web interface, I presume. Either it's a bug, or a third-party package is putting the problem in, etc. Contrary to what Google says, this has nothing to do with firewall rules.

@McMurphy Do you have an external BSD compatible cryptodev accelerator card or device outside of your AES-NI CPU? (These devices are extremely hard to find) If not why are you telling pfSense that you do? If you don't you should only use AES-NI CPU-based Acceleration only.

@ThaBozz No. OpenVPN just adds a route for the first client IP in the tunnel network to the system routing table. This just routes the traffic to the OpenVPN insctance. But the correct routing to the respective client IP is done inside OpenVPN. pfSense doesn't know at all, what happens there.

@chitchat Assuming the two VPN servers use all the same certs then it should be ok. In my case the single VPN server listens on Localhost. Then there's two port-forwards (one for each WAN) to the same VPN server. [image: 1759479867156-eed1a7f9-d88e-4da3-bb46-e723e73ed01e-image.png] [image: 1759479896297-6d8d4837-2ea9-43eb-95c0-08358cd644b3-image.png]

I figured it out...Used PureVPN pfSense 2.5.2 instructions and loosely https://vpnalert.com/guides/nordvpn-pfsense/ I changed the PureVPN pfSense 2.5.2 instructions in this manner: '17. Client Certificate: None' to 'Client Certificate: webConfigurator default (XXXXXXXX) (Server: Yes, In Use) Added after '23. Under Advanced Configuration:' Custom options: (from ovpn file downloaded from PureVPN) dev tun auth-user-pass persist-key persist-tun nobind compress With these changes it connected after 2 retries and has been connected for the last couple hours...Now to make rules to sent traffic to my newly added pfSense based always connected VPN. Hooyah!!!! Rudder2

@adrianp918 If your VPN client (on the remote device) uses the pfSense resolver as its DNS source, you could create a host name on pfSense for this printer. from then on you can use (example) : "printer.your-pfsense-domain.tld" as that will resolve to the LAN IP of the printer.

Just replying to my original post. The issue seemed to be something to do with Proxmox. I brought another PVE host into my cluster this weekend. As part of that work, I had to go to the Proxmox Datacenter view and go to "SDN > Apply" to push my Proxmox SDN "Zones" and "VNets" to the new host. When I did that, it went ahead and refreshed the Zones and VNets (and anything else that is SDN-related) on the existing PVE hosts - one of which was hosting my virtual firewall. To my surprise and utter delight, the previous issues of some internal websites not always working, and RDP often timing out and coming back - all that went away. I have no idea what was going on in the virtual bridges but at least now if I see those issues again, I'll know where to look for troubleshooting, and what should fix it. Hope this helps someone down the line. Hope I've put in enough keywords for web crawlers and AI. :) Cheers.

@marcelobeckmann Obrigado pelo contato em diagnostico/rotas existem varias rotas inclusive para 192.168.10.0/24 Meu conhecimento com PFSense é basico e fiz as congurações baseados em videos e tutoriais encontrados na internet para fechar esta VPN Site to Site Poderia me auxiliar como criar estas rotas e onde verifico se elas existem? Para adiantar vamos a estrutura DATACENTER - PFSENSE WAN: 201.46.121.XXX LAN_BLO:192.168.100.1/24 LAN_EFT:172.11.1.254/24 LAN_HPK:192.168.120.1/24 LAN_GTR:192.168.130.1/24 VPNSITETOSITE VPN_EFT - LAN_EFT DATACENTER X LAN_EFT CLIENT TUNEL IP: 10.0.11.0/24 LAN LOCAL: 172.11.1.0/24 LAN REMOTA 192.168.10.0/24 STATUS: FUNCIONANDO EM PRODUÇÃO PINGANDO NORMAL DA LAN REMOTA PARA LAN LOCAL DATACENTER. VPN_GTR TUNEL IP: 10.0.15.0/24 LAN LOCAL: 192.168.130.0/24 LAN REMOTA 192.168.10.0/24 STATUS: CONECTADA PINGANDO SO DE DENTRO DO PFSENSE LAN REMOTA NAS ESTACOES DA LAN REMOTA (192.168.10.0/24) NAO ALCANCAM NEM O SERVIDOR DE DADOS (192.168.130.242) E NEM O PFSENSE (192.168.130.1) AMBOS SAO ALCANCADOS DE DENTRO DO PFSENSE LAN REMOTA. JA USEI COMO BASE A VPN_EFT E NAO ENCONTREI NADA DE DIFERENTE QUE JUSTIFICASSE A VPN_GTR NAO FUNCIONAR|-left aligned paragraph

@viragomann Can you possibly elaborate on this? A floating rule on the client pf? both instances? (active and stby?)

@hossazaw said in Installing Openvpn package: I found the url on gpt and also searched for the package in the website but with no luck pfSense has its own 'package servers url' build in. Like Windows : no need to specify where to look for updates, Windows knows how to call home. be ware : if if you found that url, you can't use it with a web browser. It's a package server, not a web server. @hossazaw said in Installing Openvpn package: Whenever I tried to install the package from Webgui, it says "Please wait while the update system initializes" and nothing happens. A possible reason : and by far the most obvious one : DNS is broken. The code (script) used to request the package list is somewhat resilient, and won't take no for an answer that quickly, and will stay in memory for some time, trying many times. It could be a non local temporary DNS issue after all. All this time, only one instance of this script is allowed, subsequent requests from your (GUI) side will get "Please wait while the update system initializes" as an answer. If DNS couldn't be used by the update script, because it (for pfSense itself) doesn't work, it can take quiet a while before it times out. Subsequent request will also fail. To see better what actually happens : Use the SSH or console access, option 8. Start by reading this one : Troubleshooting Upgrades.

Problem has been solved. I rented a virtual server, with static public IP and everything is working as it should be. as far as I undaerstan, ISP is blocking certain traffic, despite forwarding openvpn ports in their modem.

@david283 You just change the rule to source any and set the corresponding destination ports to your liking. It is very simple if you ask me. Maybe show your rule if you still need help.

@Antibiotic said in OPENVPN DCO pfsense 25.07.1: @yon-0 f you ever connect to older OpenVPN servers (e.g., 2.4.0–2.4.4), you’ll need to disable DCO on your client to fall back to DATA_V1: The DATA_V2 format in OpenVPN is a streamlined, secure packet structure designed for use with AEAD ciphers (like AES-GCM or ChaCha20-Poly1305) and Data Channel Offload (DCO). It replaces the older DATA_V1 format and is required for kernel-level acceleration and modern encryption. When OpenVPN prepares a DATA_V2 packet: It selects an AEAD cipher Generates a Packet ID (used as part of the nonce) Encrypts the payload and attaches the Auth Tag Sends the packet with Opcode, Peer-ID, and encrypted content No IV or HMAC is needed — AEAD handles it all internally. Generates a Packet ID (used as part of the nonce) Sends the packet with Opcode, Peer-ID, and encrypted content how do it?

@DenverDesktopsSupport said in Update Tunnel Connected: 99281-pfSense-2-5-Setup-with-NordVPN Using pfSense 2.5 today is already a huge security issue, and probably impossible as the OpenVPN client from back then will not connect to the Nord OpenVPN server anyway. The pfSense OpenVPN Client GUI page also changed ... The documentation does mention the creation of a policy routing so all outgoing traffic goes over the NordVPN connection. After all, when a VPN connection is created, pfSense suddenly has two outgoing network interfaces so it might be necessary to inform pfSense what traffic needs to use what interface : WAN or VPN ....

I am following the Nord's instructions on this step which shows the webconfigurator. https://support.nordvpn.com/hc/en-us/articles/20382523899281-pfSense-2-5-Setup-with-NordVPN