I have found some more. This is apparently a known issue that is caused by changing the Monitor IP on an OpenVPN-Interface. Here is the bug report: https://redmine.pfsense.org/issues/8142 And here the discussion linked in the report: https://forum.pfsense.org/index.php?topic=138608.msg764734#msg764734 The issue is still present in 2.4.3-RELEASE (amd64). The only workaround I have found without resetting the system was to change the subnet of the Ubuntu OpenVPN-server to something different than x.x.x.0/24. x.x.x.0/24 seems to be forever blocked by the non removable route. If anyone has any updates in that regard, I would be highly interested, so please let me know! Kind regards, Holger

In the OpenVPN client settings check "Don't pull routes" to avoid to get pushed the default route by the VPN servers. Assign interfaces to each client instance and enable the interfaces. Edit the firewall rules on your LANs which are allowing the upstream traffic, expand the advanced options, go down to Gateway and select the appropriate gateway. In System > Advanced > Miscellaneous check "Skip rules when gateway is down". Consider that firewall rules with stated gateway allow traffic passing that gateway solely. So you will need separate rule to permit internal access it you need, for instance DNS to the pfSense interface.

@derelict Thanks Derelict. I will have a further look into it. It seems I cannot replicate this issue anymore, but not much has changed. I will return if I manage to figure it out. Thanks

There is usually no reason to use push route commands any more. Put the network in the Local Networks field instead.

@derelict I will try to post the network diagram. We are using two Devices at the Remote sites: An Intel NUC running custom data acquisition software which periodically publishes messages to the MQTT Broker at the central site . It initiates the OpenVPN channel to the central site via the 4G cellular wireless router. There is a power controlling/monitoring device at the site which has a web and SNMP interface. We need to occasionally check or reconfigure that from the central site. We would like to SSH into that device from the central site across the OpenVPN tunnel. All of this palava comes about because of the "carrier grade NAT" at these Remote sites, which means we don't have static IP addresses and DynDNS doesn't work so we need to open the comms channel from that end.

Hi Folks I tore the entire system down and redid it from scratch from the actual manual. This time it worked . So not sure what I missed but all is good now. Thanks for your input.

RESOLVED! The problem was the MTU of VPN! I had MTU 1500 but max of my openvpn machine was 1472. I add mssfix 1420 fragment 1472 mtu-test to openvpn client config and all works! Thanks!

@jimp said in OpenVPN - Connected Since time is wrong: What time zone did you select? Looks like you used one of the GMT offset zones which really shouldn't be used. Pick a geographically named zone and restart things again. Thanks I changed to Europe/London and it seems to be working well for now :)

@johnpoz Are you sure it is secure ? :) You mean register from DHCP ? Yes I do

Anyone have an ideas? I think it might be a route issue, but I'm not sure since sometimes the connections go though and sometimes they time out.

ok firewall rules created by openvpn wizard vpn server settings created with vpn wizard vpn client vpn file created by export wizard

I will follow the instructions and let u know, thanks for your help.

@johnpoz I suppose in the final setup it wont be needed as this will be the only gateway, but at the moment I need it as it is not our primary gateway just yet. Thanks for your help on this anyway John.

Check out the following guide which explains quite well how to set up multiple OpenVPN client connections in pfSense: https://www.techhelpguides.com/2017/06/12/ultimate-pfsense-openvpn-guide/

glad to hear. sometimes the small details make the difference

You cannot route the servers public IP through the tunnel. That would mean the vpn tunnel would be routed through the tunnel itself. How should that work? Access the web server by its internal IP. Also you can setup a split DNS and provide it to the vpn clients. So the client get the internal IP when they try to access the web server.