@mgideon It boils down to how do you authenticate your users to deliver secure information. pfsense doesn't have something automated in any case.

Does anyone have any thoughts around this? Or maybe this is of no concern to most users or IT security admins?

@trever So you fail to access VPN clients? Consider that each client run its own firewall. And firewalls of different operating systems can have different default settings naturally. Maybe you noticed that your issues concerns Android devices only.

Hi @viragomann, You're my hero! I've added the certificate to the certificate manager and selected this certificate in de VPN config and that was the solution. Thank for your help :-)

@scooter17 Thank you for this excellent solution. I can quite easily deploy an OpenVPN Linode. https://www.linode.com/docs/guides/openvpn-marketplace-app/ This seems much easier than loading BSD and PFsense, but I assume you found that you needed more than the OpenVPN capability. I am relatively new to self hosting, and any learnings or reasons for one route or the other would help me.

@daveo132 Possibly something messed up the interface settings.

@zz00mm Oh good grief! Thank you very much for the extra nudge which got me across the line... You are right - I don't need to re-install, it works fine "when you get the syntax right". In this case the "syntax" was collected from a post above in this thread, which appears to do the wrong thing. This works: /usr/local/sbin/pfSsh.php playback svc restart openvpn client 1 The syntax in the post above uses the keyword SERVER which may restart the server, but doesn't restart the client! So I was also right when I remembered that it used to work previously - because I had the syntax right then, but I copied the wrong advice....what a muppet! So now we have a mechanism to restart the OVPN client on demand, and the cron jobs in place to check & restart as required. I do like your technique of changing locations daily - very sneaky 10/10. I consider this issue closed, don't expect to add any updates as it will almost certainly be fine now. Thanks. "Permission to engage smug mode sir?" (Kryton)

@oguruma In the OpenVPN server settings remove the check at "redirect gateway", instead enter the networks which the clients should be able to access into the "Local networks" box. If it's only that one server you can enter a single IP with a /32 mask. Since the clients can apart from this route anything over the VPN on their own, it's a good advice to restrict your firewall rules accordingly. Instead of allowing access to any destination on the OpenVPN interface limit it to your needs. Also you might have an Outbound NAT rule for the OpenVPN tunnel network (possibly added automatically by the wizard and removed again by unchecking "redirect gateway), which you can remove, if no WAN outbound is desired from VPN clients.

More on this - mostly for my own notes: Jan 29 00:14:50 pfSense openvpn[75977]: Inactivity timeout (--ping-restart), restarting Jan 29 00:14:50 pfSense openvpn[75977]: SIGUSR1[soft,ping-restart] received, process restarting Jan 29 00:14:50 pfSense openvpn[75977]: Restart pause, 5 second(s) Jan 29 00:14:55 pfSense openvpn[75977]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jan 29 00:14:55 pfSense openvpn[75977]: Re-using pre-shared static key Jan 29 00:14:55 pfSense openvpn[75977]: Preserving previous TUN/TAP instance: ovpns1 Jan 29 00:14:55 pfSense openvpn[75977]: Socket Buffers: R=[42080->42080] S=[65507->65507] Jan 29 00:14:55 pfSense openvpn[75977]: TCP/UDP: Socket bind failed on local address [AF_INET]99.229.125.21:6001: Can't assign requested address (errno=49) Jan 29 00:14:55 pfSense openvpn[75977]: Exiting due to fatal error Jan 29 00:14:55 pfSense openvpn[75977]: /sbin/route delete -net 192.168.110.0 10.0.8.2 255.255.255.0 Jan 29 00:14:55 pfSense openvpn[75977]: Closing TUN/TAP interface Jan 29 00:14:55 pfSense openvpn[75977]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1561 10.0.8.1 10.0.8.2 init

Restricting access via OpenVPN to only TCP port 3389 (RDP) and possibly DNS (TCP/UDP53) to your internal DNS servers should reduce your exposure a fair bit.

@viragomann said in OpenVPN on another public ip address: Requesting the whole config seems quite dubious to me. It didn't ask him for his configuration, he asked for his wan-side firewall rules and I showed him how to make a backup since he asked. @jptferreira said in OpenVPN on another public ip address: @silence on pfsense I still can't find an easy way to export settings besides taking screenshots... any hints on how to do it? Thanks waiting firewall rules wan

@viragomann The server routing table was missing the route for 192.168.2.0/24 . I added it in the OpenVPN server Custom Options box: route 192.168.2.0 255.255.255.0 The server side is now able to access client-side local IPs. Thanks for your help!

Thanks for your solution. Now I have the problem that i can't filter the dhcp server for separate dhcp server in each site. In a non-virtualized environment it need 2 simple rules on vpnbridge in each site

@jamespedersen-brightpattern-com Thanks! Will test your recommendation: VPN > OpenVPN > Servers > Edit > Advanced Configuration > Custom options push "route 192.168.1.0 255.255.255.0"; push "route 10.0.100.0 255.255.255.0"; reneg-sec 28800 auth-gen-token 43200

@someusername If you were missing routes, you could not access the remote devices, even with a single connection. A member wrote here that his Ubuntu client changes the default route and points it to the server, even if the server is not set to push "redirect gateway". But possibly one of your server is. With former version of NetworkManager I'd experienced this as well, but I'm not on Ubuntu.

@jknott said in Quotom J1900 / ExpressVPN Performance: I also have a Qotom computer (see sig) You have an i5!! The TO is talking about a J1900 and OpenVPN troughput. The i5 has 5 times more power. It would not surprising me, if this is due to CPU limits.