[Feature] ConeNAT support

[myloft]

Description

From v2.4.1, the NAT type has changed to Symmetric NAT.

Is this feature related to a specific bug?

No response

Do you have a specific solution in mind?

No response

[myloft]

I'd be happy to help, although I don't know how to do it right now.

[xjasonlyu]

Before v2.4.0, the NAT part was written with a customized/unofficial UDP module, which makes it simple to implement Full-Cone NAT. But due to the aggressive gVisor update frequency, the API constantly changes, contributing the terrible code maintainability.

Therefore, starting from v2.4.0, the official gVisor net module was used to avoid regular code adaptations for its daily API updates. However, this also imported another issue - NAT. The gVisor abstracts its UDP module as a connection-based net, making it infeasible to receive packets from other sources, which causes the NAT type can only be symmetric for now.

To support Cone-NAT at this stage and keep the high code maintainability, we can only use a NAT table to map the connections and create a "fake" Port Restricted Cone NAT. The implementation can be done inside the tunnel/udp.go file. But it can be a bit complex and buggy at the beginning, and that's why I haven't implemented it yet. You're welcome if you want to contribute to this feature!

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

[GektorUA]

Is there any possibility that Full Cone NAT will be back in future versions?

[rurirei]

The gVisor abstracts its UDP module as a connection-based net, making it infeasible to receive packets from other sources, which causes the NAT type can only be symmetric for now.

Is there any possibility that Full Cone NAT will be back in future versions?

maybe no.

[rurirei]

To support Cone-NAT at this stage and keep the high code maintainability, we can only use a NAT table to map the connections and create a "fake" Port Restricted Cone NAT. The implementation can be done inside the tunnel/udp.go file. But it can be a bit complex and buggy at the beginning,

how do we comfirm the source addr to map some *gonet.UDPConn connections?

[dksslq]

Nobody care this?