# NIP-14: Nym Exit Policy Update – Opening Additional Ports for Applications and Community Services

oceanus · August 10, 2026, 9:43am

Pasting here verbatim the message I posted in the Node Operators Matrix channel, per @serinko 's proposal.

Toward clearer governance for exit-policy changes

I’d like to start a discussion about how changes to the exit policy should be governed. The below is mostly a summary of what has been discussed in the Matrix operator channel and in the forum, along with a few new ideas.

This is not an attempt to reopen NIP-14. However, it showed that the process for exit-policy changes has never been clearly defined.

Exit-policy NIPs are submitted as standards, but in practice they are also put to an operator vote. We do not appear to have agreed rules covering:

what information must be disclosed before a vote;
when services or port groups should be voted on separately;
how exit operators should be represented;
how an approved proposal is linked to the deployed policy;
how ports can later be reviewed, suspended or removed.

I think this could be addressed through a process NIP.

Why this matters

The scope of these proposals has grown.

NIP-3 covered a few named ports and allowed separate voting choices. NIP-14 included broad ranges and many additional ports, but operators could only vote yes or no on the full package.

A bundled vote does not show which parts operators actually support. It also means that describing a large range by the name of one service may not fully describe what the policy permits.

Future proposals should therefore include:

the requested ports and ranges;
a before-and-after diff showing the effective net-new permissions;
the requester or sponsoring organisation;
the original request channel and intended use case;
a risk section covering other common uses, known abuse patterns and possible hosting-provider concerns.

Independent services or ranges should be separate ballot items where practical.

Exit-operator participation

All bonded operators currently vote, but the direct legal and operational consequences fall mainly on exit gateway operators.

One possible model would require both:

approval through the normal operator vote; and
approval by participating eligible exit operators.

The second vote should probably be stake-neutral, although we would need to decide whether it is counted per gateway, per family or another model.

The aim should be a review mechanism, not a permanent veto. A rejected proposal should be able to return after the concerns have been addressed.

Auditability and review

Each deployed change should have a public record containing:

the NIP #;
the vote result;
the exact policy diff;
the implementation date;
any later rollback or modification.

We should also define procedures for:

normal removal of an obsolete or harmful permission;
temporary/emergency suspension following credible abuse or security evidence;
rollback where the deployed policy does not match what was approved.

Large ranges could receive a mandatory review after a defined period, based on usage, abuse reports, provider notices and operator feedback.

A related technical question

We should also examine whether every port needs to apply equally to fast mode and anonymous mode.

Many recent requests involve latency-sensitive applications for which the demand may mainly come from fast mode. Mode-specific policy entries could potentially reduce unnecessary exposure, although this may be better handled through a separate technical NIP.

Questions

I’d particularly value feedback on:

Should exit-policy NIPs require a separate exit-operator threshold?
Should that be counted per gateway, per family or through a capped model?
What types of changes should trigger a more demanding process?
Should broad ranges require periodic review?
Should mode-specific policies be explored separately?

If there is support, the outcome of this discussion could be turned into a process NIP.

The objective is not to block useful policy changes. It is to make the process proportionate to their scope, clearly document what is being approved and give the operators carrying the direct consequences a meaningful role.

wunderbaer · August 10, 2026, 10:29am

Hey @userm5 ,

thanks for your reply and sorry if I misunderstood you. But from my point of view all node operators should be considered as small businesses with all the pros and cons. Everything else contradicts the idea of a decentralized operation of NYM infrastructure. I mean, if NYM runs all the exit nodes the only step it would need for a government actor to bring down the whole network would be shutting down NYM Technologies which is a registered business under swiss law. This simply defies the whole purpose of a decentralized economy. Plus all exit nodes would basically be operated under one, the swiss, jurisdication. Summarized: I don’t see a way to centralize the exit nodes and still have a decentralized network tbh. Please explain to me how you would see this working?

Imagine Uber being responsible for every accident one of their drivers has. Do you know what I mean?

As a node operator you are self-employed so to say. So your legal risk assessment is up to you, not to NYM. That’s also why I am talking about a sustainable business model. The more risky operations need to be compensated better (exit nodes are already compensated better than mixnodes tbh but there i still a huge gap). The incentives need to be high enough so a sufficient amount of operators are willing to take the risk - or better said: The additional work this brings.

So for me this does indeed boil down to a business question rather than a technical question.

Best Wunderbaer

userm5 · August 12, 2026, 3:15am

Hello @wunderbaer

Thank you for your response. I would like the Nym team to seriously consider this issue, and I hope this discussion contributes to that.

To clarify, my concern is not which ports should be open or closed. Adjusting the port policy does not solve the underlying problem.

The core of my argument is that the network has no way to distinguish between “idealistic operators who knowingly accept legal risks” and “adversarial actors who simply do not care about those risks.” A structure that places legal responsibility on individual operators will, over time, tend to drive out the former while leaving the latter. The allocation of responsibility itself becomes a mechanism for selecting which operators remain.

One way to avoid this is for Nym itself to take responsibility for operating the Exits. With the mixnet architecture, I believe practical privacy can still be adequately preserved. ProtonVPN, for example, is operated by a single company, yet no one says it provides no anonymity. NymVPN’s mixnet has the potential to provide even stronger privacy.

Simply increasing node rewards does not solve this. A risk that cannot be transferred cannot be priced, and the operator still bears it personally.

Looking into it, Uber covers driver insurance at the platform level. This is exactly what I am asking Nym for — the platform bearing the risk, not the individual.

How this network should be designed is Nym’s decision. There are already projects addressing parts of it, such as MysteriumVPN’s use of residential IPs and Torservers’ separation of legal risk from individual operators. But no one has found a complete answer yet.

I hope Nym can be the project that provides that answer.

Best,

Numbless · August 12, 2026, 10:59am

First of all, @wunderbaer, thank you very much for sharing your perspective, and thanks to everyone else who contributed to the conversation. It was important for me as a person who requested a bunch of the ports in NIP-14. I was hoping to spark a genuine conversation and get a deeper understanding of the issue from all sides, and I’m glad that it happened and, in the process, uncovered more issues that are no less important.

I am not a node operator, though I have the proficiency required to host one. I may host a node in the future, but that is not the near future by any means.

That means that I mainly represent my interests as a user; I want to make it clear, if it wasn’t already. That also means that my opinion is not nearly as representative as the opinion of anyone who actually hosts an exit node.

That being said, I want to share my perspective on some of the issues.

First, ports. As a person who used to use other VPNs and not have to care about ports, the mere fact that they are restricted was surprising. I now understand that the issue is mostly abuse through mass port scanning, and this is a way to deal with the problem. As I stated previously, we should balance quality and quantity when it comes to ports. I am comfortable sacrificing some convenience for the sake of exit IPs having less chance of being flagged for abuse. My stance here is that if a service requires opening a lot of ports, it should be additionally reviewed and decided upon. Also, some services, like gaming, have less priority than others. On the other hand, if a service requires opening one or several ports, I think it’s usually OK to open them because this provides a lot of utility for a price that’s almost negligible.

That is what brought my attention in NIP-14: three thousand ports for proxy services is something I’d imagine we can live without, but ultimately this should be discussed additionally. In my opinion, opening multiple commonly used ports for proxies is right, but thousands is too much. There has to be a balance.

Two things that stand out, though, are BitTorrent and WebRTC/VoIP. These are very important technologies that have complicated port usage policies. I don’t really know how well they are supported by Nym, though (my guess is not very well, because many servers don’t work or work poorly with BitTorrent and WebRTC services are hit or miss), and all their technical intricacies, but implementing proper support for them is crucial and deserves further discussion.

Ultimately, it is good that operators can dispute port proposals in the corresponding NIP’s forum thread (and bad that there was no discussion initially). We can improve that by hosting a discussion before opening a NIP and ruling out some discrepancies beforehand and assigning the most controversial ports their own NIPs. Also, starting discussions around ports that are already open but are not liked by exit node operators and creating NIPs to exclude them if needed.

Regarding voting, I don’t have much to say other than that only letting exit node operators vote on matters that impact only them seems reasonable.

Regarding risks, I think that we shouldn’t resort to extremes, and we also need to acknowledge that this problem is impossible to solve entirely, and we cannot change the situation drastically without introducing other problems and compromising too much. But some improvements can be made, of course. The ones I stand behind are higher payouts for exit node ops than others, conducting research on different countries and legislations, making accessible guides and resources about the risks involved with hosting exit nodes and how to manage them, and the Nym team providing legal and technical assistance when needed.

However, this is still a difficult problem and requires a lot more further consideration.

serinko · August 13, 2026, 10:37am

I would like to share my thoughts on some of the points above. Please note that I am wroting form a position of Nym network technical lead and one of the authors of all NIPs so far (if I remember correctly). I am therefore having an interest for these NIPs to pass, there is nothing hidden behind that, the fact that I publich these proposals is the most transparent act of intention.

At the same time I am a big proponent of decentralised governance and it is my duty and part of my work description to meet a balance in between requirement of NymVPN users and health of Nym network from both technical and social sides.

Before I get to this, I don’t take none of these as any attack nor an offense. Divergence of opinions is a key parameter of a healthy community while there is a common direction and mutual respect, so no worry about that.

My response to the points shared in this message:

1. The Misleading Nature of NIP

We can decide upon a time needed for discussion between proposal submission and beginning of the vote. Anything else is not up to none of us to judge as statements like this: ‘operators cannot fully understand all the implications involved’ is a speculation and it shouldn’t be a basis to any decision on their behalf as it’s creating a class of the ones who understand vs the ones who don’t understand the issue, give advantage to those who self-claimed to be the ones who understand.

2. The Misleading Nature of Port Descriptions

This is a real issue but it has nothing to do with NIP-14, but it puts in question the entire logic behind the management of exit policy of Nym network. This point is in my opinion the most crucial one as it may lead to a bigger rewamp of the design, instead of patching or undoing part of last NIP.

Such discussion needs pros and cons of various solutions and involve more than people in this room, both from side of operators as well as Nym team.

3. Current Port-Opening Policy Lacks Security Logic

It’s more complicated than that. Nym network is not meant to be a niche architecture used by a few dozens of enlightened super users, rather a proposal to change what we understand when we say internet. Just like any young project, we started small and used an existing model of Tor to begin with. But our user base and our aim is not same as the one of Tor.

It’s not a lack of imagination or knowledge making us to go from small to more opened service, rather the fact that it’s unknown what type of personas will be using the product and what their needs will be, combined with limited resources, a budget not allowing us to have an exact market research to know who will use NymVPN upfront. Therefore we have a governance allowing us to be flexible and adjust the policy on the go.

Security and privacy are both fields important for us and while distinct, there is a corssover of these. As stated above privacy is also a part of security: “having to disable VPN for other services to work may be far more dangerous for some people than having these ports open”.

This opens almost a philosophical question: Why should users have different restrictions when using VPN and when not using VPN to begin with?

4. Asymmetrical Operator Attitudes

We can think of ways to exclude mixnodes from the Exit policy voting, though as stated, Mixnodes are minority now. Secondly they all can become Gateways in the next hour as well as eligible Gateways can become Mixnodes.

The rest of the point talking about “not a rational outcome” is not clear to me, what is meant by that.

5. Official Expectations in Voting

See my intro of this post.

6. The Core Contradiction

I agree that we need to set a clear requirement minimum to initiate a NIP to open more services, in whichever design the exit policy may be managed.

All these questions surfacing here are also discussed at Nym internally in parallel and my work is to be a connective tissue of these two sides of one organism.

Next Steps

Create NIP with input from operators and Nym team summarizing the points above:

Minimum thrashold
Discussion time between publishing and vote
Allow mixnodes or not to vote on exit policy

If wished - create NIP reverting some of the prior decisions about exit services
Think of a new design for exit policy management

I am going to continue reading and answer more in the follow up messages

serinko · August 13, 2026, 11:25am

A few more notes

I join on the opinion of all services not being equal. At the same time, it’s my personal opnion, meanwhile we try to deliver a product meeting peoples needs and that’s much bigger than my opinion. Web3 “movement” had ambitious and valuable goals, but haven’t really deliver them. Nym is (also) coming from that tradition and attempts to meet people where they are at. The VPN users are a key metric for the use-case check box.

Mixnet and dVPN have identical exit policies as those are same nodes working in different modes. Please keep in mind that the governance is here because all nodes are expected to run the same exit policy, not customize it per node. For that we built a checker as a part of Gateway probe and now discussing how to plug it into the reward calculation. At the same time any developer coding a service behind Nym can run their Exit gateway plugged to that service with any type of exit policy they need.

Sometimes when operators are unhappy with something, they tend to objectify their opinion, like if it was a general stance. I want to listen to all operators but please keep in mind that sentences like “ordinary operators are increasingly likely to avoid running Exit nodes in order to avoid legal risk” are not based on facts as the numbers show exact opposite.

There will always be a selection towards operators who are able to bear the legal risk, the question is where do we want this line to be. Currently Nym network load is 10-20%, that means that even with slowly increasing user-base and low token price we have more than 5x more operators than required, willing to be part of the network. While there are concerns and indeed reasonable ones to be addressed, I would say that the bar is still set in a fairly healthy level from factual point of view.

I agree with this as there are many vectors of issues and it comes along operating Exit gateway:

Some traffic cannot be identified by port at all (BitTorrent is one example), while some traffic cannot be distinguished as legal or illegal based on the port alone (copyright infringement over HTTPS, for example). No matter how we adjust the granularity of the Exit policy, we cannot control whether an abuse notice is generated in the first place.

About this:

Option 1 — Nym operates the Exits
Option 2 — Nym provides legal support for Exit operators

I brought it to the team and will share the outcome. Though I don’t see realistic that Nym will run all exits nor that it will have special department to answer all abuse reports. In my opinion the rewards need to be adjusted and then operators need to decide whether this work is worth it or not.

Like that we keep decentralisation intact and make operators more supported along the way.

About this:

A best practices documentation that exit node operators can follow. Like local laws for several countries, recommendations on useful insurances, creation of legal entities to mitigate personal liabilities, etc. This could be a community driven but NYM supported initiative, maybe.

It exists already. We have this page in our official documentation: Community Counsel | Nym Docs
There is a manual for adding content as well as Nym Squad League grant program to support community contribution.

serinko · August 13, 2026, 11:26am

Thank you all for your contributions. Really good thoughts gathered here so far.

I am now at the beginning of Oceanus proposal. Will read further and answer more.

serinko · August 13, 2026, 1:44pm

This reply is an answer to Toward clearer governance for exit-policy changes

I highly appreciate @oceanus methodical approach and the though put into the write up. Here are some thoughts, concerns or questions. The unaddressed things are directly in line of my agreement.

I will quote some parts and directly respond to them.

Why this matters

…

Future proposals should therefore include:

the requested ports and ranges;

a before-and-after diff showing the effective net-new permissions;

the requester or sponsoring organisation;

the original request channel and intended use case;

a risk section covering other common uses, known abuse patterns and possible hosting-provider concerns.

The requester or sponsoring org as well as the original request channel is hard to imagine this formally. The reason is that as a Nym team we communicate with various partnering projects via separated channels, in person during conferences etc. You have quite an extended experience in the industry and therefore you know how it works, a lot of proposals and ideas are created organically. The service and intent should be clear, I agree, but the requester and request channel cannot be disclosed every time by far.

…

a risk section covering other common uses, known abuse patterns and possible hosting-provider concerns.

How to consider standard of such information to be considered satisfying. To what extend we want this to be happening and how to define it?

…
Independent services or ranges should be separate ballot items where practical.

How do you see it in practice?

As a NIP-XX-1, NIP-XX-2 as a part of the same proposal with separated ballots
or
As entirely separated NIPs, ie NIP-XX and NIP-XY with separated ballots

All bonded operators currently vote, but the direct legal and operational consequences fall mainly on exit gateway operators.

One possible model would require both:
approval through the normal operator vote; and
approval by participating eligible exit operators.
The second vote should probably be stake-neutral, although we would need to decide whether it is counted per gateway, per family or another model.

The aim should be a review mechanism, not a permanent veto. A rejected proposal should be able to return after the concerns have been addressed.

There is often an issue with perfection vs practice. To get a two degree governance where in the first round everyone voters and secondly only GWx operators can become quite a management issue from Nym as well as too much attention requirement from the operators. Secondly what parameters do we use to define GWx operators? I can change my node mode any time. This point is proposed alongside of having much

About stake, remember that stake at Nym is mostly a reputation and the current stake-weighted system is therefore including the power of delegators.

Auditability and review

The points your proposal requires, do you imagine it as a comment inside the files, as a standalone github file with the hash commit? The latter was one of the ideas which kind of due to the cadence of NIPs and other deadlines vaporized and IMO if we slow down on it to allow for more quality and depth, it should be returned.

I am hesitant to think that rolling back after abuse reports is a good thing. As:

They will happen anyways as they are unpredictable and even https usage (standard port) can trigger that
There is an existing cultural diversity of Nym operators. these surfaced ie. during the discussions about services like Bittorrent. These diverging stances also define what approach people take when running a node (levels of KYC, payment methods, sticking to node ID vs ready to thrash and spin a new one etc). We may arrive to the point where the final vote difference of NIPs may be even slimmer than NIP-14 and still they will be valid.

A related technical question

We should also examine whether every port needs to apply equally to fast mode and anonymous mode.

There is a problem in this. One is the management complexity of such design, another is the fact that NTM is used by both hops as it builds nymtun and nymwg and only socks connections using network-requester are pulling the upstream url exit policy.

About your Questions I think I answered all of them above. Keep in mind the resources (stuff and time) as well into the cost of any NIP changes. This for example can be quite a decisive point when it comes to periodic range review, two degree votes etc.

My greetings.

moejoe · August 13, 2026, 1:54pm

Hello guys,

I’m really appreciate these discussion and that the people which are count are coming into place.

So, back to the Topic:

First one:

i think an real decentralization is only possible with an closed peer2peer network like an messenger as briar, so from the concept i think its not really possible to achieve it completely but we should get close as possible.
these are only my thoughts so some parts are may no perfectly well thought-out but it should be encourage to think about the whole topic.

So now, to the statements:

I think everyone from urs has an point and i ll try this to point out some ideas (slightly) based on your opinions , may some things are already said:

Short Term Approach:

Goal:
Protect the exit Nodes with some measure which can be implemented today:

Introduce an fair Risk-Reward Ratio for the nodes esp. exit nodes should get a much more better one.
Possibility to revoke an NIP if its necessary or useful
Increase the Percent for an NIP Apply at least on 50 %
create an NIP Advisory Board with more experienced Node OPS which has either an veto right or much more voting power.
Forbid mass range port opening.
Create guides to help exit nodes by their legal concerns ( like some tor communities doing)
Exclude the most not important apps like gaming with an much better split feature in the nym app.

Long Term Approach:

Goal: Protect the Exit Nodes as good as possible also with technical improvements.

1. Approach: Obfuscate the Exit nodes and outsource legals to an other entity.

Cause, its not possible to hide the exit node completely may its an idea to obfuscate them like mixing on some relays and then gives an advisor or an legal topic only the possibility to reach these public egress.

These one should outsource as an independent board from an community running or an independent subsidiary from nym.

Even if the egress would like to trace some back, it should impossible by design through crypto or waterproof legal measures, but crypto should be preferred.

Then its possible to process things like legal complaints on an level with like an AI for simple ones and triage some other which are more complicated.

I made some outline on an PDF which describes the most from this approach in a nutshell:

Additional Pros and Cons:

Pros/Cons

Pros

Much easier to implement with the existing Nym architecture.
Keeps stable, professional infrastructure for a critical network role.
High reliability and uptime.
Predictable CPU, bandwidth and latency.
Easier node selection and routing.
Easier to maintain and upgrade.
NAT/CGNAT is usually not a major problem for datacenter nodes.
Easier Sybil resistance because the exit population is relatively controlled.
Easier to apply ASN/operator diversity requirements.
Can strongly protect the actual exit IP by using:
Protected Exit → Blind Relay(s) → Public Egress.
Exit does not need to be visible to websites or ordinary copyright/abuse complainants.
Easier to enforce destination encryption, ephemeral state and cryptographic complaint unlinkability.
Much easier path toward a realistic first prototype.

Cons

Still maintains a relatively small, identifiable special exit-node population.
Compromising one protected exit may expose more traffic metadata than compromising one node in a huge residential pool.
Professional nodes are often concentrated in datacenter ASNs.
Hosting-provider concentration can remain an issue.
Scaling requires operators to deploy more dedicated infrastructure.
Potentially easier for an adversary to enumerate the protected exit population.
Exit nodes remain comparatively valuable attack targets even if their public Internet role is removed.

Additional Step to the Approach 1. : Outsource the Mix-Net operations to some residential nodes.

The fact, that an exit operator is still vulnerable, may its an good idea to outsource this on an residential nodes.

Here also Additional Pros/Cons:

Pros/Cons

Pros

Far greater decentralization.
Potentially thousands or millions of participating machines.
Much greater ISP, ASN and geographic diversity.
Removes or greatly reduces the traditional dedicated exit as a special infrastructure role.
Compromising one residential processor normally affects only a very small portion of the network.
Makes infrastructure-wide surveillance/control more expensive.
Harder to enumerate the complete processing population.
Capacity can scale using hardware users already possess.
Home routers, NAS systems and always-on PCs could contribute resources.
Potentially much harder for one hosting company or datacenter operator to become a major observation point.
Can still use the same protection concept:
Residential Processor → Blind Relay → Public Egress.
Residential IP never needs to appear in the destination-facing Internet connection.
Complaints therefore still terminate at the public egress layer, not at the residential participant.
Strong long-term potential for turning Nym into a much more genuinely peer-assisted network.

Cons

Much harder to implement.
Residential nodes frequently appear/disappear.
NAT and CGNAT become significant engineering problems.
Highly variable bandwidth.
Highly variable latency.
Routers, PCs and phones have dramatically different hardware capabilities.
More difficult load balancing.
Requires sophisticated health/reliability scoring.
Requires fast failover when nodes disappear.
Sybil resistance becomes one of the largest security challenges.
Attackers could attempt to create large numbers of fake residential peers.
Need strong ASN/IP-prefix/operator diversity rules.
More software platforms must be supported securely.
Residential devices need very strong sandboxing and LAN isolation.
More complex update and patch-management model.
Higher chance of malicious or misconfigured participants.
Harder to guarantee consistent performance.
More difficult to debug because infrastructure is heterogeneous.
A large orchestration/discovery system would itself need to be highly privacy-preserving.

Here is also an PDF which describes the idea in a nutshell:

Again, these are thoughts which are came to my mind.
So take this as an inspiration and not as an fully solution. And feel free to ignore this completely.

Best regards

esgazqn · August 15, 2026, 3:09pm

Games

ARC Raiders — UDP 7777
Albion Online — TCP 4535, UDP 5055-5056
Apex Legends — TCP 1024-1079,3216,9960-9969, UDP 1024-1079
Arma 3 — TCP 2302-2305,2344, UDP 2302-2306,2344
Battle.net downloader (WoW/D4/OW2/SC2/HS) — TCP 6881-6999
Battlefield 2042 — TCP 9988
Black Desert Online — TCP 9991-9993, UDP 9991-9993
DayZ — UDP 2302-2305
Dota 2 — TCP 9100-9200
Escape from Tarkov — TCP 11007
Fortnite — TCP 5795-5847, UDP 5795-5847
Fortnite (secondary range) — UDP 9081-9100
Guild Wars 2 — TCP 6600
Lineage II — TCP 2106,7777
Squad — UDP 7787
War Thunder — TCP 7800-7802,7850-7854
Warframe — UDP 4950,4955,4960,4965

Self-hosted game servers

ARK Survival Evolved / Ascended — UDP 7777-7778
Abiotic Factor — UDP 7777
Conan Exiles — UDP 7777-7778
Eco — TCP 3000-3001, UDP 3000
Mindustry — TCP 6567, UDP 6567
Mordhau — UDP 7777
OpenTTD — TCP 3979, UDP 3978-3979
SA-MP / open.mp — UDP 7777
SCP Secret Laboratory — UDP 7777
Satisfactory — UDP 7777
Sons of the Forest — UDP 9700
Soulmask — UDP 7777
Terraria + TShock — TCP 7777,7878
V Rising — UDP 9876-9877
Valheim — UDP 2456-2458

Game platforms and cloud gaming

Battle.net client — TCP 6881-6999
Epic Games Launcher / EOS game traffic — UDP 5795-5847
PS Remote Play — TCP 9295-9304, UDP 9296-9304
Sunshine / Moonlight / GameStream discovery — UDP 5353
Xbox network / Xbox app for PC — UDP 500,3544,4500

Messengers, VoIP and conferencing

Apple APNs — TCP 2195-2197
Apple FaceTime media — UDP 3485-3497
BigBlueButton — TCP 5066,7443
Cisco SCCP secure — TCP 2443
Cisco Webex SIP signaling — TCP 5063-5070
Delta Chat SMTP submission — TCP 25
Element Call / LiveKit SFU — TCP 7880-7881, UDP 7882
FreeSWITCH — TCP 5066,5080,7443,8021, UDP 5080
Google FCM push — TCP 5229-5230
IAX2 (Asterisk inter-exchange) — TCP 4569, UDP 4569
Linphone RTP — UDP 7078-7079
MGCP — TCP 2427,2727, UDP 2427,2727
Matrix Conduit / conduwuit — TCP 6167
Mattermost — TCP 8065
Mumble / Murmur ICE admin — TCP 6502
Nextcloud Talk HPB — TCP 4222
Nostr relay (strfry) — TCP 7777
Prosody XMPP — TCP 5269,5280,5281,5347,5582
Rocket.Chat — TCP 3000
Ventrilo — TCP 3784,6100, UDP 3784
XMPP proxy65 file transfer — TCP 7777
ejabberd XMPP — TCP 4369,5210,5269,5280,5443,7777

Crypto, P2P and anonymity networks

Algorand node — TCP 4160
Avalanche node — TCP 9650-9651
BitTorrent peer + DHT — TCP 6881-6889, UDP 6881-6889
Bitcoin JSON-RPC alt / Litecoin RPC — TCP 9332
Cardano node — TCP 3001,6000
Cosmos / CometBFT gRPC — TCP 9090
Ethereum consensus beacon API (Lighthouse/Teku/Nimbus) — TCP 5051-5052
Hyphanet / Freenet FCP — TCP 9481
I2P router console / I2CP / SAM / BOB — TCP 2827,7654,7656,7657
NEAR RPC — TCP 3030
Nebula overlay — UDP 4242
Polkadot / Substrate RPC + WS — TCP 9933,9944
Prysm beacon gRPC gateway — TCP 3500
Solana gossip / TPU — TCP 8001, UDP 8001-8007,8009-8020
Stellar Core — TCP 11625-11626
Veilid — TCP 5150, UDP 5150
XRPL WebSocket — TCP 6006
ZeroTier — UDP 9993
i2pd web console — TCP 7070

Remote access and VPN clients

Amazon WorkSpaces / NICE DCV — TCP 4172,4195, UDP 4172,4195
Apache Guacamole guacd — TCP 4822
Check Point SecuRemote / Mobile Access — TCP 259,264, UDP 259,2746
Citrix ICA/HDX session reliability + EDT — TCP 2598, UDP 2598
Citrix licensing — TCP 7279
Cloudflare WARP / Zero Trust — UDP 2408
IPsec IKE + NAT-T (AnyConnect, FortiClient, GlobalProtect, strongSwan) — UDP 500,4500
Microsoft RD Gateway UDP transport — UDP 3391
Palo Alto GlobalProtect IPsec — UDP 4501
SoftEther VPN Server — TCP 5555, UDP 500,4500
SonicWall NetExtender SSL-VPN — TCP 4433
Splashtop — TCP 6783-6785, UDP 6783-6785
TeamViewer — TCP 5938, UDP 5938
VMware Horizon / Omnissa PCoIP — TCP 4172, UDP 4172
VMware Horizon Blast Extreme — TCP 9427
X11 / X.Org displays :0-:63 — TCP 6000-6011,6013-6014,6016-6063
oVirt websocket proxy — TCP 6100

Media, streaming and broadcast

AirPlay / AirPlay 2 — TCP 7000,7100, UDP 6001-6011,7011
AirPlay 2 PTP clock sync — UDP 319-320
DAAP / iTunes Home Sharing — TCP 3689
Google Cast / Chromecast — TCP 8009, UDP 5353
Jellyfin / Emby auto-discovery — UDP 7359
Kodi EventServer + JSON-RPC — TCP 9090, UDP 9777
Lyrion / Squeezebox CLI — TCP 9090
MPD Music Player Daemon — TCP 6600
NDI (discovery, remote sources, streams) — TCP 5959-5969,6960-6969,7960-7969, UDP 5960-5969,6960-6969,7960-7969
Plex Companion — TCP 3005, UDP 5353
Roku ECP — TCP 8060
Sonos — TCP 3400-3401,3500,4070, UDP 6969
Spotify Connect / access point — TCP 4070, UDP 5353
Tvheadend web + HTSP — TCP 9981-9982
UPnP AV / DLNA event + control — TCP 2869, UDP 2869
mDNS / Bonjour / Avahi discovery — UDP 5353

IoT, smart home and hardware

Bambu Lab LAN liveview — TCP 6000
CoAP + CoAPS/DTLS — TCP 5683-5684, UDP 5683-5684
ESPHome native API — TCP 3232,6052-6053, UDP 5353
Google Nest cameras / thermostats — TCP 9543,11095
HP JetDirect raw socket printing — TCP 9100-9102, UDP 9100-9102
IPMI / RMCP and RMCP+ — TCP 623,664, UDP 623,664
IPP / IPPS printing + AirPrint — TCP 631, UDP 631
Klipper Moonraker API — TCP 7125
LPD / LPR printing — TCP 515
Matter / CHIP over IP — TCP 5540, UDP 5540
Meshtastic network API — TCP 4403
ONVIF WS-Discovery (IP cameras, NVRs) — TCP 3702, UDP 3702
Philips Hue Entertainment API — UDP 2100
SNMP agent + traps — TCP 161-162, UDP 161-162
SmartThings Hub — UDP 11111
Syslog (UDP, TCP, reliable, TLS) — TCP 514,601,6514, UDP 514,6514
TFTP — UDP 69
Wake-on-LAN magic packet — UDP 7,9

Self-hosted services and homelab

AUTOMATIC1111 stable-diffusion-webui — TCP 7860
AdGuard Home — TCP 3000,5443, UDP 784,5443
Airsonic / Airsonic-Advanced — TCP 4040
Apache Kafka + ZooKeeper — TCP 2181,2888,3888,9092-9094
Authelia — TCP 9091
Bazarr — TCP 6767
Cassandra — TCP 7000-7001,7199,9142,9160
ClickHouse — TCP 9181,9234,9281,9363,9440
Cockpit — TCP 9090
CouchDB — TCP 4369,5984,6984
Deluge — TCP 6881-6891, UDP 6881-6891
Docker daemon / Swarm — TCP 2375-2377,7946, UDP 4789,7946
Drone CI / Coder — TCP 3000
Elasticsearch — TCP 9200,9300
Emby — UDP 7359
GitLab — TCP 2305,6432,9090,9100,9121,9168,9187,9236
Gitea / Forgejo — TCP 222,3000
Grafana — TCP 3000
Graylog — TCP 514,5044,5555,9200, UDP 514
Home Assistant — TCP 4357, UDP 5353,5683
Immich — TCP 2283,3001,3003
Jackett — TCP 9117
Jellyfin — UDP 7359
Kibana — TCP 5601
Kodi — TCP 9090, UDP 9777
Kubernetes control plane — TCP 2379-2380,6443
Loki — TCP 3100,7946,9095
MariaDB Galera cluster — TCP 4567-4568, UDP 4567
MeshCentral Intel AMT MPS — TCP 4433
NATS — TCP 4222,6222,7222,7422
NZBGet — TCP 6789,6791
Navidrome — TCP 4533
Neo4j — TCP 6000,6362,7000,7473-7474,7687-7688
Nextcloud + Collabora CODE — TCP 4222,9980
Ollama — TCP 11434
Open WebUI — TCP 3000
OpenSearch — TCP 5601,9200,9300
Overseerr / Jellyseerr — TCP 5055
PhotoPrism — TCP 2342
Pi-hole FTL API — TCP 4711
Plex Media Server discovery — UDP 5353
Prometheus + exporters + alertmanager — TCP 9090-9091,9093-9094,9100-9200,9216, UDP 9094,9125
Prowlarr — TCP 9696
Radarr — TCP 7878
Rancher / RKE2 — TCP 179,2379-2381,4240,5473,6443,9098-9099,9345, UDP 4789
Redis — TCP 6379
SABnzbd — TCP 9090
Scrypted — TCP 11080
Technitium DNS Server — TCP 5380,8053
Transmission — TCP 9091
TrueNAS — TCP 111,548,3260, UDP 111,161
UniFi Network Application — TCP 6789, UDP 5514,5656-5699
Uptime Kuma — TCP 3001
Vaultwarden websocket — TCP 3012
Wazuh — TCP 514,9200, UDP 514
etcd — TCP 2379-2381
k3s — TCP 2379-2380,6443
ownCloud Infinite Scale — TCP 9200
qBittorrent — TCP 6881, UDP 6881
rTorrent / ruTorrent — TCP 6881-6999, UDP 6881-6999

Hitting an explicit reject rule — separate vote, drop if preferred

Destiny 2 — TCP 7500-7509, UDP 3097-3196
World of Tanks — TCP 3128
Parsec — UDP 8000-8007,8009-8040
IRC (IANA assigned) — TCP 194,529, UDP 194,529
IRC conventional + IRCv3 — TCP 6660-6669,6679,7000
Tencent QQ — TCP 8000, UDP 8000
Tox / qTox TCP relay — TCP 3389
Bisq / Haveno P2P — TCP 8000
I2P SOCKS proxy / IRC tunnel — TCP 4447,6668
Microsoft RDP — TCP 3389, UDP 3389
Squid / corporate HTTP proxy — TCP 3128
Telnet — TCP 23
VNC / RFB displays + Java viewer — TCP 5800-5809,5900-5909
Icecast — TCP 8000
SHOUTcast DNAS — TCP 8000,8001
Hikvision SDK / Reolink media port — TCP 8000, UDP 8000
Tuya local control + LAN discovery — TCP 6668, UDP 6666-6667
Kasm Workspaces — TCP 3389,6901
Proxmox VE — TCP 3128,5900-5999,8006-8007, UDP 5404-5412

esgazqn · August 15, 2026, 4:13pm

## Games
* Dauntless — TCP 5269, UDP 5269
* EA App / Origin — TCP 1024-1079,9960-9969, UDP 1024-1079
* Enemy Territory Quake Wars — TCP 7133
* FIFA 22 / EA Sports FC — TCP 3569,9946,9988
* Grand Theft Auto Online — UDP 6672
* Hytale — TCP 5520
* PS Remote Play (full) — TCP 9293,9295, UDP 9296,9297,9309
* Pavlov VR — TCP 9100
* Payday / Payday 2 — TCP 9899, UDP 9899
* PlayStation console wake — UDP 987
* Red Dead Online — UDP 6672
* Steam default dedicated server range — TCP 7779-7788
* VRChat — UDP 5055-5056,5058
* Valorant — TCP 2099
* Warframe (TCP side) — TCP 6695-6696,6698-6699
* Warzone 2100 — TCP 2100
* World of Tanks Blitz — UDP 2479,3432

## Self-hosted game servers
* Aleph One (Marathon) — TCP 4226, UDP 4226
* Armagetron Advanced — UDP 4534
* BZFlag — TCP 5154, UDP 5154
* Blood Quest Online — TCP 11294, UDP 11294
* Doom (classic netplay) — UDP 666
* Freeciv — TCP 5555,5556, UDP 5556
* NetPanzer — TCP 3030, UDP 3030
* Planet M.U.L.E. — TCP 6260, UDP 6260
* Savage Battle for Newerth — TCP 11235, UDP 11235
* Sonic Robo Blast 2 — TCP 5029
* WarMUX — TCP 3826
* YSFlight — TCP 7915

## Legacy games, private servers and emulators
* Age of Empires II (Voobly, GameRanger, DirectPlay) — TCP 2300-2400, UDP 2300-2400
* Aion emulators — TCP 2106,7777
* Anarchy Online — TCP 7012-7013,7500-7600
* Baldur's Gate / Icewind Dale (DirectPlay era) — TCP 2300-2400, UDP 2300-2400
* Battle.net legacy (Diablo/StarCraft/WC3) — TCP 3723, UDP 3723
* Battlefield 1942 / 2 / 2142, Project Reality — TCP 4711
* City of Heroes Homecoming / Rebirth — TCP 2106,6994, UDP 7000-7200
* Club Penguin style Flash MMOs — TCP 9875
* Dark Ages — TCP 2610
* Descent 3 — UDP 2092
* EQ2EMu (EverQuest 2 emulator) — TCP 9100
* Endless Online — TCP 8078, UDP 8078
* EverQuest EQEmu / Project 1999 — TCP 5998-5999, UDP 5998-5999
* GameSpy replacements (OpenSpy, 333networks) — TCP 6500, UDP 6500
* Halo PC / Custom Edition — UDP 2302-2306
* Killing Floor 1 — TCP 8075, UDP 7707-7717
* L2J / L2JMobius (Lineage 2) — TCP 2106,7777
* MaNGOS / CMaNGOS (WoW emulator) — TCP 7878
* MapleStory v83 private servers — TCP 7575-7600
* Meridian 59 / OpenMeridian — TCP 5959
* Metin2 private servers — TCP 11002
* Neverwinter Nights 1 / 2 — TCP 5121, UDP 5121,6500
* Red Orchestra Ostfront / Darkest Hour — TCP 8075, UDP 7757-7767
* The Palace — TCP 9996, UDP 9996
* Tibia OTServ / Forgotten Server — TCP 7171,7172
* TrinityCore / AzerothCore (WoW emulator) — TCP 3443,7878
* Ultima Online RunUO / ServUO — TCP 2593,2599, UDP 2593
* Unreal Tournament 99 / 2004 / OldUnreal — TCP 7777-7788,8075, UDP 7777-7788
* Warhammer Online Return of Reckoning — TCP 8048
* rAthena / Hercules (Ragnarok Online) — TCP 5121,6121,6900

## Hitting an explicit reject rule — separate vote, drop if preferred
* CnCNet (Command & Conquer) — TCP 6667, UDP 8054-8060
* PvPGN (StarCraft / Diablo II / Warcraft III) — TCP 4005,6200,6667, UDP 6200