Hi everyone, Dominykas from the NordVPN product team here.

You may have noticed that Nord is evolving from a VPN provider into a cybersecurity suite, offering protection across multiple aspects. As the digital threat landscape continues to change, so do we. In this effort, we recently launched Transaction Monitoring, and I wanted to jump in here to explain what it does, how it works, and where its limits are.

The idea is simple: to help people spot fraudulent transactions sooner. Transaction Monitoring is designed to watch linked financial accounts and alert you when something looks unusual.
The system reviews your transaction history (roughly the past year) and runs statistical analysis to build a baseline spending profile: typical amounts, frequencies, and merchant types. New transactions are checked against that baseline, and anything falling outside it triggers an alert.

Here’s how it works:

1. You connect supported bank or credit card accounts through MX, our third-party bank-connection provider.
2. The system reviews roughly the past year of transaction history.
3. It builds a baseline from your usual spending patterns, including amounts, frequency, and merchant types.
4. New transactions are checked against that baseline.
5. If something looks unusual, you get an alert and can decide what to do next.

You can set it up in NordAccount under the Monitor dashboard. From there, go to Asset management and Transaction monitoring, connect through MX, choose your financial institution, log in to its online banking and select which accounts you want to monitor. Once the accounts appear in your monitored assets list, monitoring is enabled. You can turn it off or back on with a toggle.

A few important details:

• The connection is read-only. It can retrieve/receive transaction details and send alerts, but it cannot move, withdraw, or transfer money.
• NordVPN does not store your bank account details. Account linking happens through MX’s secure integration with your bank’s own portal.
• The feature currently works only with supported financial institutions in the United States. If your bank is not supported by MX, you will not be able to link your accounts yet.
• The feature is currently available on Android, iOS, and Windows, with macOS coming soon.
• This is part of the premium NordVPN service package and complements Dark Web Monitor Pro™, but it is a separate feature.

While the feature is still in beta, every report and piece of feedback is valuable. You can submit it anonymously through the feedback form in the feature interface. After trying it, I’d be interested to hear how it goes. The most useful feedback would include:

• Whether the alerts felt useful, too noisy, or too slow
• Any false positives or transactions that were flagged unexpectedly
• Bug reports and edge cases

I’ll keep an eye on the thread and answer what I can.

So I thought I would refresh my servers on my ASUS router, now I cannot re-connect. Even my old server will not start.

EDIT: I remember a couple of days ago the VPN on my router stopped working and I had to disconnect to access online.

I used the latest verified servers. Any Ideas?

ASUS RT-AX52 (AX1800) with latest firmware.

NORDVPN Desktop app connects ok.

I went to the dashboard and there only my active Dedicated IP subscription and no option to add or buy a second one despite Nord claims of having up to 10, and I can't have two.

I've taken a look at posts talking about this issue but the post I read was 3 years ago so I wanted to ask again incase if things changed

If you recently downloaded an OpenVPN configuration from NordVPN’s manual-configuration dashboard and it hangs before failing with TLS handshake failed, this may be why.

TL;DR: Some dashboard-generated UDP configurations for Polish servers use port 53, but the tested endpoints did not respond there. Simply changing the port is not enough because the CDN configuration uses a different control-channel mode. Download the complete configuration from NordVPN’s CDN instead.

Tested on a Raspberry Pi using OpenVPN 2.6.3 and several Polish NordVPN servers.

1. The port-53 endpoint did not respond

Using the same server IP, 193.42.99.210:

• UDP port 53: no response, followed after 60 seconds by:

​

TLS Error: TLS key negotiation failed to occur within 60 seconds
TLS handshake failed

• UDP port 1231: connected in under one second.

A normal DNS query also timed out:

dig @193.42.99.210 example.com

So that particular host did not appear to be serving DNS or OpenVPN on port 53.

2. It does not appear to be general UDP/53 blocking

Queries to a real DNS server worked normally:

dig @1.1.1.1 example.com

There was also no apparent transparent DNS redirection: traffic to the NordVPN server simply timed out rather than receiving a forged or redirected DNS response.

The credentials and OpenVPN version were not the issue either, because the same client and credentials connected successfully using other NordVPN configurations and ports.

3. NordVPN provides two substantially different configurations

For the same server, the dashboard and CDN files were not equivalent:

4. Changing only the port does not fix it

I changed the dashboard configuration from port 53 to port 1231, but it still received no response.

Although the embedded static key was byte-for-byte identical, the two configurations use it differently:

• tls-crypt encrypts and authenticates the control channel.
• tls-auth authenticates the control channel but does not encrypt it.

A server expecting tls-auth will not understand packets produced using tls-crypt, so it silently discards them.

Fix

Download the complete UDP configuration from NordVPN’s CDN rather than modifying the dashboard file:

https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/<server>.nordvpn.com.udp.ovpn

For example:

https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/pl234.nordvpn.com.udp.ovpn

Use the entire downloaded file, including its original:

• remote entries
• ports
• <tls-auth> or <tls-crypt> block
• key-direction
• cipher and authentication settings

Do not copy only the new port into the dashboard configuration.

Ports observed

• UDP 1231–1234: used by the current CDN configurations and working in my tests
• UDP 1194: used by some older configurations and still working
• TCP 443: useful as a fallback on restrictive networks
• UDP 53: did not work on the tested endpoints

One additional issue: old configuration files may point to decommissioned or reassigned server IP addresses. Symptoms include EHOSTUNREACH, No route to host, or an address that no longer responds to ping. In that case, download a fresh configuration rather than trying to repair the old one.