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

    NAT Port Forwarding Issue with Pfsense 2.2.2

    Scheduled Pinned Locked Moved NAT
    4 Posts 2 Posters 1.6k 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.
    • P
      peterkrautle
      last edited by

      Hi There,

      I am testing Polycom remote phone capability with the shared line appearance (SLA) feature - the SBC and PBX sit behind the LAN interface on Pfsense. There is one WAN interface with a public IP address assigned.

      SLA capability on Polycom phones uses two ports in this implementation:

      • 5060 for general SIP signaling to the SBC
      • 5170 for SLA signaling

      I have two entries in the NAT port forward table of Pfsense, with corresponding firewall rules:

      Entry 1
      Interface: WAN
      Protocol: TCP/IP
      Source Address: Public IP address of remote phone
      Source port: *
      Destination Address: Public IP address of Pfsense WAN ethernet interface
      Destination Port: 5060
      Target IP: 10.20.2.25 (IP address of SBC)
      Target port: 5170

      Entry 2
      Interface: WAN
      Protocol: TCP/IP
      Source Address: Public IP address of remote phone
      Source port: *
      Destination Address: Public IP address of Pfsense WAN ethernet interface
      Destination Port: 5170
      Target IP: 10.20.2.25 (IP address of SBC)
      Target port: 5170

      As you can see, 5060 and 5170 destination ports map to the same target port in Pfsense. In reviewing PCAPs, what is happening is that the WAN interface and firewall is observing the first port forward entry and forwarding to the SBC on the LAN side. SIP packets with destination port 5170 are being received on the WAN interface but not forwarded to the SBC. If I flip the entries around, then SIP packets from the remote phone using port 5170 are forwarded the SBC but 5060 packets are dropped.

      Is there an easy way around this issue?

      All the best
      Peter

      1 Reply Last reply Reply Quote 0
      • M
        muswellhillbilly
        last edited by

        Er… change the target port in Entry 1 to 5060, I would have thought.

        1 Reply Last reply Reply Quote 0
        • P
          peterkrautle
          last edited by

          Many thanks for the response. The way shared lines work with Polycoms on this PBX solution is that the PBX issues a Subscribe with contact port number 5170 to the phone. That first subscribe to the remote phone is important as the phone uses that port number to communicate shared lines state changes back to the PBX.

          We do have remote phones working when both the port to the PBX from the SBC and port to the remote phone set to 5060 for private lines. However, the SBC 'out-of-box' configuration sends port 5060 to the remote phone and then transposes to 5170 for the active call-id on a shared line. Subsequent call-ids use 5060 for subscribe/notify signaling, and shared lines fails to work in this scenario.

          We are trying to avoid customized dialplans in the SBC so have defined the port number to the remote phone from the SBC as 5170 and ran into this Pfsense issue. Assigning a public address to the SBC bypassing Pfsense or building a customized SBC dialplan for this application are current alternatives being explored.

          Any insights on other workarounds is appreciated.

          All the best
          Peter

          1 Reply Last reply Reply Quote 0
          • M
            muswellhillbilly
            last edited by

            This isn't a pfSense issue, so much as a basic NAT error. Firewall rules apply from the top down, so your NAT rule will only work with the first entry the ruleset encounters. You're trying to port-forward using two different ports mapped to the same internal port, so the first one in the ruleset will apply.

            I believe you might be able to get around this by binding a second IP to the WAN NIC and setting your port map to that NIC, though I haven't personally tested this. What would probably be more likely to work would be introducing a second WAN NIC and setting the port map to that and the other port forward to the former NIC. Though from the sound of it, the more elegant solution would probably be the suggestion you made concerning a customised dialplan.

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