Hi, Because of the differences, is it still a question for me which pfSense version is this? (for example, it's a difference...) [image: 1589966065569-a5e04914-dd2a-4541-837e-1c1e7326f70d-image.png] The second important thing is server mode (you use TLS), but that's all I see: [image: 1589965625870-a4666822-e747-4e05-9657-82e796510e7c-image.png] instead of: [image: 1589965661226-0b4e10a0-be71-4b2c-ad2c-d118a3478c69-image.png] I don't see your own cert for the connection either: [image: 1589965717587-8b5bbbd9-235b-4183-94a3-d0bd6e1d3d4e-image.png] instead of: [image: 1589965778044-8fd16d58-39b6-45f3-a24c-c4f941401cf3-image.png] like: [image: 1589965880180-ff6291f2-6a01-4d33-866c-1f5c2019df89-image.png] and even a VPN User is required: [image: 1589965936182-3397cc2b-5bbd-4e55-933a-bccc0f134c07-image.png] with: [image: 1589965989354-a4585c69-0d7d-49a8-8bc9-792285643332-image.png] exactly where does the DNS (10.0.1.31) point?? this is the box itself or a separate DNS server on the network

Hi, View /etc/inc/openvpn.inc. Locate the several function calls and definition at the bottom of the function called : openvpn_add_keyfile This function takes the directory, the extension, the PEM based64 encoded data and writes out the file. File rights are set to 0600 and that's it. It's line 760 in the openvpn.inc file. If something goes wrong at that place, I guess the $data that gets base64 decodes isn't 'ok' ? Is your cert ok ? Many cert type files are created using that function. When only "server1.cert" goes wrong, I gues it's input (= $data) is 'wrong'. An old 2.4.4-p3 bug that got resolved (?) ^^ edit : non. openvpn server was working just for for my when I was using 2.4.4-p3.

The OpenVPN connect app for iOS doesn't even support a bundle with multiple files like described for Viscosity to import automatically. You'd have to manually import the .p12 file into iOS separately from the VPN configuration in multiple steps as described on that link. We export the inline configuration because that's what the app accepts to import in one step. If it's insecure, the App shouldn't allow it or should offer to split it and import the keys securely. That's an App problem, not an export problem. We're helping you get the config into the App, that's all. If you don't want to do it that way, don't do it that way, but lobby Apple to change their practices and the App designer to support more secure practices. We could make an iOS "Bundle" but then the user would need to unzip it and copy all the files manually and do all the import steps individually to import the keys and the config. Seems like a lot of work for everyone (us, the users, etc) when the OS and App should be doing it better.

I uninstalled the OVPN client export package and rebooted and I was able to delete the CA and the Cert and add them in again. Also I used blanks in description so all that is OK. Once I get the configuration underway and get to the point I need the Client Export package I'll see if I can add another Server configuration. If there's a problem I'll report back.

@EdAdders said in Removing openvpn completely: this is still a problem: "UNSPEC" May 18 18:28:35 openvpn 18494 UDPv4 link remote: [AF_UNSPEC] if you still need help, we'll be here after a week too

There are some spikes once in a while. I was unable to find the root cause. You might be right in that it's caused by the provider itself. To midigate I put the packet loss monitoring threshold at 50/90 and disabled latency monitoring. If there is anything more to do/investigate, I'd be interested to know. [image: 1589792378275-ab5ef44a-1fa5-4b5c-9bc1-474e93783842-image.png]

Run the OpenVPN servers on pfSense and run pfSense in HA if you need redundancy.

Just tried it again...as soon as I change IP address range of OpenVPN server tunnel network from 192.168.75.0/24 to 192.168.120.0/24 all clients lose internet access. I change all rules from 75 to 120 as well as well as the one client specific override. Bizarre.

@viragomann Thanks, somehow thought it would be more complex. I see the entry and will give it a go.

@vnkvnk said in please help with openvpn: Even more info Using the pfSense - GUI access : does "100" reply to ping ? From "167" : "100" replies to ping ? Or better, can you see and your network resources exposed by "100" on "167" ? @vnkvnk said in please help with openvpn: changed manually IP to 1.168 When doing so - chanting the IP, check / set also the gateway IP, idem for the DNS IP, you can find these on the other tabs.. The last two should be the IP of pfSense.

No ... and yes. Using the GUI : no solution but click click click. Not using the GUI : You are the limiting factor of possibilities. First : Create one or two users manually. Do a config export, Diagnostics > Backup & Restore >Backup & Restore Consider exporting OpenVPN (server users) only. Yo wind up having an xml file with the correct format. Now, you can script as much as you want. You only have to respect the XML format. Import the file. Check for results. edit : if you are using certs as an identification, things will get a little bit more complicated, but the principal stays the same.

Shouldn't the Gateway at least reply when you "monitor ip" for the OVPN Servers' tunnel address? [image: 1589496101112-gatewaysstatus.jpg]

For reasons I had to kill and reinstall the server and the problem is back. If I connect from an external address, pf does not set the connection as 'Established' and kills it after ~30 seconds. Also weird: If I disable pf completely (pfctl -d), the connections is established and remains stable, so it's definitively pf that`s killing my connections. But since I can't leave the server with pf disabled, that's not an option. I've tried a few other tricks, like disabling TX Checksum Offload (https://xcp-ng.org/docs/guides.html#pfsense-vm), settings in the firewall, but couldn't find anything. Has any one else seen something like this?

@kevindd992002 No.

No, I was talking about that maybe ip address "52.4.131.46" not beeing the right one for the website, for "https://rilm.org" So i've setup the things like u've said, and after that i've got no internet access, which is a good thing, but it also cuts access to "https://rilm.org", which is a bad thing. The only thing working in browser, going somewhere, is "52.4.131.46", and it reaches that nginx test page that I was talking about. So, it looks more like a DNS problem now. The DNS's entered here in options are Google's public ones. I've also tried push "route 192.168.1.0 255.255.255.0" in Advanced Config, to no avail.

@Jxck Well, it certainly won't work, without it being configured on the VPN.