@Lagan said in OpenVPN Client Specific Overrides ot updated until server restarted: I would like the new override to take effect when I restart the client. Hummm. It's possible that a save on the "Client Specific Overrides" page doesn't restart the OpenVPN server - I doesn't seem to do that. Maybe it isn't needed, as the server has a setting : client-config-dir /var/etc/openvpn/server1/csc/ that tells the server to look into that folder for client special settings, the "Client Specific Overrides". Anyway, I did restart the server, then connected the client and it got the '.30' IP.

@Enso_ I was talking about the firewall on the destination machine. To investigate the issue, sniff the traffic with packet capture on pfSense on the LAN interface and see if you get both, request and response packets.

Some more info... I am trying now to reconfigure my system by getting rid of all the VPN configuration and redoing it.. However as one last thing, I was going to try was removing my VPN Gateway and recreating it and subsequently assigning a VPN interface to it. However when I did that, my Internet access stopped working. i.e. the WAN_PPPeO gateway was removed under the covers! I wonder if this is the problem I am experiencing above: There is something weird in that the Gateway link on my rule shows that correct VPN gateway, including a red status when I hover over it, but when I click the link it opens to the WAN_PPPOE Gateway definition, not the VPN one. Which leads me to believe there may be something that happened during the upgrade? I even recreated the rule from scratch, with the VPN gateway selected, but it still clicks through to the WAN_PPPOE gateway? For clarity, on the Rules/LAN page where I have my rule to direct certain hosts to the VPN Gateway. it shows that I have my VPNgateway selected for the traffic. If I hover over the VPN link for the rule, It shows the VPN gateway state. But when I click on the VPN gateway link, it opens to the WAN_PPPoE gatweway definition, not the VPN gateway definition? if I inspect the link, the URL points to the actually WAN_PPPeE gateway with id=3 whereas the VPN gateway is actually id=2? I wonder if the backup/restore of my configuration is just screwed and I need to start over? Any ideas here?

@kamil-0 opcjach serwera OpenVPN odchacz opcję "Inter-client communication". Komunikacja między klientami nie powinna działać. Ale jak wrócę do domu to sprawdzę.

Here is my transfer performance using Wireguard DOWNLOADING FROM SERVER (Server upload performance) [image: 1705852885802-fa6458705745c2fe12cf2ee4b989de6b-1.png] UPLOADING TO SERVER (Server download performance) [image: 1705853123719-cbd266b143cfdf96762c54a44e8b5656-1.png] I'm very happy with these results.

@viragomann Thanks for the reply! I have checked this box, however when I do reload the tunnel (momentarily dropping it) traffic does route to the other network card, so it must not be blocking it

OK, so deep diving, this does not function as expected in pfSense if you try and chain CA certificates. It just doesn't and hard-fails. The only way to do this is to use a single-tier OpenVPN Certificate Authority and then things just work. Unfortunate, but this is a solution we can work with (everything's stored in a X.509 cert management utility so nothing is lost and everything is equally secure). Just annoying I can't use the intermediate chains...

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch. This will be probably fixed in one of the next releases then.

So your on-prem Webserver is also running as OpenVPN client which is connected to your gcloud pfSense? You are only running this one pfSense? What is your OpenVPN mode? -Rico

Hallo Zusammen, vielen Dank für die vielen Antworten. Ich werde das ganze am Wochenende mal trennen. Das macht Sinn ja. :) Aktuell komme ich nur nicht dazu, weshalb das ganze hier etwas eingeschlafen ist. Bei einem anderen Peer klappts scheinbar. Sehe merkwürdig. Aber ja, trennen macht sinn. Danke erstmal.

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

You have to forward OpenVPN packets on your ISP router to the pfSense WAN IP. The pfSenes WAN address should be static. Configuring an OpenVPN Remote Access Server If your public IP from your ISP isn't static, you will have to use a dynamic DNS service to have a static FQDN, which you are able to connect to from outside. The DDNS update should be done by the ISP router if possible. If it doesn't support that you may do it on pfSense, you can run a cron job with a short interval for that.

@careymichael I am having this same issue. When you said you had a static route pointed to the LAN interface, are you meaning in the firewall rules?

So uh... I totally disabled the VPN in order to be able to actually upload anything. Screenshot fail! Should be a little more enlightening here... [image: 1569284230474-img_2374.jpg]

Got it! Thanks so much for your help. I've changed a dozen settings in the last couple of days so it's hard for me to say exactly what did it. The last thing I did before it started working was actually to uncheck the box that says "Force all client-generated IPv4 traffic through the tunnel." And now when I go back in, it shows checked again... hmmm. In any case, it's working now and I hopefully won't ever have to do any troubleshooting ;) Thank you again for taking the time to help me.

Gertjan, Thank you, I changed it to 192.168.9.0/24 and now things appear to be working!! I'd tried that at one point but when I did the OpenVPN service wouldn't start for some reason, the log said something about a subnet mismatch (don't have log anymore) and I couldn't connect at all, when I brought it in to 192.168.0.0 the service would run. Not sure what the problem was before but it's working now. Thanks again!