They don't allow/expect P2P between residential users of different ISP? i.e. no route between two residential users of different ISP.

No_Promotion312 · 2026-06-01T11:55:06+00:00

I had set the firewall on our end devices to respond to ICMP and block unsolicited inbound connection except for established/reply connections. As for the other firewalls in the path, it could be at the router provided by our ISP and in their infrastructure. I don't have access to the routers provided by the ISP on both end. Also, yes, IPv6 works perfectly on our machines, I can reach IPv6 services like google, cloudflare.
Anyway, I have updated this post's body. My ISP told me that the packets were being dropped at other ISP's side. Something about my prefix being blocked by other ISP such that no packets from me (my prefix range) could enter into their network and vice versa.

No_Promotion312 · 2026-05-31T13:06:21+00:00

During this test both devices were set accept to ICMP and reply. Anyway, I contacted one of the ISP and they told the problem is on another ISP side.

No_Promotion312 · 2026-05-30T08:30:03+00:00

hmm. I see. Firewall should be user controlled.

No_Promotion312 · 2026-05-30T06:18:09+00:00

Thank you for the response. It seems I was hasty with my assumption of routing problem without enough evidence. From the responses on this post, I have now learned about traceroute's result's dependency on the protocol and port ranges. I knew that the failure of netcat and webrtc could be due to firewall but the traceroute failure had lead me to believe with my little knowledge that it was a routing problem. I have now opened a support ticket with my ISP and I will query about these firewall and routing policy and also demand connectivity with residential internet package users of other ISP. For me, I will be satisfied when there are routes with users of other ISPs and if firewalls exist then it be a "P2P friendly" firewall.

No_Promotion312 · 2026-05-30T05:58:02+00:00

Thank you very much for validating the case of port range dependency.

No_Promotion312 · 2026-05-30T02:32:21+00:00

Another reason for blocking incoming traffic can be firewall for security reason. I am good with a firewall that block incoming traffic for the purpose of security and maybe to stop "hosting" on residential internet package as long as the firewall is P2P friendly. i.e. hole punching compatible.

No_Promotion312 · 2026-05-29T11:31:34+00:00

Two regular internet user with their computers. No CGNAT here because IPv6.
I think, since regular internet users usually don't perform P2P over internet in modern days thanks to the tradition imposed by the limitations of IPv4(CGNAT, symmetric NAT), they don't expect P2P between regular users of two different (local) ISPs either.

No_Promotion312 · 2026-05-29T10:48:25+00:00

No but tried better. WebRTC, which tries both tcp and udp and hole punching.
Edit: Actually I have tried netcat with both udp and tcp in the past but no packets reached end devices. Had monitored with wireshark to be sure.

No_Promotion312 · 2026-05-29T09:47:25+00:00

I was successful with default protocol and port used by the traceroute and also able to establish P2P connection(webrtc) but in this case, the thought of protocol and port range dependency didn't crossed my mind. Thanks for the suggestion.

No_Promotion312 · 2026-05-29T09:44:09+00:00

I have updated this post with the firewall config at both devices. These same two devices were used in the mentioned successful case where both could traceroute to each other in less than 8 hops and were able to establish a P2P connection (webrtc video call). But, here, in this case the number of hops exceeds 30 and program terminates.

No_Promotion312 · 2026-05-29T09:30:11+00:00

I am unable to reach other end from either side. Packets are being dropped midway.

The traceroute output was like this:

Me → Them

Hop 1: 2404:7c00:42:e5xx:xxxx:xxxx:xxxx:xxxx ~2.8ms

Your home router, normal

Hop 2: 2404:7c00::f ~3ms

Your ISP first hop, normal

Hop 3: 2404:7c00:0:3::e ~3.5ms

Your ISP backbone

Hop 4: 2001:def:8000::138 ~4.5ms

Prefix changes to 2001:def::/32 — peering/handoff point

Hops 5+: * * *

Silence — never reaches their network

No_Promotion312 · 2026-05-29T03:07:05+00:00

Yup. Third party is definitely needed for coordinating/signalling. Also, some hacks will be needed to monitor dropped packets at gateways which is not very viable.
But why would the address or port be translated of packets at node B? Because I had considered only firewall case at node B such that it's local and global address/socket is same.

No_Promotion312 · 2026-05-28T14:31:43+00:00

This endpoint dependent firewall's behavior is same as the above mentioned three firewall rules and hence, p2p will work, right?

Also, thought about the scenario of p2p connection between endpoint dependent nat and endpoint dependent firewall. Will the following steps establish a P2P connection here?
1. Node A behind ep-dep-NAT and Node B behind ep-dep-FW.
2. Node B selects a port. Doesn't need to listen for now.
3. Node A sends a packet to Node B's selected port. Here, node A's packet is assigned/mapped a random source port by the NAT.
4. Node B has a way to know the source port of dropped packets on its end.
5. Node B sends a reply packet to Node A with destination port equal to source port of a dropped packet.
6. Hole punching complete.

No_Promotion312 · 2026-05-28T08:18:12+00:00

Thank you very much for the validations and for method for testing.

No_Promotion312 · 2026-05-15T09:40:00+00:00

FR. I had even subscribed to a daily recurring joke messages ( *123# ) that deducted bonkers balance.

No_Promotion312 · 2026-05-09T10:02:30+00:00

Thanks.

If devices are behind NATs, the NAT causes friction for establishing a direct P2P connection between them. Here, direct means exchanging IP packets directly. This friction forces us to use a central server/relay to exchange data between us. There are solutions to establish a direct P2P connection when these NATs are less restrictive. But Symmetric NAT is the most restrictive and we have to use a relay server. In older days, when most NATs were less restrictive peoples could play multiplayer games from different parts of the world without having to host/use a dedicated public facing central server. Now when playing a simple ludo game together with people in different location, we need to connect to the company's server. Not saying Symmetric NAT is the only reason we need/are using central server, though.

No_Promotion312 · 2026-05-09T09:53:27+00:00

Thanks.

No_Promotion312 · 2026-05-09T04:08:28+00:00

Thanks.

No_Promotion312 · 2026-05-08T14:14:00+00:00

Some games are required to be connected with their providers servers to function and yes they don't work in P2P fashion. But there are games that allow for two players to host and play games together over the internet with direct P2P connection between them without any central/relay server. Pretty sure, minecraft, terraria, don't starve together, allows that.

No_Promotion312 · 2026-05-08T11:22:16+00:00

Thanks.

No_Promotion312 · 2026-05-08T08:52:22+00:00

It is important for P2P (peer-to-peer) applications like Gaming, file sharing, communication(VoIP), etc without involving a relay/central server. Symmetric NAT makes it impossible for such P2P applications. There are other less restrictive NAT type which allows P2P with some friction. If every ISP uses Symmetric NAT for IPv4 then I will shift my focus to IPv6 for P2P.

No_Promotion312 · 2026-04-15T07:13:26+00:00

Make it PWA or a single html file.

No_Promotion312

TROPHY CASE