Nebula punchy settings: which one fixes your NAT

Two peers find each other through the lighthouse and then fail to build a direct path, and the first instinct is to turn on every punchy option. That instinct produces a configuration with three changes and no idea which one mattered. The settings answer different questions: one maintains a mapping that already exists, and one attempts a handshake in the reverse direction. Decide which question you have before touching either.

Confirm the endpoint before the timing

A peer that never appears at the expected address will not be rescued by punch tuning. Check what the lighthouse knows about the peer and what the peer's own configuration advertises, because a stale bootstrap address or a private address published by mistake defeats every traversal trick. Confirm that the certificate is trusted as well, since an untrusted identity stops the conversation long before NAT matters. Then verify that UDP reaches the lighthouse at all. Timing values are the last thing to look at, not the first.

Record the endpoint pair you are testing with, so later comparisons use the same peers rather than two other machines.

Punch keeps a mapping; respond opens a direction

The punch option sends empty packets periodically to the underlay address of a peer that already has a tunnel. Its purpose is unglamorous: it keeps a stateful NAT or firewall from expiring the mapping the direct path depends on. The respond option changes what happens on a lighthouse notification, making the host attempt a handshake back toward the peer trying to reach it. Those are different mechanisms with different failure modes.

Choose punch when the direct path works and later decays. Choose respond when the path never forms in one direction. Enabling both and hoping is how a five-minute fix becomes a week of tuning.

The delays decide when, not whether

The delay values shift timing: one applies to the packet sent after a notification, the other to the reverse handshake attempt. Neither makes a blocked direction work. Changing both at once destroys the comparison you were about to run.

Leave them alone until the mechanism is right. Then adjust one, and keep the old value written down.

When a relay is the honest answer

Some NAT combinations cannot support a direct path however the timing is arranged. Symmetric NAT on both sides, or a firewall that drops unsolicited inbound traffic entirely, leaves nothing to punch through.

A relay node with a reachable address gives those peers a path that does not depend on traversal succeeding. It costs bandwidth through that node, so it is a decision about capacity rather than a workaround. Configure the relay deliberately and check that the peers can reach it, because a relay that is itself behind a difficult NAT changes nothing. Then stop tuning the punch settings for that pair, since the direct path was never going to appear.

Test the pair that failed, after idling

Reproduce the condition that broke: leave the pair idle for the same interval, or repeat the handshake sequence that used to fail. Then exercise the application between those two peers, not a request to the lighthouse. A lighthouse response proves the control path and nothing about the data path.

Record which setting changed, the time, and whether a direct path appeared or traffic stayed on the relay. If it stayed, the answer is a relay and a capacity note, and that is a perfectly good outcome. If it appeared, the next question is whether it survives an hour of idling, because a mapping that decays is exactly the problem punch exists to address.