I'm going to update this topic with the "temporary" results obtained.

Indeed, thanks to the UDP HOLE PUNCHING technique, I was able to connect a VPN server and client without needing to open ports, but there's a BUT.

As you may know, lately ISPs have started using CG-NAT, which is a HUGE SCAM, because the UDP HOLE PUNCHING technique doesn't work under CG-NAT because it does a PORT RANDOMIZE and then the Source Port of the VPN server changes with each connection it makes, for example.

If I have a PC with the VPN server on port 1194 UDP and behind a CG-NAT, when sending packets to another computer, that 1194 probably leaves the CG-NAT through another port, which WE DON'T KNOW because it applies a PORT RANDOMIZE and maybe it ends up going out through 55123.

I've tried using a 3rd server where the "vpn server" sends some packets to be able to discover the SRC PORT behind the CG-NAT, but of course, that assignment waiting for a response is only for that 3rd server, to which the client tries to connect through that hole, the CG-NAT blocks the connection since it wasn't the original recipient, that's what HOLE PUNCHING is about.

Do you have any idea or know of any procedure to "jump" over this barrier? I know it's possible to ask the company to take us out of CG-NAT, but that's not a valid option because in the end, the one who will run the VPN server may even be behind a shared mobile connection, where there's no way to open/redirect ports either.

I know what I'm asking for is quite complex, but you never know where one might find the solution!

Best regards.

P.D: @krampak I mention you just in case