4 ms·

>BitTorrent http://www.bittorrent.com/help/manual/chapter0203 http://www.bittorrent.com/help/manual/chapter0203 BitTorrent users who do not have port forwardi

>BitTorrent http://www.bittorrent.com/help/manual/chapter0203 http://www.bittorrent.com/help/manual/chapter0203 BitTorrent users who do not have port forwarding enabled do not communicate with each other. BitTorrent has a highly technical user base and chances are good that someone with the file you want actually has enabled port forwarding or is running a server in a datacenter (seedbox). That wouldn't work for mainstream messaging. >desktop Skype Firewalled Skype users do not talk directly to each other, they talk to Supernodes (servers) running on nodes that do have port forwarding / no firewall. Conscripting random PCs as servers drew public outrage and Microsoft eventually (citing scalability and reliability) made all the Supernodes server-class hardware sitting in Microsoft datacenters. >SIP VoIP phones If you are in an office and can receive calls on a SIP phone, it's because your organization runs (or pays someone to run) a central server called a gateway, usually but not always as part of a PBX. The most common open-source PBX is called Asterisk. People who call you from the outside are connecting to your phone, but to your organization's gateway. Your gateway then sits on a (V)LAN with your phone, or your phone maintains an outgoing connection to it. If my friend has her router configured but I do not, then (absent a gateway) I could call her but she couldn't call me. So you use central gateways Many VoIP phones come with VPN clients so that they can behave like peers to phones within the organization if deployed at employees' homes or in certain branch office configurations where bridging is not already in place. In this case, you still have centralization at the level of the VPN server.

api 12y ago
It's very weird that the BitTorrent docs say that, since I have seen different in practice, both Transmission and uTorrent support uTP, a tcp-like udp protocol that can traverse NAT. There is something like a standard. Few products use this standard by name, but many use it's techniques. http://en.m.wikipedia.org/wiki/STUN http://en.m.wikipedia.org/wiki/STUN So you are mistaken. Either that or for years I have suffered from packet hallucinations and clinical delusions of NAT traversal, cause I am literally watching it happen now. :) Here's some scenarios I have recently personally tested using simple UDP hole punching: * Institutional/enterprise NAT: two universities, one large corporation, one hotel * Double NAT with virtual machine behind physical behind NAT * Double NAT on a cellular connection (tethering) * NAT behind "privacy tunnel" VPN * Several consumer cable modem routers But it certainly is hard. It involves either complex or clever solutions, and to field a reliable product there must be relay fallback for the percentage of users who cannot traverse. (Since it's a small percentage it's virtually free to provide that.) That fallback must be fast and transparent to the user, and done in a way that is maximally compatible. I do TCP over port 443, which is almost always open, and have considered literal HTTP encapsulation over 80 as a second fallback that would work even through proxies. It can be done. Like I said, I have a system in the field now seeing 90-95% success rate with direct connectivity. No firewall config is needed, nor are users conscripted to act as relays. Like I said elsewhere on the thread: coping with the limitations of mobile is harder than dealing with NAT. I think that can be done too but there are still question marks, especially around iOS. Idea is to do all the super hard stuff once and then make it available in a very nice SDK that's also backed by a service with enterprise SLA, support, etc. (All cheaper than handling all bandwidth yourself of course, not to mention lower latencies for most users.) Hide all the complexity from both the user and developer and offer something professional. There are P2P libraries out there but none that are professional, polished, or backed. Target would probably be games, video, and other more demanding applications. I was just using SnapChat as a simple example but it's probably not the best one.
- superuser2 12y ago
  Interesting! I didn't realize so much of the NAT in place was full-cone. I thought it would all be symmetric. Non-symmetric NAT seems like a major security vulnerability, though. Couldn't I hijack any application whose eAddr:Port I knew simply be replying faster than the actual server? My traffic would appear to the client as identical to traffic from the actual server, no? Why do people deploy NAT that is not symmetric? Also, why couldn't Skype and BitTorrent simply use those techniques rather than relying on certain users to serve all the firewalled traffic? What is the demographic of your product where you're seeing a 90-95% success rate?
  - api 12y ago
    Linux, BSD, and most home routers are full cone. Apparently my cellular tethering feature is also full cone. Most importantly, every carrier-grade NAT I've seen (used on cellular nets and by some ISPs) is full cone. It's actually hard for me to test symmetric, since I don't have access to any networks nor have I found any that are symmetric. I have to simulate it on a test net with a special iptables config. Symmetric seems rare in the field, though it also seems most common in "enterprise" environments. My guess is that some major vendor like Cisco or Juniper sells symmetric NAT engines. All the users I've heard from who are behind symmetric are in large corporate or university networks. I've never even heard of a symmetric NAT consumer device. My guess is that full cone is most common because (a) it's simpler at the router and (b) it guarantees maximum compatibility. As I said: NAT traversal is a "de facto standard" used by a number of products. If those products don't work or are slower than molasses, users complain that "the Internet is broken." That sword cuts both ways. Vendors probably found that fewer complaints about "broken Internet" came when they went to full cone NAT. There are ways of traversing symmetric NAT, but none of them can be guaranteed to be successful the way full cone hole punching is, and some might look like a port scan or an attack and set off alarm bells. They include psychotic techniques like: * Proposing that the symmetric NAT box assigns ports sequentially and trying the next few (may look like a port scan). * Proposing that the symmetric NAT box may assign ports using the standard K&R linear congruential rand() function, inductively determining the PRNG state, and guessing the next ports by extrapolating the next sequence numbers (also may look like a port scan). * Impersonating a DNS server and sending a packet that refers to the NAT-t target as if it were a delegated DNS server (apparently some symmetric NATs have DPI logic to make stuff like this work, which can be exploited... but this can look like an attack). * Having the host behind symmetric NAT probe its own exterior ports 1024-65535 and determine the port assignment schema by doing NAT-t against itself (looks like an attack). * Impersonating IPSec and triggering "make IPSec VPNs work" DPI logic in the router (absolutely requires 'root' on the host and SOCK_RAW, which Windows doesn't have). * Various "Jackass stunts" with ICMP that can set of IDS systems. I would not do any of that stuff in a Real Product(tm), but it's all cool in a cool hack kind of way. Nevertheless, the statistical rarity of symmetric means that just relaying peoples' traffic for free is basically... free... at least within reason. As far as I know BitTorrent does use hole punching, but maybe not in the official bittorrent.com client. Take a look at Transmission and uTorrent. They use uTP, which is basically an application mode TCP stack that runs over UDP, and they pair it with hole punching. I have used them many times behind NAT and they work... you'll notice that if you're behind NAT nearly all of your peer links are uTP instead of TCP. I don't know about Skype. I know they use servers only on mobile, but I don't know what their desktop client does. Skype is super closed and obfuscated, so only way to tell there is to fire up a sniffer. My demographic is mostly consumers and small businesses, so it's going to be mostly consumer routers and hotels and such. I do see some symmetric with .edu users. Product is here: https://www.zerotier.com/ https://www.zerotier.com/ If it can't do NAT-t, it will relay UDP (for free). If it can't do UDP at all it will fall back to relayed TCP over port 443 that looks like TLS. It works just about everywhere. Being able to NAT-t just makes it run a lot faster. I'm considering taking the engine behind this and SDKifying it and then trying to make it play nice on mobile. The latter is IMHO much harder than dealing with NAT, and if I could do it would make it a first-in-class product. But I don't want to spend the time if nobody wants such a thing.

api 12y ago

It's very weird that the BitTorrent docs say that, since I have seen different in practice, both Transmission and uTorrent support uTP, a tcp-like udp protocol that can traverse NAT. There is something like a standard. Few products use this standard by name, but many use it's techniques. http://en.m.wikipedia.org/wiki/STUN http://en.m.wikipedia.org/wiki/STUN So you are mistaken. Either that or for years I have suffered from packet hallucinations and clinical delusions of NAT traversal, cause I am literally watching it happen now. :) Here's some scenarios I have recently personally tested using simple UDP hole punching: * Institutional/enterprise NAT: two universities, one large corporation, one hotel * Double NAT with virtual machine behind physical behind NAT * Double NAT on a cellular connection (tethering) * NAT behind "privacy tunnel" VPN * Several consumer cable modem routers But it certainly is hard. It involves either complex or clever solutions, and to field a reliable product there must be relay fallback for the percentage of users who cannot traverse. (Since it's a small percentage it's virtually free to provide that.) That fallback must be fast and transparent to the user, and done in a way that is maximally compatible. I do TCP over port 443, which is almost always open, and have considered literal HTTP encapsulation over 80 as a second fallback that would work even through proxies. It can be done. Like I said, I have a system in the field now seeing 90-95% success rate with direct connectivity. No firewall config is needed, nor are users conscripted to act as relays. Like I said elsewhere on the thread: coping with the limitations of mobile is harder than dealing with NAT. I think that can be done too but there are still question marks, especially around iOS. Idea is to do all the super hard stuff once and then make it available in a very nice SDK that's also backed by a service with enterprise SLA, support, etc. (All cheaper than handling all bandwidth yourself of course, not to mention lower latencies for most users.) Hide all the complexity from both the user and developer and offer something professional. There are P2P libraries out there but none that are professional, polished, or backed. Target would probably be games, video, and other more demanding applications. I was just using SnapChat as a simple example but it's probably not the best one.

superuser2 12y ago
Interesting! I didn't realize so much of the NAT in place was full-cone. I thought it would all be symmetric. Non-symmetric NAT seems like a major security vulnerability, though. Couldn't I hijack any application whose eAddr:Port I knew simply be replying faster than the actual server? My traffic would appear to the client as identical to traffic from the actual server, no? Why do people deploy NAT that is not symmetric? Also, why couldn't Skype and BitTorrent simply use those techniques rather than relying on certain users to serve all the firewalled traffic? What is the demographic of your product where you're seeing a 90-95% success rate?
- api 12y ago
  Linux, BSD, and most home routers are full cone. Apparently my cellular tethering feature is also full cone. Most importantly, every carrier-grade NAT I've seen (used on cellular nets and by some ISPs) is full cone. It's actually hard for me to test symmetric, since I don't have access to any networks nor have I found any that are symmetric. I have to simulate it on a test net with a special iptables config. Symmetric seems rare in the field, though it also seems most common in "enterprise" environments. My guess is that some major vendor like Cisco or Juniper sells symmetric NAT engines. All the users I've heard from who are behind symmetric are in large corporate or university networks. I've never even heard of a symmetric NAT consumer device. My guess is that full cone is most common because (a) it's simpler at the router and (b) it guarantees maximum compatibility. As I said: NAT traversal is a "de facto standard" used by a number of products. If those products don't work or are slower than molasses, users complain that "the Internet is broken." That sword cuts both ways. Vendors probably found that fewer complaints about "broken Internet" came when they went to full cone NAT. There are ways of traversing symmetric NAT, but none of them can be guaranteed to be successful the way full cone hole punching is, and some might look like a port scan or an attack and set off alarm bells. They include psychotic techniques like: * Proposing that the symmetric NAT box assigns ports sequentially and trying the next few (may look like a port scan). * Proposing that the symmetric NAT box may assign ports using the standard K&R linear congruential rand() function, inductively determining the PRNG state, and guessing the next ports by extrapolating the next sequence numbers (also may look like a port scan). * Impersonating a DNS server and sending a packet that refers to the NAT-t target as if it were a delegated DNS server (apparently some symmetric NATs have DPI logic to make stuff like this work, which can be exploited... but this can look like an attack). * Having the host behind symmetric NAT probe its own exterior ports 1024-65535 and determine the port assignment schema by doing NAT-t against itself (looks like an attack). * Impersonating IPSec and triggering "make IPSec VPNs work" DPI logic in the router (absolutely requires 'root' on the host and SOCK_RAW, which Windows doesn't have). * Various "Jackass stunts" with ICMP that can set of IDS systems. I would not do any of that stuff in a Real Product(tm), but it's all cool in a cool hack kind of way. Nevertheless, the statistical rarity of symmetric means that just relaying peoples' traffic for free is basically... free... at least within reason. As far as I know BitTorrent does use hole punching, but maybe not in the official bittorrent.com client. Take a look at Transmission and uTorrent. They use uTP, which is basically an application mode TCP stack that runs over UDP, and they pair it with hole punching. I have used them many times behind NAT and they work... you'll notice that if you're behind NAT nearly all of your peer links are uTP instead of TCP. I don't know about Skype. I know they use servers only on mobile, but I don't know what their desktop client does. Skype is super closed and obfuscated, so only way to tell there is to fire up a sniffer. My demographic is mostly consumers and small businesses, so it's going to be mostly consumer routers and hotels and such. I do see some symmetric with .edu users. Product is here: https://www.zerotier.com/ https://www.zerotier.com/ If it can't do NAT-t, it will relay UDP (for free). If it can't do UDP at all it will fall back to relayed TCP over port 443 that looks like TLS. It works just about everywhere. Being able to NAT-t just makes it run a lot faster. I'm considering taking the engine behind this and SDKifying it and then trying to make it play nice on mobile. The latter is IMHO much harder than dealing with NAT, and if I could do it would make it a first-in-class product. But I don't want to spend the time if nobody wants such a thing.