@gertjan said in OpenVPN server broken after upgrade: @squeakie pfSense 2.5.2 uses a new version of OpenVPN - see the pfSense release notes. This might, depending settings used, have an impact on the server client traffic. Did you exported clients settings ? Check also if "Tunnelblick 3.8.7a (build 5770)" supports the OpenVPN version that is used by pfSEnse : [2.5.2-RELEASE][root@pfsense.athome.net]/root: openvpn --version OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 24 2021 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 The Openvpn version is 2.5.2, identical to the pfSense CE version, that's just a coincidence. OpenVPN 2.5.x had a lot of changes compared to 2.4.x (see OpenVPN 2.5.x release notes). Hi, Thank you for your response, I actually got it to work again after reading some other post that had similar issues. I only allowed some AES 192 CBC chipers and checked the tickbox "Do not include OpenVPN 2.5 settings in the client configuration." during export.

@ilya-v authentication and encryption is better setting. Your clients just need to know to use it as well.

@jaci said in LAN Access to OpenVPN Clients without Site-to-Site: PfSense as OpenVPN server Also as default gateway? The primary issue here is that PfSense is routing the entire tunnel subnet (10.99.99.0/24) to the first client address (10.99.99.2), regardless of topology (subnet/net30). If a client is connected at 10.99.99.6, it is unroutable from the Pf box. This limits only a single pingable client at a time on 10.99.99.2, which is not desired for my use case. Normally there shouldn't be any issue. Since all the OpenVPN clients are within an L2 which is connected to pfSense, there is no need for any route at all. If pfSense is the default gateway and you have a proper firewall rule on the LAN, LAN devices direct traffic for 10.99.99.0/24 to pfSense LAN interface. pfSense passes it to OpenVPN and OpenVPN will know, how to forward the packets to the clients. Both the server and client override configs only specify the tunnel IP range (as well as the local accessible range for the server, with deny rules in the firewall for the backup server clients). The CSO overrides the server config, therefor it's called "override". As long as there is no pass rule on the OpenVPN interface, no access will be allowed anyway. If you have an interface assigned to the OpenVPN server, remember that the OpenVPN tab is an interface group including all OpenVPN instances. Rules on this tab will have priority over interface tabs.

Anyone?

@ovidius Do you have firewall rules on the client site LAN to allow access to the server?

@pinballwiz said in NordVPN Obfuscated Server Use: I was hoping that I could switch to a obfuscated VPN server to alleviate VPN detection so that all sited work, Not on networks that behave like the internet. There must be a source IP and destination IP. Otherwise there will be no traffic. And yes, it probably happens : big companies (employees) subscribe to the same VPN offers as you. They test out all VPN servers for that VPN provider in every country of that provider, note down the IP used, put them all on a list, and block these.

@gertjan said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2: He isn't pushing "10.0.10.0 255.255.255.0" (right ?) No he isn't pushing it - but you wouldn't need too.. The problem I saw with his configuration was that pfsense showed no route for his tunnel. [image: 1638702626881-tunnel.jpg] So something glitched or his instance wasn't actually running as I showed. If the instance is running there should be routes on pfsense for that tunnel network. See where I tuned off my instance and the route went away. My point about pushing as well - is there is really no reason to have to add those. As long as you list them as local networks they are auto pushed.. You don't need to add them to the options box, etc.

@audiobahn If a device is accessible from other devices within the same subnet, but not from the VPN or other network segments it should be accessible from outside with NAT though, because this way the packets get a source IP from its own subnet. However, in most cases it is the firewall on the respective device itself, which is simply blocking outside access. So the NAT is a hack and not recommended. You should better configure the devices firewalls accordingly. There are only rare dumb devices, which have no possibility to configure a gateway, where NAT is a good workaround.

Likely because OpenVPN is single-threaded? The faster that one core is, the better.

@viragomann Thanks for your clear explanation, got some rules to set up!

Yes, right and no change :)

@mikeyno said in Using DNS from VPN Provider (ExpressVPN): The help text implies that "Pull DNS" should cause pfSense to use DNS servers assigned by the OpenVPN server. Agree. So there might something be wrong.

@m0l50n said in Errors on OpenVPN logs server: I mean, 2 clients from the same location connecting to the same OpenVPN server (same WAN IP) on same protocol (UDP) can be problematic?!?!? Not problematic. The ports are different. You have a OpenVPN set up to listen on port 1200 and you have another OpenVPN server set up to listen on port 1195. Two complete separate instances, using their own settings. Example : many web server have two processes running : One web server, listing on port 80, doing the ancient "http" stuff. Another web server using other settings (with some TLS settings added) listens on port 443 and handles the "https" access. Both web server process serve the same data, doing the same things. It's just the "communication channel" that chances.

@jimp ok, thanks I see that now. both the VPN servers are Asus AX-11000 routers, so I guess I'll have to install a pfsense box at one of those locations because I don't see any way to change the CN.

I confirm your solution is so simple and working very well. I just renew the server certificate, client reconnecte to the server instance and continue to work like before. Thanks again!

Ditto. I couldn't replicate it on 2.6.0 / 22.01. Looks like it was fixed by https://redmine.pfsense.org/issues/12172

@viragomann I believe the problem is related to OpenVPN. Today the link SSH worked, but I lost it while I was working. From the log I see Nov 28 08:41:19 openvpn 46588 MyLoginName/MyRemoteIP:46059 [MyLoginName] Inactivity timeout (--ping-restart), restarting But I was working both on the pfSense dashboard and on a web panel of the server in DMZ. . Then I see many rows of this type, every 5-10 seconds. Nov 28 08:44:02 openvpn 46588 MyLoginNam/MyRemoteIP:45524 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2210 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings Finally I would not want it to be related in some way to the problem I have already reported in this post; after starting the VPN connection, after about a minute I lose the ability to access the internet although I have configured the Outbound.