Discussion
A most elegant TCP hole punching algorithm
jcalvinowens: If you're asking "where is the listener", you don't need one: https://datatracker.ietf.org/doc/html/rfc9293#simul_connect
EnigmaCurry: > Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity.It is precisely this point that has flummoxed me when connecting my p2p wireguard config[1] with a friend that uses a pfsense router, no matter what we tried, pfsense always chooses a random source port.But in the simple case this blog outlines, if both ends use the same source port, this method punches through 2 firewalls effortlessly:[1] https://blog.rymcg.tech/blog/linux/wireguard_p2p/
getcrunk: AI ANSWER: (lightly edited)The Solution (Static Port)To fix this without a permanent port forward, you must enable Static Port in pfSense's Outbound NAT. This doesn't open a hole to the world; it simply tells pfSense: "When this internal IP sends UDP traffic, do not rewrite the source port."Navigate to Firewall > NAT > Outbound.Switch to Hybrid Outbound NAT (if not already).Add a rule at the top:Interface: WANProtocol: UDPSource: [Friend's WireGuard Internal IP/Port]Destination: [Your Public IP]Translation: Check Static Port.
lxgr: Did you validate this solution yourself?
getcrunk: No, hence the all caps ai disclaimer. But seems plausible
nneonneo: Lord, we're how many years into using LLMs, and people still don't understand that their whole shtick is to produce the most plausible output - not the most correct output?The most plausible output might be correct, or it might be utter bullshit hallucinations that only sound correct; the only way to tell is to actually try it or cross-reference primary sources. Unless you do, the AI answer is worthless.The reason why they're getting so good at code now is that they can check their output by running and testing it; if you're just prompting questions into a chatbot and then copying their output verbatim to a comment, you're not adding any meaningful value.
anovikov: Exactly! This is what LLMs do: they bullshit you by coming across as extremely knowledgeable, but as soon as you understand 5% of the topic you realise you've been blatantly lied to.
Veserv: Needing to punch holes in NAT is one of the most idiotic own-goals in the entire field of networking.NAT is effectively your router doing DHCP with a 17-bit suffix (16-bit port + 1 bit for UDP vs TCP) to each of your applications and then not telling you the address it gave you or how long it is good for (which is what a regular DHCP lease does). This is in addition to it, most likely, already doing regular DHCP and allocating you a IP address that it does tell you about, but which is basically worthless since routing to just that prefix without the hidden suffix goes into a black hole.If you could just ask your router for a lease on a chunk of IP+NAT addresses that you could allocate to your applications and rotate them as they expire, you would not need this horrifying mess.The router would just need to maintain the last-leg routing table (what a concept, a router doing routing with routing tables) just like it already does DHCP.The applications would have short-term stable addresses that they could just tell their peers and just directly tell the router/firewall to block anybody except the desired peer short-term address.
lxgr: > If you could just ask your router for a lease on a chunk of IP+NAT addressesThe “just” is doing a lot of lifting there. I’m glad the various port mapping protocols didn’t really take off and it looks like IPv6 is going to actually make it instead. Much less complexity in most parts of the stack and network.
hrmtst93837: Assuming IPv6 kills NAT is optimistic, plenty of orgs still stack private addressing and firewalls on top.
