@gasper_gt In the OpenVPN server settings check "Redirect gateway". This pushes the default route to the clients. Additionally there is an outbound NAT rule necessary on WAN for the the source of the VPN tunnel network. If it isn't added automatically by pfSense you have to configure it manually.

@mrneutron hmm I have never seen that, but I don't recall an outage of that long in very long time.. Normally the outages here are very short, like 1 hour is really long outage.. We had pretty bad storm last night in the area, lots of people in the area out for really long time (downed trees taking out lines I think) - still out I think for some, but we were lucky my power bounced, it was maybe 10 seconds if that.. Long enough to reset all the clocks etc. But I didn't even hear my upses start beeping that they were off Ac. Just long enough for all my smart lights to turn on because of the outage.. You know power bounced in my house because all the smart lights turn on when it comes back - hehe.. I have one of my alexas on ups so when it bounces like that I can turn off house without having to wait for all the alexas to reboot ;) And since network and internet are still up when have a power outage can normally still control stuff from the one alexa.. But if you loose internet like that, you should prob just need to reboot your modem and not even worry about rebooting pfsense. But hope the reject thing helps.. Heres hoping though you don't have to see if works for a long time.. Power outages suck ;) We did have one long time ago where we were out for 3 some days, but electric company even paid for food we lost in frig, etc.

@viragomann Thank you! Went with two servers and now everything is working as expected.

@johnpoz That is interesting. I can go back and look and previously exported files and it doesn't show the ^M characters. It's just recent ones that I've noticed it. Things seem to be working though, so I'll just accept it and move on. Thank you for taking the time to look at it for me.

@anthadeas You client tries to connect to an IPv6 and an IPv4, each port 1194, but your server is listening only on an IPv4, which is another one then the client tries to connect to. So what does your client log show? Are these connection attempts to different servers? If it is the same host name resolving to both, IPv4 and v6 ensure to enable both on the server. Use the client export utility an export the whole client config and import it again at the client. Note: for quick step back pfSense stores some config changes, which you can easily go back in Diagnostics > Backup & Restore > Config History.

Thanks to this fantastic forum I was able to solve my problem. Thanks a lot to everyone and especially to @ viragomann

@viragomann Thanks very much for your support. Now I have been able to understand well how nat outbound works and how to set the rules. The passage to the rule works perfectly through the openvpn and my problem was related to the insertion of the door in the translation part. The pfsense forum is the place where thanks to very competent people you can find all the solutions. THANK YOU

@viragomann The Ubuntu previously a NAT gateway + Virtualbox host + file server + others. Now I replaced the gateway role with pfsense VM. Maybe I can't restore the network setting of the Ubuntu. If so it is out of this forum. Thank you for your reply.

@viragomann Ok thanks for the help I will try it out. Really appreciate all this info.

Thank you @bingo600 for your help, advice and clear information. I will implement it like you advice and give you a feedback :-) Thank you

@parkerask_centuryci I had to remove the line to bring up my secure tunnels again today. Right now I have removed it till we can find a way to have the tunnels come back after the Firewall reboots in the morning. I do not want to have to do an hours work for it to come back for the day.

@viragomann Nothing unusual AFAIK... (note that I grabbed the raw log so its chronological order (oldest lines first) May 29 07:43:34 pfsense openvpn[73684]: Validating certificate extended key usage May 29 07:43:34 pfsense openvpn[73684]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication May 29 07:43:34 pfsense openvpn[73684]: VERIFY EKU OK May 29 07:43:34 pfsense openvpn[73684]: VERIFY OK: depth=0, CN=gateway1.nordvpn.com May 29 07:43:34 pfsense openvpn[40473]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634' May 29 07:43:34 pfsense openvpn[40473]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' May 29 07:43:34 pfsense openvpn[40473]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:43:34 pfsense openvpn[40473]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:43:34 pfsense openvpn[40473]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512 May 29 07:43:34 pfsense openvpn[73684]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634' May 29 07:43:34 pfsense openvpn[73684]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' May 29 07:43:34 pfsense openvpn[73684]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:43:34 pfsense openvpn[73684]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:43:34 pfsense openvpn[73684]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512 May 29 07:46:45 pfsense openvpn[56921]: VERIFY WARNING: depth=0, unable to get certificate CRL: CN=gateway2.nordvpn.com May 29 07:46:45 pfsense openvpn[56921]: VERIFY WARNING: depth=1, unable to get certificate CRL: C=PA, O=NordVPN, CN=NordVPN CA7 May 29 07:46:45 pfsense openvpn[56921]: VERIFY WARNING: depth=2, unable to get certificate CRL: C=PA, O=NordVPN, CN=NordVPN Root CA May 29 07:46:45 pfsense openvpn[56921]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA May 29 07:46:45 pfsense openvpn[56921]: VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA7 May 29 07:46:45 pfsense openvpn[56921]: VERIFY KU OK May 29 07:46:45 pfsense openvpn[56921]: Validating certificate extended key usage May 29 07:46:45 pfsense openvpn[56921]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication May 29 07:46:45 pfsense openvpn[56921]: VERIFY EKU OK May 29 07:46:45 pfsense openvpn[56921]: VERIFY OK: depth=0, CN=gateway3.nordvpn.com May 29 07:46:45 pfsense openvpn[56921]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:46:45 pfsense openvpn[56921]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key May 29 07:46:45 pfsense openvpn[56921]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512 May 29 08:38:45 pfsense openvpn[56921]: write UDPv4: No route to host (code=65) May 29 08:38:45 pfsense openvpn[73684]: write UDPv4: No route to host (code=65) May 29 08:38:45 pfsense openvpn[40473]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[73684]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[40473]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[56921]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[40473]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[73684]: write UDPv4: No route to host (code=65) May 29 08:38:46 pfsense openvpn[56921]: write UDPv4: No route to host (code=65) May 29 08:38:47 pfsense openvpn[40473]: write UDPv4: No route to host (code=65) May 29 08:38:47 pfsense openvpn[73684]: write UDPv4: No route to host (code=65) The internet was down during that time because the VPN ceased to function.... Other than that, I dont think I had an outage, and the WAN was still up and connecting fine.... There's an ISP cable modem upstream of pfsense but its in dumb mode (bridge mode) and has been for many years without issues....

@lasouris Our documentation has plenty of recipes: IPsec IPsec Site-to-Site VPN Example with Pre-Shared Keys IPsec Site-to-Site VPN Example with Certificate Authentication IPsec Remote Access VPN Example Using IKEv2 with EAP-MSCHAPv2 IPsec Remote Access VPN Example Using IKEv2 with EAP-RADIUS IPsec Remote Access VPN Example Using IKEv2 with EAP-TLS Configuring IPsec IKEv2 Remote Access VPN Clients IPsec Remote Access VPN Example Using IKEv1 with Xauth IPsec Remote Access VPN Example Using IKEv1 with Pre-Shared Keys Routing Internet Traffic Through a Site-to-Site IPsec Tunnel OpenVPN OpenVPN Site-to-Site Configuration Example with SSL/TLS OpenVPN Site-to-Site Configuration Example with Shared Key OpenVPN Remote Access Configuration Example Adding OpenVPN Remote Access Users Installing OpenVPN Remote Access Clients Authenticating OpenVPN Users with FreeRADIUS Authenticating OpenVPN Users with RADIUS via Active Directory Connecting OpenVPN Sites with Conflicting IP Subnets Routing Internet Traffic Through A Site-To-Site OpenVPN Tunnel Bridging OpenVPN Connections to Local Networks OpenVPN Site-to-Site with Multi-WAN and OSPF