X
X

Select Your Currency

$ US Dollar Euro £ British Pound
X
X

Select Your Currency

$ US Dollar Euro £ British Pound

Knowledge Base

HomepageKnowledge BaseLinux - MultiVPS IPv6+IPv4ICMP - IPv4 Pings And NAT IPv4 Port...

ICMP - IPv4 Pings And NAT IPv4 Port Range Testing

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 must be dual-stack (i.e. support IPv4 and IPv6 connectivity);
- Must be able to listen on IPv6 and IPv4 address formats (i.e. [::]::0 and 0.0.0.0/0, the catch-all addresses for IPv6 and IPv4);
Specific for UDP usage only: must 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 the NAT port calculators we have does not need to be provided to the application on the VPS. It is enough to have the application map to listen to catch-all addresses. Traffic sent at a given port range will be automatically split by our NAT bridging and, whenever it is not possible to reach through the IPv6 address directly, it will be routed through the IPv4 IP automatically. 

Test examples for TCP and UDP

Remember: ports are always pre-opened automatically at the given range for you. You don't need to send us a ticket.

Example for TCP: attempt to change /etc/ssh/sshd_config to one port within the predicted port range 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 port you've just put at the SSH service, and it will work flawlessly.

This was tested on a MobaXterm client under Windows and an IPv4-only connection, with socat as the underlying technology, in 29-10-2024, under AlmaLinux 9.4 and Debian 12.

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 ALSO the same exact port number of your UDP port range.

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

This was tested in 29-10-2024, on a MobaXterm client under Windows and an IPv4-only access, through a VPS with Debian 12. Socat is also the underlying technology.

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. 

Regarding ICMP connectivity over IPv4

Outbound ICMP IPv4 IP pinging on MultiVPS, outside of the allocated port range, is not supported, due to a technical specific - the executed DNS64 implementation, at both the main server and the public service fallback. The packet header is changed on the process, and the DNS64 needs to translate the request to an adequate domain name first, meaning that it's not recognisable IP-to-IP.

Pinging an IPv4 is, therefore, supported if that IPv4 is contained as a domain name. If you want to discover which domain, subdomain or Reverse DNS record associated with a given IPv4 from the command line, click here.

ICMP over direct IPv6-to-IPv6 is always supported in all protocols regardless of pinging to an IP or to a domain. 

If you want to calculate IPv4 NAT ports on your VPS, click here.

Can't find the information you are looking for?

Create a Support Ticket
Did you find it useful?
(2647 times viewed / 2 people found it helpful)

Powered by WISECP
Top