SOLVED: Having a maddening time getting a SIP Codec to work correctly.
-
I did get rid of the 6014 and 6015 port forwards and that made no difference. It still connects, but no data is transferred.
I've tried all the troubleshooting links I can find. There must be something that will work, but I'm baffled as to what it is. Having spent nearly two weeks on this, I'm getting close to contacting support.
-
Have any documentation from Comrex describing exactly what they need from a firewall - NAT in particular?
-
They say to forward ports 5060, 6014, and 6015 UDP to the unit and it needs a static IP. I've since assigned the unit to avoid load balancing as I'm on a dual-WAN, but that didn't solve the problem.
Here's their guide to connect Linphone SIP client with the Comrex:
http://www.comrex.com/wp-content/uploads/2016/01/Linphone-technote-for-ACCESS-and-BRIC-Link.pdfWorks fine when I connect to their test, works fine when I plug the Comrex directly into my cable modem, so it's definitely not a problem with Linphone or the Comrex - seems like something in PFsense is getting in the way.
-
That's great but there is nothing to get in the way there.
I see no mention of outbound connections from the codec so delete any static port outbound NAT you have created. It won't help and might break something else.
What are the contents of all your aliases?
I see no mention of TCP in that document. Why is your SIP forward TCP/UDP?
You do not need to worry about Multi-WAN on inbound connections from clients. pf reply-to handles that and is automatic as long as that connection is set up as a WAN (Has a gateway set on the interface). That is unless the default gateway on the codec is not set to pfSense LAN in which case you'll have all sorts of asymmetric routing issues.
-
This right?
http://www.comrex.com/wp-content/uploads/2016/02/ACCESS-Rack-Manual.pdfAre you running v3.0 firmware? If not then you need to be forwarding different ports.
In the case of SIP, this
must be three discrete ports (For Comrex codecs these are UDP 5060, 5014
and 5015)
<6014 and 6015 with 3.0 firmware>Do you see any blocked traffic in the firewall log from the client IP you are trying to connect from?
Steve
-
Derelict:
I've tried static port on and off and neither worked, so it's off at this time.
I was forwarding TCP so a port checker would be able to verify the forwards. It's not necessary for the Comrex. Only UDP.
Do you want the full contents of my aliases on ports, or just those related to the Comrex?
-
This right?
http://www.comrex.com/wp-content/uploads/2016/02/ACCESS-Rack-Manual.pdfAre you running v3.0 firmware? If not then you need to be forwarding different ports.
In the case of SIP, this
must be three discrete ports (For Comrex codecs these are UDP 5060, 5014
and 5015)
<6014 and 6015 with 3.0 firmware>Do you see any blocked traffic in the firewall log from the client IP you are trying to connect from?
Steve
I'm running Comrex 4.0-p9 - the latest firmware. Ports 5060 and 6014 and 6015 are the proper ports, per the advanced settings in the unit.
I've checked the firewall, and no, I don't see any blocked traffic from the IP in question.
-
As you can see in the pic I posted in this post: https://forum.pfsense.org/index.php?topic=121139.msg671629#msg671629
There are states between my cell phone IP and all three ports in question. But no meaningful amount of audio data (like a 64kbps audio stream) is being transmitted.
-
(Going on the radio for a few hours - will check back later. Thanks for the help, all.)
-
Ok, I would try grabbing a packet capture on the internal interface and filter by the IP of the Comrex unit.
If you can inspect the SIP packets in wireshark I'm betting that it's handing out it's internal private IP as the destination for the RTP traffic.
There appears to be a setting in the Comrex to force that to the external IP:
Under
Advanced System Settings
, a field is available called
Public IP Override
. Any address put into that field will be pasted into the
address SIP fieldSteve
-
There simply doesn't look to be anything special about this unit. No special NAT requirements.
Just need the contents of the aliases specific to the Comrex.
From those states it looks like the phone IP connects inbound on 5060 and then the Comrex is attempting to connect outbound on 6014 and 6015 to the Cell Phone's IP address and is receiving nothing in reply.
Allowing that traffic will be up to the firewall at the cell phone side. Those counters show the outbound traffic, with zeroes in reply and those two captures are a good example of what is meant by static source port.
You sure you have this all configured correctly?
It looks to me like the "server" unit should tell the phone unit to connect back to it on 6014 and 6015 but, instead, it is just trying to connect outbound sourced from 6014/6015. Destination 7076 and 7077 in both examples.
-
Ok, I would try grabbing a packet capture on the internal interface and filter by the IP of the Comrex unit.
If you can inspect the SIP packets in wireshark I'm betting that it's handing out it's internal private IP as the destination for the RTP traffic.
There appears to be a setting in the Comrex to force that to the external IP:
Under
Advanced System Settings
, a field is available called
Public IP Override
. Any address put into that field will be pasted into the
address SIP fieldSteve
Hrm, here's the top of the packet capture I ran during a test connection from Linphone. The source and destination ports are:
line 1: 37524 / 5060
2: 5060 / 37524
3: 1783 / 7077
4-100: 61245 / 7076Searching for the cell phone IP in the firewall logs of pfsense shows nothing - no pass, no block. Shouldn't it show passes?
-
Under
Advanced System Settings
, a field is available called
Public IP Override
. Any address put into that field will be pasted into the
address SIP fieldDid you do this?
No. Pass rules do not log unless you explicitly enable that on the rule.
Again, that shows good two-way SIP initiated by the Phone IP followed by OUTBOUND traffic to the Phone IP on ports 7076 and 7077. That will have to be passed at the Phone IP side.
-
There simply doesn't look to be anything special about this unit. No special NAT requirements.
Just need the contents of the aliases specific to the Comrex.
From those states it looks like the phone IP connects inbound on 5060 and then the Comrex is attempting to connect outbound on 6014 and 6015 to the Cell Phone's IP address and is receiving nothing in reply.
Allowing that traffic will be up to the firewall at the cell phone side. Those counters show the outbound traffic, with zeroes in reply and those two captures are a good example of what is meant by static source port.
You sure you have this all configured correctly?
It looks to me like the "server" unit should tell the phone unit to connect back to it on 6014 and 6015 but, instead, it is just trying to connect outbound sourced from 6014/6015. Destination 7076 and 7077 in both examples.
I've attached the comrex port aliases, per your request. The 10000:30000 range is new - I added them per PFsense's official support person's request, though they are not required by Comrex. Adding them made no difference.
I believe I have it configured correctly - that's what PFsense's support person told me. That's what one of the earlier respondents said here on this thread, but clearly I've got something set wrong somewhere, as the Comrex works fine when it's plugged directly into the cable modem.
-
Under
Advanced System Settings
, a field is available called
Public IP Override
. Any address put into that field will be pasted into the
address SIP fieldDid you do this?
No. Pass rules do not log unless you explicitly enable that on the rule.
Again, that shows good two-way SIP initiated by the Phone IP followed by OUTBOUND traffic to the Phone IP on ports 7076 and 7077. That will have to be passed at the Phone IP side.
Welp, I set that field to my WAN IP and now it's working. Thank you!
