@yakatz said in One server out of 5 keeps stopping: I don't see any mention of it in the logs. If logging is enabled, where should be any entry in the log though regarding the server went down. Either in the OpenVPN log if the server was shut down in due form, or in the system log if it crashed.

@mpcjames glad I could help.

@modesty said in Client export - no configurations available: This "help text" I dont understand what to do... It says : If a client is missing from the list it is likely due to a CA mismatch between the OpenVPN server instance and the client certificate, the client certificate does not exist on this firewall, or a user certificate is not associated with a user when local database authentication is enabled. which means ... what it says. When a 'client' uses a VPN connection, it should 'authenticate' against the pfSense OpenVPN server, at the connection needs to be secured. And you have a choice : A user name and password. A certificate st, assigned for that user. Or a combination of both. You've set up a OpenVPN server, you can see the "access mode" : [image: 1639726821841-b2b463b7-c6ed-4354-9f17-389cf62b20e7-image.png] You have made a choice here : [image: 1639726871161-93502a9d-2fd9-4634-af96-291a397d0474-image.png] If could create a user + password here : [image: 1639726910738-5cc6ee04-8442-4c4e-8520-2a8cbf577233-image.png] and - important, assigned it to the OpenVPN user group, the OpenVPN client export utility can't find a user to include in the export files. Or create a 'CA' certificate here : [image: 1639728519102-e87f5c2a-ba0f-437c-893a-b88034d5fc47-image.png] I called it "CA-openvpn". As you can see,, it's in use by my OpenVPN server right now. This CA cert is only created ones. After that, for each user (do not share certificates among users !!) you create Certificates : [image: 1639728823425-11ba180a-74b8-45c8-be64-5f8c8bee5f53-image.png] This one is for me, for my iPhone. I also created one for my pad, one or two for the PC's I use to remotely access this pfSense OpenVPN server. Again, this certificate is in use right now by the OpenVPN pfsense server. Note that this CA certificate is assigned to the OpenVP server : [image: 1639729087843-e5b7de2b-c61b-4ce3-aa04-dcaa31afcb53-image.png] Because I chose : [image: 1639728938281-0104ea83-044d-4ebe-851b-5b723f41fcff-image.png] which means 'only certificates' (and no user or password), I now have this listed on the OpenVPN client export list : [image: 1639729003496-ceaadc91-b136-4008-85d4-afce76204731-image.png] Now, read again : If a client is missing from the list it is likely due to a CA mismatch between the OpenVPN server instance and the client certificate, the client certificate does not exist on this firewall, or a user certificate is not associated with a user when local database authentication is enabled. and I'll bet that all is clear now. and If you have Youtube installed, go here Youtube > Netgate > Configuring OpenVPN Remote Access in pfSense Software - it's a bare minimum 'need to know' video, but it explains the steps. Several other, far more detailed OpenVPN videos are also a viable. They are old, but do still apply. A couple of thousand other pfSense OpenVPN video's also exist. An there is the manual, in the top right corner, right in front of you, one click away.

@daddygo Hi Seem to have this matter resolved. First, used a Class C private IP address subnet for the VPN client. Second, the matter with the Android Chrome Browser SSL/TLS was resolved with revoking the certficate I was using for the WebConfigurator, deleting it and creating a new one. Only with the new one for the SAN (Subject Alternative Names) I specified the FQDN of the firewall as well as supplying the IP address for the local LAN and the WAN subnet. Connected without the error message after importing the relevant certs into the Android Cert Store. Having checked the OpenVPN logs, I am getting a number of warnings such as; WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1601', remote='link-mtu 1585 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' as well as number of messages stating; Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #6 / time = (1639703647) 2021-12-17 01:14:07 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings and TLS Error: incoming packet authentication failed from [AF_INET]92.40.192.240:33082 The VPN link appears to be ok and holds up I have a concern these may be producing problems. Do you have any insight as to how these could be mitigated? As stated, I have tested this on Android mobile and it could be down to link quality with 4G but I'm not sure. Any insight as to these? Thanks for your consideration. Regards...

@viragomann said in Best practice for site to site, hub and spoke setup: @bp81 Yeah, you need a configure CSO when you have a site to multiple site setup. This way you tell the server which remote network is behind which client for proper routing. Took me a while to realize that the vanilla client/server setup specified the remote networks to the server, but doesn't tell the server which gateway in the tunnel network to use for a particular LAN. Obvious in retrospect.

@viragomann Thanks for your crazy fast reply. It works :)

@viragomann I always wondered if the space matters. It turns out I'm wrong in what "works" -- while the routes are being created for both server subnets (and traffic is passing from Server->Client and back), Client-initiated traffic will only route to the first listed subnet. I've removed the space, and things look promising. We'll see if this holds up. If so, I can't believe it's something so stupid.

@justanotheruser pfSsh.php playback svc restart openvpn server 1 And here in a cron: 10 10 * * * root /usr/local/sbin/pfSsh.php playback svc restart openvpn server 1

@viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration: Possibly there is network or route overlapping on that interfaces with the remote 10.30.51.0/24. This is correct. The 10.30.51.12, 10.30.52.12 and 10.30.53.12 hosts are Windows Servers acting as routers for local 192.168.6.0/24 networks. This overlapping is causing the connectivity problem on the VPN when the 192.168.6.0/24 NIC is enabled. I could make this secondary LAN unique in each site so that there is no overlapping, but for now this is Ok. @viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration: As far as I know this is needed by pfSense to route traffic to OpenVPN. Ok.. Well, everything is working fine so far.. Thanks!

@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.