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

Well after hours of trying different things. I think I might have found the fix. I have no idea if this was the fix because of the number of things I was trying at the end but this makes since to me. I didn't have these boxes checked and when pfSense made the gateways it didn't check the boxes automatically. [image: 1642722702554-24bde76f-16f2-4739-9ca8-a7ec475914ae-image.png]

After further testing, it appears this issue is limited to FREEBSD v12. I installed fresh instances of FREEBSD 12.2 & 12.3 and neither would resolve DNS over OpenVPN. I then installed FREEBSD 13 and DNS worked no problem. I still don't know why my hub's routing table looks like it does, with all remote OpenVPN subnets pointing to 172.27.120.2, but hey routing to all subnets seems to work so I guess I'll just ignore that.

@viragomann Yeeees! It works! I just added the destination in the first rule - local network. Now clients get van1 and van2 ip addresses, as I wanted to separate and have access to the private network. [image: 1642583640433-vpn_-openvpn_-servers5.png] Thank you very much for the help!!!

@jknott Yes i mean wan address. the clients are pointed towards a dynamic dns address which updates correctly to the new ip every time. @viragomann Thats already ticked.

@kromek The server assigns the pool IPs sequentially from the from the lowest up. So the CSO you should begin with the highest down. Ensure that your tunnel pool is large enough for all users. Also you may consider to uncheck "Duplicate Connection", so that a single client cannot grab multiple IPs.