Remote desktop connection over internet without port forwarding

I dont think you can tunnel over RDP, however if you were to rdp to the server and then initiate a ssh tunnel back to your client your machines would be connected by ssh. You can forward both remote and local ports so you could do it so that it was all in reverse

EDIT

If you install a ssh server on your client pc and set it to accept ssh connections on port 443 then you can connect to the ssh server (your client) from your server (using ssh client connection) and you wont need to open any ports (443 should be open for https)

That's great, but what about when someone doesn't have access to a physical router

Generally all Internet traffic traverses multiple ISP and carrier-grade routers, none of which are usually physically accessible by the users.

Your fourth paragraph is a bit unclear. I think you don't understand how NAT works.

The reason why port forwarding is needed is due to NAT. NAT hides multiple systems behind 1 IP address. You can only talk to this 1 publicly visible IP address. If you want to get to anything behind this IP, you must go through this IP. You do not have a choice. Without the port forwarding, the NAT-enabled router does not know which machine behind it to send unsolicited incoming traffic to and will assume you are trying to talk to the router itself.

If you are talking about a program that accepts requests on behalf of a client behind it, the name for that is "proxy" and you can certainly do that. A router is a logical, but not necessarily best, place to have that running and accessible. There are proxies for many protocols, HTTP, SIP, etc.

When the first one receives the request to form an actual connection, it accepts

This would never happen. The "first one" is behind a NAT router, the NAT router receives the request at first, not anyone behind the router.

IPv6 fixes this by providing a large enough address space that NAT isn't necessary to preserve addresses.

There is no special protocol involved in NAT, it's all TCP/IP.

What is different from a standard non-NAT router is that, from the outside, nodes only see and know about the single public IP. As far as they know from a TCP/IP level, there is only one system on that IP sending out many requests. If nothing like Javascript, a proxy, or other application-level traffic is snitching on someone's private IP, then the outside cannot know the private IP.

The NAT facility must keep track of who initiated what connections (only behind it) so it can forward incoming traffic destined for itself to the appropriate host. (This is possible because each outgoing connection has a unique random source port, so it can simply map source ports to LAN destination addresses).

I think there was a program that tried to work the way you are saying by sending a NAT router an out-of-sequence TCP packet (the sequence is SYN, ACK, SYN-ACK) which may fool it. I have also heard of NAT routers that erroneously allow incoming TCP connections on ports that UDP traffic is sent.

But a good NAT implementation is going to check its internal tables for mapped connections, and drop the packet if it doesn't match anything it has seen from the inside. You can't count on implementation flaws to provide a reliable solution in the manner you are asking.