Is pwnat still an applicable solution

问题

I need a solution for NAT traversal to transmit RDP data across the internet. I came across the following tool and it's really amazing - pwnat.

I have tried it with the two different machines behind different router, but i am unable to make it work as explained in the above link. So is pwnat still working and if yes what could I have done wrong? It would be very helpful for me.

Note: I am using a Windows machine for testing and downloaded the Windows version from the following link:

http://www.sumitgupta.net/pwnat-windows-complied-version/

回答1:

No.
I assume you know how it worked:
the server sent ICMP echo request packets to the fixed address(for example, 1.2.3.4) where no echo replies wouldn't be returned from, the client, pretending to be a hop on the Internet, sent an ICMP Time Exceeded packet to the server, expected the NAT in the front of the server to forward the ICMP time exceeded message to the server.

The picture above is from the homepage of pwnat, it's on the premise that client is not behind NAT and the original payload in time exceeded message is typically not checked by NAT implementations. If both client and server are behind NAT like this,

=========================================================================================
| CLIENT  | <---> |  NAT-C  | <---> { internet } <---> |  NAT-S  | <---> | SERVER |
=========================================================================================

It rarely works nowadays mainly for 2 reasons below:

1. When the server sends ICMP echo request packets to the fixed address, according to RFC 3022, the identifier field in ICMP echo request header will be uniquely mapped to a query identifier of the registered IP address by NAT-S so that it can route future ICMP Echo Replies with the same query ID to the sender, so ICMP header in ICMP Query packets must be modified to replace the query ID and ICMP header checksum. RFC 3022 ICMP error packet modifications section:

   In a NAPT setup, if the IP message embedded within ICMP happens to be a TCP, UDP or ICMP Query packet, you will also need to modify the appropriate TU port number within the TCP/UDP header or the Query Identifier field in the ICMP Query header.

   But the client doesn't know the external query ID(the code in pwnat use 0 as the identifier of original request), it sends an ICMP Time Exceeded packet to the server, even if the packet can reach NAT-S in front of the server, NAT-S can't find the active mapping for the embedded packet, most of NAT implementations will drop it.

2. Moreover, according to rfc 5508, when the NAT-C receives the ICMP Error packet from the Private Realm, NAT-C uses the packet embedded within the ICMP Error message (i.e., the IP packet from the client to the server) to look up the NAT Session to which the embedded packet belongs. If NAT-C does not have an active mapping for the embedded packet, the NAT-C SHOULD silently drop the ICMP Error packet. It means the ICMP Time Exceeded packet from the client wouldn't arrive at NAT-S.

So pwnat only works with basic NAT devices(rfc 1631 describes) which do simple address translation, won't work with any NAPT device which has robust NAPT implementation. And This paper does mention this problem.

来源：https://stackoverflow.com/questions/22985793/is-pwnat-still-an-applicable-solution