Strange behaviour when NATing SIP connections
-
I work for a VoIP provider, and we recently started using PfSense as our office firewall. However, I have also noticed the same strange behaviour on a couple of other routers as well. Perhaps someone can explain this behaviour so that I can fix it.
Many of our customers have several SIP phones behind their NAT routers, which are typically Linksys or Dlink routers, and our standard method of handling this situation is to assign unique ports to each phone and set up NAT to allow inbound connections to these fixed IP addresses. Our Asterisk server picks up on this, and the phones tell the server that they're logging in from say, port 5071, and that's the port where Asterisk should send calls to the phones. This arrangement works quite well with these routers, and they seem to preserve the state as expected.
However, PfSense and a scant few other routers will assign a random port for Asterisk to connect back to the phone on. If I set the phone to use port 5071 for incoming connections, the router will connect to Asterisk on say, port 57291, even though I have NAT configured to forward port 5071 to the phone. As a result, the Asterisk server cannot send calls to the phone because it's trying to connect back to the client on port 57291 instead of 5071.
Coincidentally, using siproxy is not really an option, because we're testing the phones for our customers, who typically aren't using pfsense.
-
Just to clarify, the problem is when the client (or your test client) is behind pfsense? If I understand you correctly, there are multiple SIP clients on pfsense's LAN, trying to connect to Asterisk, which is beyond pfsense's WAN (ie, the internet). Each SIP client is listening on a non-standard SIP port, and pfsense is rewriting these ports as they connect to Asterisk.
You may need to enable Advanced Outbound NAT and write a rule for each SIP phone using a static port.
-
No, that doesn't seem to have had any effect at all. SIP phones logging in on non-standard ports are still connecting to the Asterisk server on random ports.