NAT for Multple Asterisk Servers behind pfSense
I just set up a fresh pfSense and two Asterisk Servers for testing purposes. Both Asterisk Servers are trunked to the same external VOIP Provider. Now depending on which Asterisk comes first, one of the systems will register and work over the trunk just fine while the other won't. If I use two different VOIP Providers on each Asterisk, both can register. Taking a look at the traffic passing the pfSense WAN interface, it looks like the packets from the second Asterisk (the one which can't register), are not being natted and leaving the interface with their internal ip address. I assume this is because there is already an active NAT for [external-ip]:5060 pointing to the first asterisk, is that correct? But then again it should not make a difference whether I have 2 connections to the same VOIP Provider or to two diffenrent Privoders. Maybe someone could give a bit of explaination here…
So what would be the best way to get two or more asterisks to work behind a pfSense firewall?
Any help or suggenstions appreciated!
If the provider has more than one server, register each * box to a different one. If not, ask if they can use a different port number for one?
Thanks a lot for the answer. I thought about that, too and tried to get pfSense to change the outgoing port from the second asterisk from 5060 to 5070 as suggested in other forums. Unfortunately I couldn't figure out how to do so using pfSense. I meanwhile solved the problem using sipproxd which works fine.
However, I still don't fully understand what was the problem there even though I'm quiet experienced with NAT and Firewalls. Maybe you or someone could explain?
pfsense i believe does not rewrite the source port if it is 5060, so if two sip entities behind the firewall try to talk to the same remote SIP server, the remote host will see two connections from the same source IP (pfsense) and port (5060), so return packets will not make it to the second asterisk server. i intended to suggest trying siproxd but forgot :( glad it is working now.
That does indeed make sense, thank you!