Base de conocimientos

ICMP - Pings IPv4 y NAT Pruebas de rango de puertos IPv4

NAT Port Range Testing

In order to work as intended, the application that you wish to run through the NAT IPv4 system must fulfill the following requirements:
- The application shall prefentially be dual-stack (i.e. support IPv4 and IPv6 connectivity);
- Must be able to listen on [::]::0 and/or 0.0.0.0/0, the catch-all addresses for IPv6 and IPv4;
- Specific for UDP usage only: shall preferentially send send a continuous packet stream over UDP. 

Nearly all written applications for Linux support dual-stack connectivity. Notable and known exceptions have included:
- SOCKS 4 and SOCKS 4a (it is supported at SOCKS 5);
- Docker only with versions below 27.0.1 (which was launched on June 24th, 2024). Some distributions still implement the previous version 26, primarily Debian 12 and 13, for example; Ubuntu 24.04 LTS is confirmed to support Docker at 27.5, for example, making it a usable alternative;
- Kubernetes (only versions before December 2021). Debian 10 does not have support, first support is at Debian 11.
- Other software before 2017/2018.

The NAT IPv4 IP address informed at VirtFusion's NAT port maps (on the VirtPortal, at virtportal.cfld.uk) does not need to be provided to the application on the VPS, which will have a private IPv4 and a public IPv6. It is enough to have the application listening to catch-all addresses. Traffic sent at a given port range will be automatically split by our Libvirt bridging and, whenever it is not possible to reach one of the addresses, it will proceed with the other.

Test examples for TCP and UDP

Remember: ports are always pre-opened automatically at the given outbound port range for you, and you simply map them to the internal ports on the scheme shown at the VirtPortal - to any specific internal port you desire. You don't need to send us a ticket, in fact, we explicitly do not support tickets on NAT port operation, which shall be entirely autonomous by the user.

Example for TCP: attempt to change a service, e.g. /etc/ssh/sshd_config to any one port (except ports under 1024, or port 22) of your VPS.
Ensure "PubkeyAuthentication" is set to No and uncommented (without the #), and "PasswordAuthentication" is set to Yes and uncommented.  Save. Now do:

sudo systemctl restart sshd [for Debian, AlmaLinux, Rocky Linux, Fedora], or
sudo systemctl restart ssh [for Ubuntu]

in order for the SSH service to restart. Ensure it's listening on both formats prior to any testing.

After that, you can attempt to login using PuTTY, MobaXterm or any SSH client, inserting the global server's IPv4, the VPS Linux user (root) and that specific outbound port available on the VirtFusion's portal, the VirtPortal (for example 43560); it will map directly to the internal port you specified for SSH (for example 4096); and it will work flawlessly.

Another nice solution can be for example installing a iperf3 server/client dynamic, with your VPS acting as an iperf3 server and any computer with Linux acting as an iperf3 client. This works by default on TCP with 1 stream. You have always the possibility of testing with a higher number of streams and/or testing with UDP as well, and you can define any internal port where that is going to happen on your VPS, according to the VirtPortal's NAT port mapping.

There are plenty of guides available on the Internet for the iperf3 packages, and they will work on our VPS systems as we operate standard IPv4 NAT. Just ensure that, from the client, you're always targeting either the IPv6 or the public IPv4 of the system (the global dedicated server's IP), and you're good to go.

Example for UDP: install netcat-openbsd, available under Debian or Ubuntu systems. After install, ensure you don't want to run any further commands prior to netcat, and run the following command:

nc -6 -u -l -p [number of your port]

where [number of your port] will be the UDP-exclusive port-range you have on your VPS for NAT IPv4 (check the Knowledge Base article for NAT IPv4 port calculation). 

The process will start to listen, over IPv6, at the port you've chosen, and will stay like that.

After that, attempt to send anything (text, message, etc) via UDP:

From Windows Powershell
$message = "Test UDP"; $udpClient = New-Object System.Net.Sockets.UdpClient; $udpClient.Connect("116.xxx.xxx.xxx", [number of your port]); $bytes = [Text.Encoding]::ASCII.GetBytes($message); $udpClient.Send($bytes, $bytes.Length); $udpClient.Close()

From Linux
echo "Test UDP" | nc -u -w1 116.xxx.xxx.xxx [number of your port]

where "116.xxx.xxx.xxx" is the public global IPv4 at server-level that you have, and [number of your port] will be the UDP-exclusive port number, which must be the same exact port number your process is listening on the VPS, and it's also recommended to be the same exact port number of your outbound UDP port range, to simplify things

If you recieve "Test UDP" on your VPS, everything is working.

We cannot guarantee the "nc" package under RHEL-based systems is the technical equivalent of the netcat-openbsd available at Debian and Ubuntu (wasn't tested), also because of their habit of backtracking changes, but we can assure the netcat-traditional package is not suitable for this task, because it doesn't support the -6 parameter for IPv6 listening.