@viragomann
Thnx again, my N5105 is on the way. ill see what would it can do:)
regards

Thanks all, update went well, VPN and other configurations appear to have been preserved.

Later I will try an install from the file to see if I can get zfs up. I would really like to have the ability to use different boot environments, but that is a separate story for later.

Again, thanks all.

@jimp
yep. I missed it. Thanks.

@frodet You have to fix your client configuration if you switch your server to use DCO.

DCO automatically comes with a few drawbacks from the OpenVPN team (that are stated in the blog post Netgate published to DCO and the docu). E.g. AES-GCM is the only supported cipher (besides CHACHA20), compression is not available and mtu/mssfix/fragmentation settings aren't available.

As your client sends AES-CBC that won't work, the other lines are most likely follow ups of the wrong cipher setting.

Cheers

I changed "data-ciphers" following this information: link

Reasonable?

@rcoleman-netgate Thank you!

FYI- There are a couple different ways that they can show up UNDEF:

If something probes the server port without actually speaking the OpenVPN protocol or otherwise doesn't complete authentication If you use User Auth only (no SSL/TLS) and do not have "Username as common name" enabled

The latter is normal/expected and OK. You probably want to enable that option in that case anyhow, it really only has benefit when using SSL/TLS+User Auth and each auth user can have multiple different certificates.

The former is a bit trickier since you kind of have to have OpenVPN open to the world to accept remote access VPN connections, but the good news is as long as you have a TLS key on the tunnel (Either TLS auth or TLS encryption+auth) it's a non-issue. It won't matter if anything probes the VPN port because without the TLS key the packets will be rejected without even performing a full TLS exchange.

Everyone should have a TLS key on their OpenVPN servers anyhow not only for the authentication protection, but also because it is an extra authentication factor ("something you have", similar to a cert) and it has also been proven effective at protecting the server against OpenSSL exploits like Heartbleed in the past.

@viragomann

Thanks for answering. Yes, it is a Remote Access configuration, not S2S. I forgot to include that I am also utilizing RADIUS-controlled ACLs, so the user connecting is getting a specific ACL configuration. It seems that when the RADIUS server returns ACLs, no other rules are evaluated which are locally configured on the firewall. And indeed, no rule was matched while I tested. As soon as I removed the ACL coming from the RADIUS server, they started to match, and packets started to get out the correct WAN interface. I tested this with an assigned interface for the instance, but I suppose it will work without it too.

Now the question is: will it be possible to achieve this while preserving the ACLs from the RADIUS server or these are mutually exclusive? I don't think the RADIUS server can pass a rule for policy routing, so it's just a packet filter. If it is not possible, maybe just get rid of the RADIUS ACLs, create another instance of OpenVPN, assign it to an interface and do the filtering there? The idea is to have different ACLs for different user groups.

@jknott thanks for your help

@sandsjh
I'm not familiar with Tailscale. But I don't think, that it's the same reason. As you wrote, your machines are able to access the internet, but they go out with your WAN IP instead of the VPN endpoint. So it's obviously a routing issue.

The OpenVPN server in this topic pushes the default route to you. You can check that out in pfSense routing table. If the route is not pushed by the server you can state it in the client settings anyway to direct all traffic to the VPN server.
There might be a similar option in Tailscale.

Is see you stated "--accept-routes", but possibly the server doesn't send ones.
Look for an option to actively set routes on the client.
If that is done you maybe also need an outbound NAT, if that isn't done automatically in Tailscale.

Yes, 1.6_6 also fixed the problem for me as well.

@technolust
So you're forcing the whole clients upstream traffic over the VPN (redirect gateway checked)?

If so your outbound NAT should be configured properly and also access to the provided DNS servers should work.

The reason for the issue when having "Block Outside DNS" checked might be on the client side.
There are already threads regarding that as far as I remember. Maybe you can do some search.

@gertjan said in NordVPN makes internet speeds very slow on PfSense.:

hardware encryption

Thank you for your reply! I believe N*rdVPN doesn't allow to choose from a list of cyphers. AES-256-GCM is the encryption algorithm I use. Hardware Crypto is availible:
7590057b-a6da-40b4-919f-203b79dfee1d-image.png
For now, I'm changing my desktop's local IP to disable the VPN if I need high speed like you said. 180-200 Mbps is still enough for browsing the internet and even gaming, video streaming, but it sucks that 80% of my internet speed goes to VPN. I originally chose NordVPN because they were recommended in many forums and they had a nice deal VPN + Password Manager and Data Leak Scanner, but now I think about switching to PIA.

@latency0ms
Best practice is to create an alias and add all private network ranges to it, call it e.g. RFC1918.

Then add a block rule to the top of the OpenVPN tab:
source: OVPN2 tunnel network
destination: RFC1918 alias

For upstream from OVPN2 you also need an outbound NAT rule on WAN if you didn't add it already.