Windrose ISP Blocks, DNS, IPv6, and Port 3478 Co-op Fix

Windrose ISP Blocks, DNS, IPv6, and Port 3478 Co-op Fix

When a Windrose crew cannot connect and every surface-level check passes — the server is running, the invite code is correct, the client files are verified, the tutorial gate has been cleared, versions match — the cause is almost always one of three things sitting in the network path between the player and Windrose's backend. DNS filtering on the consumer side, an IPv6-preferring operating system, or an ISP that is quietly blocking the NAT-traversal port used to bring two co-op participants together. These three classes have already been called out in community threads, in the official FAQ, and by the developers themselves on Discord, who after the April 14, 2026 Early Access launch specifically said that some co-op services appear to be restricted or blocklisted by ISPs across Europe and North America. That is unusually explicit. It also means that if your crew is failing to connect, the fastest way to find the problem is to stop tweaking the game and start looking at DNS, IP family preference, and UDP port 3478.

This guide is written for hosts, server operators, and players who have already ruled out the obvious blockers. It walks through what each of the three problem classes actually is, how to detect it from a normal consumer PC, and which knob to turn when you find it. The goal is to get your crew back on the water without accidentally creating three new problems while fixing the first one.

Why ISP-side blocking is a real issue

For most games, ISP-side blocking is a fringe problem. In Windrose's first week of Early Access it is a central one. The developer team publicly asked for help from ISP specialists because connection failures were clearly concentrated in specific regions and on specific providers rather than spread evenly. Some players on Ziggo in the Netherlands, on Spectrum in the US, and on a handful of other carriers with aggressive "security" filtering reported that they could reach Steam, reach Discord voice, reach any normal website, but could not complete a Windrose connection until they disabled a router-level security feature or switched to a different DNS resolver. The pattern is specific enough that it is worth treating ISP-side interference as a front-line possibility rather than a rare edge case.

Symptom fingerprints

Problem class 1: DNS filtering

The single most common ISP-side block is DNS filtering. Consumer DNS resolvers like NextDNS, Pi-hole, AdGuard, strict-mode Quad9, or built-in ISP "parental controls" can and do block the domain windrose.support. Once that domain fails to resolve, the game cannot reach its NAT-traversal backend, and every downstream step looks broken even though nothing about your server or account has changed.

You can test this in one command on Windows:

nslookup r5coopapigateway-eu-release.windrose.support

Good outcomes:

• You get a normal IPv4 answer like 3.x.y.z or 18.x.y.z.
• You get a short list of A records with a sane TTL.

Bad outcomes:

• You get no answer at all (SERVFAIL).
• You get 0.0.0.0 or 127.0.0.1, which means a filter is sinkholing the domain.
• You get only AAAA (IPv6) records.
• You get the private-address range answer (192.168.x.x), which is a sign of rewrite.

If any bad outcome shows up, change your DNS temporarily to a known neutral resolver (Cloudflare 1.1.1.1 or Google 8.8.8.8) at the operating-system level and retry. You will probably find that the join works immediately. If it does, you can decide whether to keep the neutral DNS permanently or to whitelist the Windrose domains inside your existing filter.

Problem class 2: IPv6 preference

Windrose's current co-op path is IPv4 only. If your PC prefers IPv6 and your ISP's IPv6 path answers a DNS query with a valid-looking record, the client can get tangled and time out. This is especially common on machines with Teredo, 6to4, or ISATAP tunneling still enabled, and on some ISPs where IPv6 connectivity is technically available but practically broken.

The test is simple:

netsh interface ipv6 show prefixpolicies

You want to see that IPv4 precedence is at least as high as IPv6. If your prefix policy table is showing IPv6 ahead of IPv4, that alone can cause Windrose's connection attempts to stall.

There are three useful responses:

1. Run the prefix-policy registry tweak recommended by the Windrose FAQ to make IPv4 preferred without fully disabling IPv6.
2. Disable IPv6 at the network adapter level as a one-shot test, then reboot, and retry. If that fixes it, you have confirmed the layer and can decide how to resolve it long-term.
3. Keep IPv6 on if you need it for other services, and instead flush DNS and force the client to re-query after switching DNS to a resolver that does not return AAAA aggressively for the Windrose domain.

Do not assume IPv6 is to blame before testing. Disabling IPv6 unnecessarily can hurt other services. The point is to make it not preferred for the Windrose call path, not to strip it out of your network stack entirely.

Problem class 3: UDP/TCP port 3478

Windrose uses a STUN-style handshake over port 3478 to bring two co-op participants together through NAT. Most consumer routers pass this just fine. Some do not. The usual culprits are:

• ISP-provided routers with built-in "network security" suites (Ziggo SafeOnline, Spectrum Advanced Wi-Fi, some BT and Virgin Media modes).
• Aggressive SPI firewalls that drop unsolicited UDP.
• Corporate or student-housing networks that enforce whitelist-only outbound traffic.
• VPN services that block STUN specifically to force traffic through their own relays.

You can test port 3478 reachability directly:

telnet windrose.support 3478

If the connection drops or hangs immediately, 3478 is being filtered. Some ISPs block TCP but still let UDP through, so the telnet test is not definitive by itself. If you suspect UDP is the problem, use an online UDP port checker to confirm.

When port 3478 is blocked, your practical options are:

1. Open port 3478 (TCP and UDP) outbound in your router's firewall if it is locked down.
2. Disable the router's security-suite feature that is dropping it, accepting the obvious tradeoff for other traffic.
3. Port-forward 3478 to your machine as a last resort. This is not required by default, but it helps on very strict NAT setups.
4. Contact your ISP and ask them to whitelist *.windrose.support on port 3478. Some ISPs will do this for customers who ask directly.

This third class is the one the developers explicitly mentioned when they publicly asked for help from ISP specialists. It is the place where the symptom is most clearly outside the server operator's control.

Suggested triage order

1. Resolve r5coopapigateway-eu-release.windrose.support with nslookup on each failing machine.
2. If it fails or returns private IPs, change DNS to a neutral resolver and retry.
3. If DNS is clean, run the prefix-policy check and confirm IPv4 is preferred.
4. If both DNS and prefix policy look clean, test port 3478 reachability.
5. If 3478 is blocked, check router security suites and then the ISP itself.
6. Only after all three classes are clean should you suspect the game, the server, or the account state.

What server operators can do

You cannot fix a customer's ISP. You can, however, make the triage path faster by:

• Publishing a short "is your ISP blocking Windrose?" knowledge-base article on your panel, with the three one-liners (nslookup, netsh, telnet).
• Displaying a "Windrose uses UDP/TCP port 3478 outbound" note on the hosting product page so prospective customers know what their network needs to allow.
• Logging the exact invite code and time when a customer says "I can't connect." Matching that against a healthy server response proves the server is fine and shifts the investigation to the customer's network.
• Offering a basic SSH/tcpdump capture diagnostic for paying customers on request. You will usually find the packets never arrive at the server.

Where this intersects with the tutorial gate

It is common to have one player fail for ISP reasons and another fail because they skipped the singleplayer tutorial. They look identical from the outside: both are silent failures. The difference is whether the failure is universal (ISP or DNS) or individual (tutorial or account). If only one person in the crew is failing and everyone else is on the same home network, the tutorial gate is far more likely. If two or more are failing simultaneously and they are on the same ISP, the ISP-side class is far more likely.

Decision table

Sources

• Official Windrose FAQ
• GosuGamers: Windrose devs call on ISP experts
• GamesRadar: Windrose hotfix and connectivity
• Steam discussion: Server Join Problems — Possible fixes
• PCGamingWiki: Windrose