Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    UDP hole punching: new datagram from same local IP and port doesn't re-use external port

    Scheduled Pinned Locked Moved NAT
    2 Posts 1 Posters 309 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      derkades
      last edited by derkades

      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?

      D 1 Reply Last reply Reply Quote 0
      • D
        derkades @derkades
        last edited by

        Apparently this is because pfSense (pf) uses Symmetric NAT. This makes hole punching impossible.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.