NAT Port Forwarding Issue with Pfsense 2.2.2

[peterkrautle]

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

[muswellhillbilly]

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

[peterkrautle]

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

[muswellhillbilly]

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.