Are there security measures against udp hole punching? [closed] - networking

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I want to establish an UDP communication between two peers, say Alice and Bob. Alice is behind a port restricted cone NAT (so that the same internal port gets mapped to the same external port even if the destination is changed), while Bob is behind a symmetric NAT (which means that the external port will change every time a new destination is chosen regardless of the internal port, thus making the external port unpredictable). I have a server in between and I want to make an UDP hole punch.
I implemented the following strategy:
Bob opens a large number of ports and from all of them sends a packet to Alice's external port (he gets to know if through the server).
Alice sends packets to Bob's NAT at random ports until the connection is established.
Having two NATs of those types at hand, I did some experiments. Bob opens 32 ports, and Alice sends 64 packets every 0.1 seconds. The connection is usually established within 1 or 2 seconds, which is more than suitable for my needs.
However, I was wondering if I could get in trouble with some strict NAT routers or firewalls. On example, could it happen that a router won't allow an internal peer to open 32 ports? Or (and this sounds somehow more likely) could it happen that a router that sees a lot of packets incoming on random ports that get dropped will blacklist the ip and drop all its packets for some time? I read that sometimes this could happen in case of a DoS attack but my packet rate is something like 4 to 6 orders of magnitude lighter than a DoS attack.
I am asking about reasonable network configuration: I am pretty sure that in principle it is possible to setup a firewall to behave in that way. I will be targeting mainly users that lie behind standard home connections, so my main target is common internet providers that use NATs.

Answer 1

It's an interesting question.
First of all, I'm not sure anyone has the exact answer you're looking for. Different networks use different equipment and different configuration. Two ISPs can use ten different vendors for their routers, firewalls, NATs, intrusion detection equipment, DPI equipment etc; not to mention the number of possible configurations all of this equipment has.
And while commercial and corporate networks are bad enough, home networks are even worse. Here there are even more vendors selling modems, NAT boxes, and various software that affects network connectivity (such as firewalls and anti-viruses). All of which is in the hands of users who aren't technically savvy that leave it with the default settings, or worse.
Moreover, in both home and commercial networks there might be several layers of NAT. I know of a company that has a NAT for each lab (to isolate it from other labs and the R&D network). Each lab is then connected to the R&D NAT (to isolate it from other departments), which in turn is connected to the company-wide NAT, which, by the way, is also heavily firewalled. Add to that a possible ISP-level (carrier grade) NAT, and you're looking at up to 4 layers of NAT. Hopefully this is an extreme example, but two layers of NAT are quite common nowadays with home NAT and carrier grade NAT.
Given that, how likely it is for a random network to consider this behavior suspicious and limit it? Frankly, I don't know for sure and I don't think anyone else does with a high degree of certainty.
Despite that, my educated guess is that sane default configurations of communication equipment (NATs, routers, etc) should not block such behavior. After all, many applications open several ports; not to mention the fact that the NAT has no way of knowing that the IP sending this traffic isn't itself a NAT device with dozens of computers behind it - each of them with several open ports.
I also guess that simple firewalls should be fine with it as long as UDP itself isn't blocked, and the usage of the various ports is allowed. Firewalls that attempt to block port-scanning, and anti-DDoS equipment, however, might pose a problem as this traffic might seem suspicious to it, so it might depend on the configuration/implementation details of such equipment and software. So unfortunately, the only way to tell how your strategy will behave in the real world it to try it out on a variety of different networks.
Second, I'd like to say a few words about your hole punching strategy. If both Alice and Bob have a shared server, and Alice is behind a cone NAT, I don't see the point in your strategy. A cone NAT is the simplest NAT to overcome. If you want Alice to be able to connect to Bob (which is tricky since he's behind a symmetric NAT), all you really have to do is to get Bob to connect to Alice upon Alice's request.
To do that, both Alice and Bob should always have a long-lasting TCP or UDP connection to the server. The connection shouldn't carry any data for the most part, and should be just kept alive once in a while.
When Alice wants to connect to Bob, it just opens a port (say port X), and connects from that port to the server. The server sees Alice's external port that corresponds to port X - say port Y. At this point, Alice informs the server that she would like Bob to connect to her. Since Bob is connected to the same server, the server informs Bob that it should connect to Alice at at port Y. This should establish a connection between them without the need for any guessing.