Asterisk behind PFSense 2.0.3 works for clients outside but not in different LAN
-
Well, I have tried just about everything and it doesn't work for me. I can conclusively state that I have followed all of the great suggestions offered here with no success. Using tcpdump, I monitored the VoIP interface after moving the Trixbox behind pfSense and setting up Manual NAT to point to Broadvox. On incoming calls, you can see the voip connections but no traffic on outgoing calls pass through the VoIP interface. On the Trixbox, I can see the SIP connection attempt to Broadvox, but no answer from the other side. There's no sound (ringing, etc.) plus, my phones start logging registration errors. Once I reconfigure the Trixbox to sit outside of pfSense, everything works fine. I honestly believe that Asterisk works behind pfSense but only in certain situations. It's time to start looking at Cisco (ugh!).
-
Its not pfsense thats not working for you.
Its either:
1. Your settings. Some small thing you are overlooking.
2. You VOIP provider has its own issues.It is better and easier to have 1 ip > pfsense > all the computers in your setup than trying to 1:1 NAT Asterisk in 1 place using 1 WAN exclusively serving VOIP to a bunch of computers using a totally different WAN exclusively. Still, it could work. Some setting isn't quite right. You will hit the same thing on CISCO.
-
Its not pfsense thats not working for you.
Its either:
1. Your settings. Some small thing you are overlooking.
2. You VOIP provider has its own issues.It is better and easier to have 1 ip > pfsense > all the computers in your setup than trying to 1:1 NAT Asterisk in 1 place using 1 WAN exclusively serving VOIP to a bunch of computers using a totally different WAN exclusively. Still, it could work. Some setting isn't quite right. You will hit the same thing on CISCO.
I just got off the phone with Fonality Support. I had them look at my Trixbox configurations, firewall, etc. They say that it's setup properly and should work behind the pfSense firewall and it actually does work one way. I've done this sort of thing many times with Cisco equipment which makes it easy to direct specific traffic out multiple serial interfaces but pfSense routing eludes me. I cannot see why I can't use a firewall for the LAN interface specifying that any traffic inbound from the LAN from the Trixbox alias that match my UDP rules for SIP & RTP cannot be sent out the VoIP interface instead of the WAN interface. In fact, this is how I first tried to do this as it worked perfectly for VoIP traffic inbound through the 2nd WAN interface.
I'd like to have 1 ip > pfsense > internal network but here I am running a call center with 60+ agents (and growing) so having them use a dedicated WAN interface for VoIP makes sense especially with our using a number of cloud based applications. I believe that it's definitely a routing issue because incoming calls work fine - you can see them register in tcpdump on the pfSense box and connect on the Trixbox.
-
I feel your pain.
An obstacle I faced that maybe you don't is the destination of the SIP packets.
For me, there is no way of knowing the IP of the endpoints of the SIP connection unless I tell asterisk to never re-invite and direct all incoming calls from everyone to initially be > to my 5060 port, allow SIP guests and limit 5060 incoming to only the IP of my trunk. Makes it harder than your setup.
But for you, is the far end ALWAYS only that 1 trunk such that you could set up policy that any traffic who's destination is the IP of you SIP trunk provider must use the WAN you intend for SIP and not the other WAN? -
I feel your pain.
An obstacle I faced that maybe you don't is the destination of the SIP packets.
For me, there is no way of knowing the IP of the endpoints of the SIP connection unless I tell asterisk to never re-invite and direct all incoming calls from everyone to initially be > to my 5060 port, allow SIP guests and limit 5060 incoming to only the IP of my trunk. Makes it harder than your setup.
But for you, is the far end ALWAYS only that 1 trunk such that you could set up policy that any traffic who's destination is the IP of you SIP trunk provider must use the WAN you intend for SIP and not the other WAN?And that's exactly what I initially thought as well. My VoIP provider will always be the destination for outgoing SIP calls. Initially, I believed that all I needed was two sets of rules - as such, I should only need to add the following rules to the LAN interface:
ID Proto Source Port Destination Port Gateway Queue Schedule Description
UDP Trixbox 5060 (SIP) Broadvox 5060 (SIP) * none SIP Outbound to BroadvoxUDP Trixbox 10000 - 20000 Broadvox 10000 - 20000 * none RTP Outbound to Broadvox
But this doesn't work because the Gateway is wrong - it is using the default WAN Gateway and not the VoIP Gateway and I completely missed how to alter the Gateway parameter in the LAN firewall rules.
If I am sitting inside the pfSense box, incoming VoIP calls use the VoIP interface and are forwarded with firewall rules directly to the Trixbox. This is working perfectly. Outbound calls from the Trixbox enter the LAN interface and have to be forwarded out the VoIP interface. Since Broadvox & the Trixbox are setup to recognize SIP traffic flowing through the VoIP IP address, that should complete the loop so to speak and provide two-way traffic between the Trixbox & Broadvox. That's why I always considered this to be a routing and not a NAT issue because Trixbox 12.6 is NAT compatible and I wasn't experiencing NAT issues. What I've been trying to do is what pfSense calls policy-based routing only I couldn't get this to work because as I stated earlier, I was over thinking and went off into 1:1 NAT and Manual NAT land. Now, if my reasoning above is sound, then the solution appears to be simple: Under the LAN firewall rules, use the Advanced Features and set Gateway to the VoIPGateway for the LAN firewall rules above. Because I'm in a production environment, I cannot test this out until Friday evening but I will post my results.
-
Just do it… If it goes down the millions of dollars per hour the company looses to the outage will be justified if it satisfies your curiosity :D I'll be looking forward to the results.
-
Well sad to report, this did not work at all for outbound calls. I was unable to even pull up the Trixbox Control Panel (https://cp3.trixbox.com) while tcpdump showed no outbound traffic outbound on the VoIP interface. It was as if the Trixbox lost all Internet connectivity while retaining LAN connectivity even though it's IP settings pointed to the pfSense box as the LAN gateway. I could connect to it via SSH but asterisk -r showed no outbound calls or traffic going through the VoIP interface from the LAN - they were still going out the WAN interface and consequently were being rejected by Broadvox. The two rules on the LAN interface should have done the trick but it's as if pfSense totally ignored them. And yes, I moved them to the very top on the LAN rules page. The last thing I suppose I can try will be to upgrade pfSense to 2.1RC0 to see if this somehow works (I've read about issues with 2.0 & multi-WAN setups like mine) but I am totally out of options here and this has been going on for a month with no resolution.
-
I saw one of the HERO guys here saying that if gateway address isn't stipulated in the WAN interface setups using multiwan that your rules may get ignored or have no effect. (something to that effect anyway).
Do you have gateway address stipulated in the WAN interface setup?
-
I saw one of the HERO guys here saying that if gateway address isn't stipulated in the WAN interface setups using multiwan that your rules may get ignored or have no effect. (something to that effect anyway).
Do you have gateway address stipulated in the WAN interface setup?
Most definitely. See attached.
-
Time to consider another option I guess:
http://images.clipartof.com/small/1045996-Cartoon-Black-And-White-Outline-Design-Of-Businessmen-Communicating-On-Can-Phones-Poster-Art-Print.jpg -
Time to consider another option I guess:
http://images.clipartof.com/small/1045996-Cartoon-Black-And-White-Outline-Design-Of-Businessmen-Communicating-On-Can-Phones-Poster-Art-Print.jpgCould I order 60 more of those please?