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.

okay i switched to bgp instead and added the p2 and now it works.. go fig.

@Derelict Hi, yes your reply is correct. Basically no extra configurations are needed. However, there is a caveat: If I enable Force all client-generated IPv4 traffic through the tunnel option and clients rely on DNS service to find the IP of the OpenVPN server, after rebooting my pfsense firewall, all the OpenVPN clients could permanently lose their connections (both VPN and Internet connections). I end up calling colleagues to reboot all clients physically to re-establish the connection.

Be sure that User Authentication Settings on the OpenVPN client configuration page not empty: [image: 1593080671359-screenshot-from-2020-06-25-13-23-52.png] Fill in the username and password fields