Static port nuance?

  • I was unable to get incoming VOIP calls working.  The VSP tech said that this was due to the source port number for SIP not being 5060.  After googling around, I found other pfsense users who had had the same issue, and switched to manual outbound NAT, checking the "static port" checkbox.  I did that, and all is well.  Here is my (somewhat paranoid) question: TCP/UDP require the 4-tuple to be unique.  In a home NAT setup, the source IP will by definition not be unique for hosts behind the NAT gateway.  So, if you have two hosts behind pfsense going to the same remote host with the same destination port number, this could (in theory) cause a conflict.  It is not an issue for SIP, since I have only one host behind pfsense using SIP.  I guess there is a miniscule chance that two hosts behind my pfsense gateway could try to connect to the same remote host (say a webserver), so the destination IP and port will be the same, as will the source IP.  If the two LAN hosts happen to pick the same ephemeral port number, it seems to me, one of them will not be allowed to connect, by the pfsense gateway (either that, or something bad will happen.)  I understand this is a very unlikely event, but I am wondering if it is worth fixing this by replacing my current rule:

    allow proto=any any any => any any "static=yes"


    allow proto=udp any 5060 => any 5060 "static=yes"
    allow proto=any any any => any any "static=no"

    What do y'all think?

  • This would interest me as well.
    I asked about the same question like 2 years ago but didn't get a conclusive answer.

    From personal testing:
    The first connection will be created.
    The second connection will NOT be created.

    However this was with version 1.0
    I dont know if this behaviour changed with a newer version.

  • Hmmm, thanks, sounds like you already have my answer :)  I think I will go with the 2-rule approach.

  • I ended up adding the extra rule.  I confirmed that port 5060 is still unmolested but other host&port combos are having the source port rewritten.

  • I ended up going back to the 1-rule "static port for all" setting.  I had forgotten that there are a number of UDP ports for the audio, and I want them to go out unmolested too.  This seemed like a lot of hassle to avoid a problem which is incredibly unlikely to occur (e.g. a source port collision).

Log in to reply