Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm in pain.

We are moving to a SIP based VOIP system and for whatever reason, we could not get our hosted Asterisk solution to work with our Sonicwall. Our VOIP provider gave up and is recommending an open source vendor, pfSense.

A little background:

  • We have about 30 users in our network.
  • We use a few IPSec VPN connections for remote networks.
  • I would like, but don't need, application layer filtering.
  • We're active internet users, so properly traffic shaping is probably a concern.

How can I tell if an open source firewall will handle VOIP setup smoothly with a hosted Asterisk system?

Current attempted setup with Sonicwall

  • We are using a TZ 190 running SonicOS Enhanced 4.2
  • Consistent NAT is enabled
  • We are not using SonicWall's automatic SIP Transformations. image link: http://cl.ly/1Q3A3K3C1M1Z322I1M2L
  • Firewall has been opened up to allow everything from our VOIP provider, and all SIP UDP & TCP: image link: http://cl.ly/310b07271R0c2s2c3L1g (@Tom O'Conner makes a good point that this may be a problem.)
  • More details coming later...
share|improve this question
    
There is a multitude of things which could go wrong. Not knowing them is an obstacle in answering your question. Your VoIP ISP would likely recommend pdSense because they have a tested scenario and configuration guidance for it. Publishing or referencing the desired configuration or some problem details would greatly improve your question. –  the-wabbit Mar 30 '12 at 11:01
    
Good point @syneticon-dj, I'm going to get my vendor's assistance in getting more detailed information. Perhaps there's a solution still for my old Sonicwall. –  Lucas Mar 30 '12 at 12:31
add comment

1 Answer

up vote 2 down vote accepted

PFsense can do that. To be quite honest, any firewall should be able to pass SIP and RTP through untouched.

SIP is only the mechanism for initiating calls, so that's only part of the problem. RTP is the protocol for the voice traffic itself. Some VoIP phones can use UPnP to talk to the firewall, and dynamically configure port forwardings as they make the calls.

PFsense can also do QoS, but I'm not sure how well it implements it (I've been configuring PFsense at work lately, and haven't got to QoS yet!)

This might be an interesting read, NAT + VoIP (From VoIP-info.org). The thing you probably do want to do is to restrict the SIP connections inbound to only come from your provider's SIP gateway, otherwise nasty people tend to connect in, and make expensive phonecalls on your account. Make sure you also lock down other ports to the phones like HTTP(S) and Telnet. I found an interesting security hole in a company once by being able to telnet into a public SIP phone, then ssh out onto the network.

You should also consider having a separate VLAN for Voice traffic. This can help with QoS, and eliminating jitter.

These might be interesting to have a look at regarding multiple SIP registrations and PFSense

share|improve this answer
    
That is interesting. I'm pretty sure we're having NAT issues with our Sonicwall. The phones were losing their connection to the server, and wouldn't ring unless they made an outbound call (thus reconnecting.) –  Lucas Mar 30 '12 at 12:54
    
If my vendor is willing, it sounds like a VLAN and VPN connection to their server would solve the problem. –  Lucas Mar 30 '12 at 12:54
    
+1 for pfSense. I have a good amount of personal experience using pfSense in VoIP-heavy environments, and I've never had a problem with it, including its traffic shaping, which it does very well. –  EEAA Mar 30 '12 at 13:23
1  
pfSense was so simple to setup and no special config was required for SIP transformations. –  Lucas Apr 17 '12 at 17:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.