supercoe wrote:The repeater is just a relay and has nothing to do with encryption, if you encrypt the traffic it will still relay it.
This is clear to me and my point was not about encryption but about authentication. Authentication and encryption are two different aspects. I was very surpised to have my WinVNC service configured with "MS Logon" authentication and found it to connect without any type of authentication when connecting to the given ID on the repeater. I see this has been discussed already and to me it's clearly an issue/bug while UVNC developers seem to think that authentication is not required in repeater mode.
Anyway this is getting off-topic since this topic is about nat2nat only. There seems to be working nat2nat tunneling utilities but I couldn't find any code on CVS/SVN as well ass no code for the NAT helper service.
supercoe wrote:You may want to look into my ChunkVNC project as it allows you to easily setup the repeater with encryption and the ability to reboot (after installing as a service).
I will perhaps have a look at it but it looks like it also does not use nat2nat but traffic relaying.
I also found an interesting project on SF: http://n2nc.sourceforge.net/reference/index.html
It seems to do basically everything I am looking for. I will have a closer look here as well. If I am able to find or implement a tunneling service for NAT2NAT connectivity then this would be entirely fine:
- Server starts nat2nat connectivity tool
- nat2nat connects to helper service
- helper service provides unique ID. Client might ask for preferred ID. This way it could store its ID locally. Just similar to what DHCP server/clients do.
- Client stars nat2nat connectivity tool
- Client will either know the server nat2nat unique ID or ask for it on different channel (via mail, phone or other channel)
- Client asks to be connected to known nat2nat helper ID
- Helper tool provides public IP addresses of both parties to each other. Depending on NAT type additional information might be required. Maybe discovery protocol like STUN could be used to detect NAT type.
- Clients start sending UDP packages to each other trying to establish reliable tunnel (perhaps UDT based)
- Clients also try to keep the tunnel up (keep-alive packages on idle). On disconnect/timeout the tunnel shall be auto-re-established (e.g. router reboot, IP change) via NAT helper service
The NAT helper service does not really need a database because in case of NAT helper service connectivity loss clients shall re-connect and re-register desired ID. Connection between client 1 and NAT helper service needs to be persistent in order to allow the NAT helper service to respond to client 1 if client 2 is known (on connect). Using TCP this would require severe amount of TCP sockets (one for each client) to be blocked. Alternatively also for initial NAT helper announcement UDP might be used. Keep-alive packages (on UDP) might be sent to NAT helper in order to assure the NAT-table entry does not get wiped out due to idle timeout so NAT helper service can send connection information when client 2 connects.