Critics after using NymVPN for one day

NymVPN Discussions
1

First off, from a technical perspective, this system is absolutely fantastic—very close to my dream. Keep working; it’s great!
But from the user experience perspective… :face_exhaling:
At least on Linux, the experience is rough even after considerable tinkering. Why isn’t autostart working? Why am I not autoconnecting? Why isn’t the killswitch blocking any connection when the nym-vpnd is running? And why does it leak my IP upon bootup? Why can’t I connect via CLI without opening nym-vpn-app
command? Also, why doesn’t my own killswitch working? (nft add rule qubes custom-forward oifname eth0 counter drop
nft add rule ip6 qubes custom-forward oifname eth0 counter drop
nft add rule ip qubes custom-forward tcp flags syn / syn,rst tcp option maxseg size set rt mtu)
Furthermore, shouldn’t the main app be usable without requiring root authentication? Why can’t I authenticate on Qubes (can me my fault)? And I also ran into issues with dnat-dns, honestly, at this point, those are minor complaints.

It’s not limited to Qubes alone, another Linux setup was more comfy, but overall, it’s still very uncomfortable in practice. And I know the underlying technology is genuinely amazing! On mobile, it works flawlessly! The network architecture itself is phenomenal!

Just… please make it much more comfortable and secure for use on Linux
and Qubes installations. Or feel free to tell me that I am using your software incorrectly.

For context, most of my troubleshooting was based on: Nym VPN Mixnet Guide (GUI) - Community Guides - Qubes OS Forum

1 Like
2

Thanks for taking the time to write such detailed feedback, and especially for sticking with the setup through all the Linux and Qubes troubleshooting.

It is great to hear that, from a technical perspective, NymVPN feels close to your ideal setup. At the same time, your criticism of the Linux experience is completely fair. I shared your points with the developers and wanted to respond to each of them directly.

Autostart and auto-connect

Auto-connect is not implemented yet, which is why NymVPN is not reconnecting automatically after startup.

Killswitch and traffic during boot

The current killswitch does not yet provide a full lockdown mode.

This means it does not block all traffic whenever nym-vpnd is running, and there is currently no early-boot lockdown. This explains why your normal IP may be exposed before the VPN connection has been established.

Both general lockdown mode and early-boot protection have been requested before and are known gaps in the current Linux experience.

Connecting from the CLI

You should be able to connect without opening the graphical app by running:

nym-vpnc connect

nym-vpnc is available through the Debian package. Authentication is handled through a polkit password prompt.

Custom nftables rules

nym-vpnd automatically manages nftables rules when it connects.

Because of this, it is possible that your custom killswitch rules conflict with the rules installed by the VPN service. We would need to look more closely at your exact Qubes and nftables setup to confirm what is happening.

Root authentication

The authentication prompt is required so that nym-vpnd can verify that another process, including potentially malicious software, is not manipulating the VPN connection.

This is currently enforced through polkit, and we do not support another authentication method at the moment.

Qubes authentication and DNS issues

The Qubes authentication and dnat-dns issues may need more focused investigation.

Any additional logs, error messages, package versions, or details about your Qubes setup would be very helpful in understanding whether this is a configuration issue, a compatibility problem, or something we need to fix.

A few follow-up questions

You mentioned that, from a technical perspective, NymVPN is very close to your dream setup. We would really appreciate learning more about that side of your experience as well.

  • Which parts of the technology or network architecture are most valuable to you?
  • Why does Nym matter to you compared with a conventional VPN?
  • How often do you use NymVPN, and across how many devices?
  • If you could change one thing, what would it be?
  • What would that change allow you to do that you cannot do today?
  • Beyond the Linux and Qubes issues you described, is anything else missing that would make NymVPN fully match your ideal setup?

Thanks again for the thoughtful and detailed feedback. It’s very useful, and it helps us understand where the Linux experience needs the most attention.

1 Like
3

Hello Salazar,

Hope all is well with you,

I wanted to add my two sense to the the original posters post about criticism of nym as well and get some feedback as well from you.

First off,

Nym is great and I’m am pretty happy with the team/product so far and that they’re so quick recently about making the product as good as possible for us in the community, the message Nym is standing for is admirable, to bring true anonymity tech to everyday folks, so on that front I would like to thank and congratulate you, keep fighting the good fight.

For Qubes os, the experience isn’t the best but I’ve found that the issue seems to be with Qubes default virtual dns and how Qubes overall handles DNS, this isn’t just a Nym problem but many other VPN providers have issue with functionality on qubes as well, it seems to have a issue with forwarding DNS request from other qubes to port 53

I’ve gotten it to work many times and be able to provide network to many Qubes through two method.

  1. Going into the specific app vm I want nym to provide network to and forcing DNS to 1.1.1.1

  2. Or configuring the nft tables in the specific nym vm and forcing all DNS to a 1.1.1.1 or your choice of DNS server

I’ve written a script to do this and also other research I’ve done to make it work so far on qubes specifically use Nym as a sys-net vpn proxy for other qubes, I might send it to you, maybe it can help with qubes support

I don’t have much to criticize Nym on other than the same stuff you probably hear from everyone, the lockdown mode is a must and without it, it hurts security, so hopefully we see it soon

I wanted ask as well in the March blog for the roadmap update, I see mentioned that Nym has developed a new traffic cover scheme that is different than the one currently being used for the mixnet, this scheme is said to be for browsing/everyday use cases and will be able to be used for DVPN fast mode

I haven’t heard much by the team in the community calls talk about this, could you shed some light on this new scheme, will this be implemented soon? Will we see it in beta testing soon? Will this bring great traffic analysis protection to the fast mode? What will it do differently than the current scheme?

4

Hello anon_punk,

I’ve written a script to do this and also other research I’ve done to make it work so far on qubes specifically use Nym as a sys-net vpn proxy for other qubes, I might send it to you, maybe it can help with qubes support

I saw your comment and would be really happy to test your script.

Thank you.