@Gertjan Actually, the NAS's live on the USER .200 network. [image: 1761263490986-7a8e6a4a-bd88-4746-b972-590669a71219-image.png] Yes, it is a /24. [image: 1761263576735-dc59d4ee-7b17-45d3-adad-6b33724c9f4d-image.png] [image: 1761263615720-4f971d77-9f42-4fa1-8a2d-ad35737c6473-image.png] Yeah, I have the OpenVPN server subnets rule to allow all traffic. What advanced settings do you have in your VPN interface rule? I see a gear symbol next to the pass check mark. Is that something that may help? That private address assigned to my iPhone (10.208.190.248) is puzzling. It appears to be a Verizon thing. If I go to Starbucks and jump on their WiFi, or work, it shows the same address.. Just for kicks, I put that IP in the VPN interface rule shown above but that had no effect. My iPad does not have any of that since it has no SIM card.

@SteveITS I agree 100%, I'm not complaining its working again and I have notes on it, when they do "maintenance" in the area again... Glad the onsite tech new something more than the support back at ISP office... Brian

Just me as a PF Admin. These guys wouldn't know the first thing about it so would like to keep them out of even accessing PFSense UI over VPN among other things.

@Gertjan I have allowed pfSense's DHCP to dole out the IP for the AP. I tried assigning an IP as you recommend but it didn't help. I've also ordered another AP to see if there is something about the software there that's causing the issue.

Well, if this is correct as far, you should be close to get it working. @Udbytossen said in Portforword through a VPN client: And under the firewall rule advanced setting I'm changing the gateway to Torguard instead of default But already mentioned, that this makes no sense at all. So edit the rule and set the gateway to default. Then go to the OpenVPN rule tab and remove or disable each pass rule. Done.

Is your pfSense configured to work over both IPv4 and IPv6? I assume you have IPv6 on your WAN. 4G & 5G phones are IPv6 and Android phones use 464XLAT to access IPv4 sites. This is effectively double NAT, which can mess things up. I don't know what iPhones use, but they'd have something similar. By sticking with IPv4, you are already breaking things. IPv6 is the future, so you'd better get used to it.

Certificates for authentication are fine being self-signed with whatever validity you assess is good for you. The VPN-endpoint (the public address) should have a real public certificate. The CA-chain for this ertificate is part of the profile, so there is a caveat that you must check the CA-chain for changes when you renew the public endpoint cert. This however can be considered a rare event in a sense, and usually you get heads up when roots (very rare) and/or intermediates (more likely but still rare) change. If the chain changes, you must provide new profiles to all users, which can be a PITA of not prepared.

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.