Documentation
NAT and firewalls: what to check
The question “which ports should I open?” comes up often, but it is ill-posed for a VIGIL-MESH node: a node opens no inbound port. It always establishes its connections outward, like a web browser. What matters is therefore not what your firewall lets in, but what it lets out. This page sorts it out: a reminder of the model, what to do if a network blocks UDP, the only ports that concern a vigie, and the behaviour in the face of strict NATs.
Reminder: the node opens no inbound port
A VIGIL-MESH node listens on no inbound port. There is therefore no port-forwarding rule, no inbound opening to configure on the router or on the machine's firewall. Every connection leaves the node outward; it is egress that has to work.
What is NOT needed
No inbound port forwarding, no public IP, no inbound firewall rule on the node side. A node behind several layers of NAT works without any particular network configuration.
What matters
Egress. The node must be able to reach the vigie outward. If UDP egress is open, all the better; otherwise, the tcp-only profile takes over.
Networks that block UDP: the tcp-only profile
Some corporate networks or hotels filter outbound UDP and only let TCP through. VIGIL-MESH favours UDP (better for traversal and direct paths), but automatically falls back to a tcp-only profile when UDP is unreachable: traffic then rides TCP to the vigie, on port 443.
- Typical symptom: the node connects but systematically stays on the relay, never establishing a direct path. Without UDP, peer-to-peer traversal cannot form.
- The node remains functional in tcp-only: connectivity is preserved, at the cost of a pass through the vigie and lower efficiency than a direct UDP path.
- To confirm the block: test outbound UDP from the machine to the outside. If UDP gets out elsewhere but not to the vigie, it is targeted filtering by the firewall.
- If you control the firewall, allowing outbound UDP restores the possibility of direct paths and lightens the load on the vigie.
Ports to open for a VIGIE only
Opening inbound ports only ever concerns the vigie (the relay), never the nodes. A vigie is the public rendezvous point that nodes reach outward; it is therefore the one that must be reachable from outside. If you host your own vigie, open inbound:
| Port | Protocol | Role |
|---|---|---|
| 443 | UDP | Main QUIC transport from nodes to the vigie. |
| 4433 | UDP | Secondary QUIC transport. |
| 443 | TCP | tcp-only fallback for networks that block UDP. |
These three ports are to be opened inbound on the vigie only. The reference list and the details are in /en/docs/reference-ports. To remember: node side, nothing; vigie side, these three ports.
Strict NATs and traversal
Symmetric (so-called “strict”) NATs assign a different external port for each destination, which prevents direct peer-to-peer traversal: the two nodes cannot predict each other's rendezvous address. This case is common behind some carrier routers or corporate firewalls.
- Consequence: the direct path does not form, traffic stays on the vigie. Connectivity is maintained, efficiency is lower.
- This is not something to fix on the node side: no node setting forces a symmetric NAT to cooperate. The relay exists precisely for this case.
- If you control the equipment, a less strict (cone) NAT on at least one of the two peers is often enough to restore direct paths.
- The “stays on relay” diagnosis overlaps with connection problems: see also /en/docs/depannage-connexion and /en/docs/chemins-relais.