Skip to content

NAT Behaviour

Xiaokang Wang edited this page May 8, 2021 · 3 revisions

Port Assignment

VLite always tries to assign a source port on the server that matches the source port of the client. This ensures that even if the game does not use STUN on the listening port to discover its public port, it would still work since the server always attempts to preserve the source port of the client's UDP Session. It will assign a port randomly if it cannot assign that port to the client.

Mapping Refresh/Session timeout

VLite always tries to keep the session for the client as long as possible. It will by default keep the session open for the client 30 minutes after the last packet have been sent/received on that port. This is usually more than enough for getting any game running without interruption. There is an exception for sessions with a destination port of 53, a shorter time out is used since the client can usually tolerate failure, and it is unlikely to receive traffic without sending a request for DNS.

Filtering Behavior

VLite always uses Endpoint-Independent Filtering. This ensures the best connectivity for the user, and will always achieve a "Full cone" status in Connectivity Check on supported server.

Hairpinning Behavior

VLite supports Hairpinning, as it uses the Linux operating system's network stack, which automatically handles this situation.

Application Level Gateways

VLite is not an Application Level Gateways. It supports traffics generically and works with every STUN based P2P protocol.

Clone this wiki locally