Just try to do it as written here: https://medium.com/@gmanual/pfsense-mikrotik-openvpn-site-to-site-b001c105843c

OSPF advertises remote network because you redistribute pfSense Kernel Routes. right? if yes try: option1 : uncheck pfSense Kernel Routes to stop redistributing it. Correct, when this is unchecked, OSPF does not learn about the route. It will work when pfsense1 is up and its link works because it is the default gateway. Once it loses its connection, it no longer works because the remote site traffic arrives on pfsense2 over the VPN but tries to return via pfsense1 (the default route). then OSPF in your local network will know about the next hob only which is pfSense 1 or 2 and nothing after them. once the traffic reach one of them it will follow openvpn routes. This is exactly the issue. Somehow, I need the local network to learn that pfsense2 is now the gateway for the remote site VPN traffic. still looking how to stop adding route when openvpn is down This would be great as it would mean everything would work.

Look at the OpenVPN logs they will tell you why it was failing to start.

resolved by adding the remote client subnets to the remote lan list on each end of the site to site config.

Push all LANs to the remote access client by adding them all to the "Local networks" in the access server settings. Additionally you have to add the remote access tunnel network 10.111.0.0/24 to each remote server by adding it to the "Remote Networks".

Got it! NAT was the key, vs modifying rules manually. I have now deleted the extra interface and all firewall rules and all is good. The .10 network no longer exists, I changed up the scheme (mentioned that above but probably wasn't clear). Thanks!

Sure. :) Thank you very much Lokesh Kamath

@juanki_hd hi, it seems to me that, you are using pfSense only......., because of the OpenVPN server @juanki_hd "I think it would be double NAT?" - (you already have one) your current system also have dual-NAT configuration (ISP router to USG = double-NAT, because RFC1918 192.168......172.10.......) BTW: pfSense has more serious abilities than a USG and is more customizable. all your problems will be solved, if you put your ISP device in bridge mode and pfSense will replace USG and USG will be listed on eBay (yeah, joke, but possible)

Could have been another case of those SSL problems with one of the Root CAs rotating their CA cert (old one expired). Perhaps working fine without actually "touching" / restarting it but now needed the new certificate chain to reconnect.

So your on-prem Webserver is also running as OpenVPN client which is connected to your gcloud pfSense? You are only running this one pfSense? What is your OpenVPN mode? -Rico

@AdmiralBTech said in open VPN and vlans: I was thinking of trying to use OpenVPN in TAP mode rather than TUN mode. I wouldn't count on that. Even in TAP mode, there are some things better left rather than to open pandora's box ;) I'd think more along the lines of tools like Zerotier or anything alike that aim to make a L2 capable VPN connection. But really, if the soft-/hardware you have deals heavily with local broadcast or multicasts and "autodiscovery" and such "automagic" things rather then plain IP, I'd leave it alone even if I understand the idea.

@ontzuevanhussen That's it!

@hieroglyph With an established s2s vpn you could connect remotely to the server side of the vpn and access both sites with one connection, concurrently. But this adds unecessary points of failure. And since these are home networks, you could be better off with two openvn servers listening at each site , and connect to each as needed. A site to site vpn could also co exist, so you don't have to do anything when at home. of course you can have it all. S2s, two openvpn listening at both sites, and access to everywhere no matter where you connect. Happy tweaking.

Hi, while this is 3 years old, i just stumbled across this problem today with another VPN setup using username and password. So long story short, for whatever reason pfsense is removing the last line in the user/password file when openvpn client is executed. This results in the above error message. To fix this issue: 1.) connect via ssh to your pfsense and choose to start shell 2.) find your user+passwordfile in the openvpn directory (/var/etc/openvpn/), for me it is the file: /var/etc/openvpn/client1.up 3.) If you open it with cat for instance it will only show the username and an empty line cat /var/etc/openvpn/client1.up myvpnusername 4.) Simply add in a new line after the username the password and save the file so that the file looks like myvpnusername myvpnpassword 5.) Now the important step, make the file immuteable. If you do not do this, the password will be removed again. Execute: chflags schg /var/etc/openvpn/client1.up 6.) re-check that username and password are correct cat /var/etc/openvpn/client1.up myvpnusername myvpnpassword 8.) Go in the webinterface to Status->OpenVPN and Start the service. 9.) Should run now. Happy VPNing ng23

In any case, its client side, pf can't do anything about it.

@JLundberg said in DNS names not resolving when connected via VPN: Under the firewall rules I have the protocol set to TCP. Should I use UDP/TCP for all my NAT Settings? TCP set for what? You didn't show us the ruleset :) @JLundberg said in DNS names not resolving when connected via VPN: It may be as @Gertjan pointed out. I don't have my local DNS set in the OVPN settings. I will try setting that tomorrow morning and see what I get. Also I'll be better set to get more info when it's connected to the network. If you use any public DNS as your DNS setting in OVPN server settings you won't get any answers for internal IPs or internally used domains. Obviously ;) So if you want them it depends: do you use pfSense for your internal DNS or do normal clients get DHCP/DNS via your Windows DC? If you want your OVPN clients to get the same, you have to hand them your pfSense or Windows DC/DNS IP as their DNS server, otherwise no one knows about your internal domains and can't resolve it :) \jens

@Mainzelman said in OpenVPN not longer starts after update to 2.4.5-p1: Maybe I'm wrong - but I think before the update to 2.4.5-p1 the service had also started on the Backup FW. Shouldn't have been the case. The only case I know where they are started on both nodes is, if you bind them on a local VIP or localhost and forward your OVPN ports with Port Forward entries to that server. That is recommended with e.g. MultiWAN setups to have the ability to connect to the same server via multiple external IPs/WAN uplinks. As the server is bound to "localhost" it is always started/restarted on both nodes and waiting for connections (without getting into each others turf ;) ). So seems to be working as intended ;)