redacted

While it may be caused by a bug, it is much more likely that the access to the port is blocked externally or that some other dst-nat rule shadows the newly added one.

So I'd suggest you first run
/tool sniffer quick interface=your-wan-interface-name port=the-port-number
and try to connect to the port; if you see packets arriving, it means they made it to the router, otherwise something has blocked them before they could get there.

If they come, and the dst-nat rule in question counts packets, the packets did reach the rule and either the firewall filter blocks them or they get redirected to a wrong address.

If they come but the dst-nat rule in question doesn't count them, some dst-nat rule before must be matching on those packets.

Can you please share your NAT rules (/ip firewall nat export)? Do you have the default filter rules (while you are at it: /ip firewall filter export)?

ppp

While it may be caused by a bug, it is much more likely that the access to the port is blocked externally or that some other dst-nat rule shadows the newly added one.

So I'd suggest you first run
/tool sniffer quick interface=your-wan-interface-name port=the-port-number
and try to connect to the port; if you see packets arriving, it means they made it to the router, otherwise something has blocked them before they could get there.

If they come, and the dst-nat rule in question counts packets, the packets did reach the rule and either the firewall filter blocks them or they get redirected to a wrong address.

If they come but the dst-nat rule in question doesn't count them, some dst-nat rule before must be matching on those packets.

In WinBox I see that both the effected NAT rules are counting packets

In WinBox I see that both the effected NAT rules are counting packets

In that case, post the export of /ip firewall filter.

ppp

Did you check if your Windows firewall or AV at the PC is getting in the way??

ppp

OK, nothing wrong with filter rules, as initial packets of dst-nated connections are excluded from the "drop all from WAN" rule.

So I'd assume it is a routing or firewall issue at 192.168.88.246 and 192.168.88.249.

/tool sniffer quick port=1194

will show you whether the packet has made it to the LAN interface and whether the server has sent any response.

The fact that you can reach everything internally doesn't necessarily mean that the firewall on the server cannot cause the issue, it may be selective.

ppp

Fine, how does it look like when connecting from outside?

Fine, how does it look like when connecting from outside?

It just never connects... I understand that this issue is vague. I was able to confirm that ufw is not running. I'm not sure what else I can do at this point. Maybe either a RouterOS bug or in need of a full factory reset? I would prefer not to reset the router if possible. Again, I've explored the possibility that its my ISP. Maybe my ISP only allows a set number of ports to be open, no. I've tired to disable a rule and enable another, no luck. I've also tried other port numbers with no luck. The modem itself has no NAT, and no firewall that's effected previous Mikrotik devices in my environment.

"it never connects" and "I cannot see any packets to get anywhere" are two distinct things.

When you were sniffing while connecting via LAN, you could see a packet with dst-port 1194 to come in via ether3, the same packet to leave via ether 4, and then a response packet with src-port 1194 to come in via ether4 and leave via ether3.

When attempting to connect from the internet, the result of the sniff would look the same (except the WAN port ether1 would replace the ether3) if it worked. But as it doesn't work, you need to identify a device which breaks it.

As the dst-nat rules count, the request packets must be arriving through ether1. The question is whether, while sniffing, you can also see them leaving via ether4 towards the OpenVPN server and if yes, whether you can see also responses from the OpenVPN server. This gives you a clue where the issue is, whether on the Mikrotik (if you can see the request packets at the WAN port but not at ether4) or on the server (if the requests leave through ether4 but no responses come back).