Den mån 16 maj 2022 kl 10:35 skrev Elias Carter <[email protected]>: > OpenBSD/PF defaults to randomizing the source port whereas > Linux/IPTables defaults to trying to keep the source port. > > I have found that preserving the source port if possible works better > out of the box when hosting publicly accessable UDP applications > within a private network. Randomizing the source port of UDP replies > will most likely cause the reply to be blocked by the requestor's > network. Of course you can create a PF rule for your UDP application > with `static-port`, but it requires a more in depth understanding of > how NAT and UDP applications interact to get it to work. > > One possible advantage of randomizing source ports is that it helps > prevent fingerprinting of the devices behind the NAT? Are there any > other reasons?
I don't know the original thought, but if the source UDP port has strict requirements, then you should really handle it strictly and not just "bet" on the first consumer to have it work, and the second,third and so on will fail. Lets take old IKEv1 as an example, it wants to make the phase 1 negotiations to UDP destination port 500, while some IKE daemons implement a check that the source UDP port is also 500. In case the NAT tries to use the same port, the first client to ipsec against a remote host will succeed, but a second client running at the same time would get a source port from the "pool" of random UDP ports, and hence stop working. I think this would cause even bigger issues than having both get random ports to begin with, so that you can act on it immediately (setting NAT-T or something else in this case) and not when the service starts to become used by more than your first test laptop. While I can see the appeal of trying, it still means the service is not really made to work for more than one client from that same NAT pool. Might be fine if you aim for "bill and bob and jenny who works from home" coming in from separate home broadband connections or whatever, but it quickly breaks down for any larger cases than that. It is rather uncommon for UDP services to make demands of the source port and for them to have expectations about the ports, so when this happens I think one needs to see and act on it right away, and that would not happen if it "sometimes work" based on luck or timing or "I was first into the office so I got todays slot at 08.01 to 08.02 before the udp session times out in the fw". -- May the most significant bit of your life be positive.
