@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 ;)

@viragomann Ok, done. Now everything works normally. [image: 1593705588494-screen-shot-2020-07-02-at-22.59.32.png] Because of the rules in the VPN tab: [image: 1593705824280-screen-shot-2020-07-02-at-23.03.19.png] Why did you give up? why you so easy to give up???

Thank you Gerjan. I added float to the client config and the errors went away. I actually didn't expect the fix to be that easy.

Still running it on my homelab without a problem but yeah in a busy setting that can hurt ;)

perfect Rico, thank you very much, I learned a lot

Thank you all guys for you kind help. it's really appreciated

Hi Jim, thank you for your time. I've supposed that the problem is the php library. I'll move to build and use a new CA. Thanks, Dario.

@Derelict Only from pfsense. Not from any clients. The routes show up in the pfsense route table with the gateway as the tunnel link address. Could it be an issue that the default destination is at the top of the entire list? Another interesting thing is that a trace route command to the other side of the tunnel gets only as far as the local gateway on the side you are trace routing from.

So finally installed the OpenVPN Access Server and it works, meaning, I did everything right on the client side, but still everything could be messed up on the server side, if I roll my own on a ubuntu machine. Again, if anyone got a good and working tutorial for that, would be appropriated.

don't worry - i've sorted it.

@fertig said in Disabled static route deletes OpenVPN's routes: @Derelict said in Disabled static route deletes OpenVPN's routes: Workaround: delete them. Don't set them to disabled. You should not be using static routes for OpenVPN routes anyway. Let OpenVPN maintain them using Remote Networks. if you're using a separate OpenVPN-gateway, you'll have to use static routes to this gateway That is a static route to a gateway, not into OpenVPN. Two entirely different things. if you're migrating away from such a gateway, while you're testing the OpenVPN on the pfSense, you'll allways disable the routes temporarly, to get back quickly. This is the normal way of doing in my opinion... Especially because you don't get the VPN working - as the routes are allways deleted. This is a complete unexpected behaviour. Anyway, I filled a bug report Good deal. That's the way to get developer eyes on it.

@dmd1234498 No, that's not noteworthy if the VPN server isn't at the other side of the globe. There are only some more hops to the webserver.