NAT-to-NAT direct connections with no proxy/STUN needed
1–10 of 37 posts
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#2very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#3very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
Very but as with the example he is giving, this is very useful technology for video games where hosts and clients are regularly behind NAT. UPNP has made this somewhat better but it's still no where near perfect.
If i'm not mistaken, much of the UDP punch-through technology was invented by Skype. However, skype still relies on a proxy server that every client connects to. It needs that so that the client can prepare the router to let data through from a certain client IP. These guys here found a ridiculously clever way of skipping this step which makes true P2P with both end points behind NAT possible and even easy to implement.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#4very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
All of these techniques could be prevented if you knew about them.
Yet I wouldn't be surprised if the specific IP address wasn't customizable eventually when you control both sides.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#5very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
On most firewalls this should be trivial. On an Cisco ASA:
access-list BLOCK_TIMEEXCEEDED deny icmp any any time-exceeded
(iirc) and then apply the acl. You should block all hosts as any could be chosen by the person. They could change 3.3.3.3 to any other IP.
NAT is not a security mechanism and does not ensure your hosts are protected. Denying tunneling of any kind is difficult as there are tunnels over most protocols. I'm not aware of any perfect prevention or detection technique, but detection could in the case of a moderate amount of data transit could possibly be done via analysis of netflow records.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#6Cheat sheet version: one side sends packets to a bogus IP, the other side sends ICMP TTL Exceeded packets back. Some NATs will pass the TTL Exceeded packets because that's how traceroute works; the ICMP packets are indistinguishable from "real" traceroute responses. Once both sides know each other's IP addresses, they open a tunnel by simultaneously talking outbound UDP to each other.
This is a clever trick for home NATs, but most corporate networks are doing more than NAT'ing; they're dropping everything but DNS and HTTP from a proxy.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#7very clever. how hard is it for the paranoid IT guy to block ICMP time exceeded packets inbound for 3.3.3.3 but not for other hosts, to stop servers from discovering clients?
Better just to block all ICMP TTL exceeded packets, breaking traceroute entirely. Normal users don't use it that much. Traceroute sucks; it's clunky, slow, and unreliable. Network people need it (and they can carve exceptions for themselves), but end-users don't.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#8This looks to be two things: a way of discovering ips and communicating them without STUN and a simple nat traversal using UDP. Th first is a little clever but not super interesting as signalling channels are a dime a dozen. The second is essentially a small subset of ICE and will fail if anyone remaps ports.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#9Ok, so ICMP is easy to turn off. But why couldn't this technique be done over UDP or TCP? The server could send a UDP packet to a known "fake" address and the client could spoof its source address to penetrate the nat.
Re: NAT-to-NAT direct connections with no proxy/STUN needed
#10This looks to be two things: a way of discovering ips and communicating them without STUN and a simple nat traversal using UDP. Th first is a little clever but not super interesting as signalling channels are a dime a dozen. The second is essentially a small subset of ICE and will fail if anyone remaps ports.
For something similar check out scottlu's FWD — http://www.scottlu.com/2008/05/fwd-tool-for-peer-to-peer-por.... It uses xmpp as the signalling channel and the ICE implementation from libjingle. This is the P2P stack we built for Google Talk several years ago. If you get this stuff right you can establish a direct connection when both parties aren't behind a full cone NAT — 90+% of the time.