maikcat wrote
so a 3rd party can connect to an open session between a client and server by using clients (router)source port?
No, because the 3rd party will be coming from a different source IP, the NAT table should not pass it.
shouldnt the clients router expecting packets from the servers ip?(destined to original scr port initiated by the client)
yes, but in our example there are 2 clients connecting to eachother ptp style. I think you're basically just asking if IP matters... Yes it does.
Traffic wrote
Sounds like a lot of work .. that will go nowhere .. for no good reason ..
But I have been proven wrong before ..
https://en.wikipedia.org/wiki/NAT_traversal
Give this a read, and remember that with what I'm talking about the clients already have a secure channel to eachother through the server, so they can agree on anything they want, such as ports, IPs, proto, mtu, etc. This removes the need for a stun server like most other client-to-client communications (like voip) would need.
I also think this would be a lot of work, that will go nowhere. But only because I do not think anybody will want to actually do the work. The idea is solid but without someone to implement it that does not actually matter.
Your point that there are different types of NAT is valid, but there are also different types of hole punching, and with our server to handle the back channel to the other client we have an advantage over other projects who want to hole punch.
I also feel the need to point out that ipv6 should eliminate the need to traverse nat, if both clients are ipv6 enabled. also this will not work with symmetric nat, but it should not be too difficult to detect that and simply mark the client as unable to make direct connections.
https://en.wikipedia.org/wiki/STUN
Not all voip clients work with STUN, but those who do should be able to be supported by openvpn for this idea. TURN is what voip users who cannot use stun would use, but that is effectively what our current client-to-client code does.
