UDP hole punching: new datagram from same local IP and port doesn't re-use external port
-
I am experimenting with UDP hole punching, as illustrated in this diagram on Wikipedia.
UDP hole punching works because, as I understand it, the router adds an entry to its translation table with ip:port, external ip:port (source). As long as the same local ip:port are used, the external port should also stay the same. The external port is discovered using a STUN server. Then, from the same source port, both clients send a UDP packet to each other to 'update' the translation table entry with a new destination address. Now, both clients can communicate, because they have an entry to accept each other's traffic.
However, while experimenting with this I discovered that pfSense seems to use a new random external port for every UDP datagram, even when it has the same source address and port number (but a different destination). This was found by looking at the state table and seeing many entries with the same local source, using a different external source each time. Captured pcaps also show the same.
Is it expected that pfSense creates a new NAT entry when the destination changes, but the source remains the same? Doesn't this break UDP hole punching?
-
Apparently this is because pfSense (pf) uses Symmetric NAT. This makes hole punching impossible.