Problem 2 fixed by adding route to 192.168.5.0/24 on Mikrotik side

@m5ip25
Just wanted to say that this seems similar to the issue I'm experiencing after updating to 2.7.0. In my case it's a simple point to point tap bridged to physical interfaces on each end. Tap needed because the whole purpose of the tunnel is to pass multicast video traffic.
https://forum.netgate.com/topic/183115/openvpn-client-process-fails-after-upgrade-to-2-7-0

@adamitj
DoT requests which are redirected to another server won't work anyway, because the SSL verification will fail.

Therefore I simply block all DoT and DoH in my network. Hence the clients have to do unencrypted DNS requests, which I can redirect as needed.

@gertjan yes, it was pfblockerng-devel v3.1.0_6.

I have blocklists set to prevent traffic coming from "non friendly countries", basically, asia region, russia, some northern countries + africa.

But I agree, it is quite weird.
I've now made several tests with pfblocker-ng enabled/disabled, etc.. and always see the BW drop when pfblocker-ng is enabled.

5c64470f-6054-465d-8153-9428ad13ba7a-image.png

@markedo hi , did you have luck resolving this ?

@m229m
Either set up the OpenVPN server on the router (default gateway) or set up a transit network on the router and move the VPN server into it.

Your setup ends up in asymmetric routing issues.

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch.

This will be probably fixed in one of the next releases then.

@mpcjames glad I could help.

@stephenw10
Answer, hopefully in order...

Version is 2.5.2 on the Azure VM and 21.05-RELEASE (amd64) on the 5100s

OVPN is site-to-site, pre-shared key, UDP on IPV4 only, Layer 3. On the remote server there is a point-to-site server (for use as a remote internet gateway). It's for travel use but nobody's travelling so there are no connections.

Latency is 27-32 ms, WAN Azure to WAN local; 100-130 ms to the other sites from WAN local.

I only have one local device so I haven't tried to replicate here. I could spin up a Hyper-V guest but not now, I am currently working on alternative method, most likely a Linux server on the local LAN, running OpenVPN as a server and NAT port forward Linux server. We are up interactively but backups through the tunnels are an issue.

Not an expert regarding state tables so I wouldn't know what to look for. I can try clearing the state tables after the trouble begins to see if that reset avoids a reboot to restore WAN performance. Would that provide useful information?

We're not running IPSEC now. We were, but IPSEC failed after a recent upgrade. We switched to OpenVPN. I have read that the IPSEC issue has been resolved but haven't switched back.

One more observation. We do have a point-to-site server running locally. There is one user, a Synology raid device that phones home and stays connected 24x7. It is used as an off-site backup device accepting snapshot replication and file share backups. It's been running without issues. It seems to be the site-to-site tunnels that are tripping us up, on the client-side.

@viragomann omg facepalm yep, you're totally right. Thanks. I know what I did now. When I initially set up the OpenVPN client I entered the wrong credentials (and didn't realize it) so it didn't appear as an option when I was initially assigning an interface so I arbitrarily selected em2 not knowing it should have said something like ovpnc1.

Went back just now and changed it. Gateway shows as up. And was able to select it in my firewall rule. Beautiful. Thank you very much.

I have the similar issue after upgrading to 21.02.2 version on my Negate SG-5100. Prior to upgrade all OpenVPN connections were working fine. After upgrade only one VPN connection is working, other is connected but no traffic passing. On disabling the VPN on connection 2, data traffic starts but not on VPN.

Not sure if it's a bug generated by pfsense update.

openvpn.txt

Log kept getting flagged as spam, so it is attached.

If anyone else hits this, netgate support found I was using "openvpn" in the outbound NAT rules as the interface. Specifying this to the VPN Client interface resolved the issues.