When will 1.3beta go public?

Accounts

what dosnt work with the cisco voip phones? got some here never a lick of trouble, use m5 for our phone service.

cybercare

We got Cisco 7940 & 7941 and they wont connect when they have to go through a pfsense 1.2 box…. The server side is running Trixbox CE and currently not behind any firewall... The phones dont seem to connect via tftp or even register if they are located behind the firewall themselves.

Have tried it on 2 different servers from different providers... But the softphones work fine. Currently have to use some cheap dlink to get phones working, and all it does different option wise is it has some options to turn AGL for sip and other protocols.

toddhumphries

I have a very similar setup with the exact same problems as cybercare. I have not been successful at getting my Cisco phones to configure via TFTP behind the pfsense 1.2 NAT.

The phone registering problem occurs because the pfsense box only holds UDP state information for 60 seconds and the PBX sends a qualify packet every 60 seconds to see if the phone is still available. This causes a race condition where sometimes the qualify packet is received before the state expires, and sometimes it doesn't, causing the phone to become unavailable.

If there was a way to change the UDP_First state timeout in pfsense it would solve the registering problem.

I ended up recompiling trixbox to send the qualify packet every 30 seconds and now my phones are solid. You can find more information at:
http://www.voip-info.org/wiki/view/Asterisk+sip+qualify

I get around the TFTP issue by connecting each phone to an external network (using a LinkSys WEP54g router) for the initial configuration and PBX connection, and then I put them behind the pfsense box. I would love to get a proper TFTP fix so I could configure the phones behind the pfsense NAT.

cmb

TFTP and NAT don't play nicely, and 1.2 doesn't have a TFTP proxy. 1.3 does. If you don't require an external TFTP server, any phones will work fine. For those that do require TFTP, it won't work if the phones are NATed.

We're trying out FreeBSD 7.0 and 1.3 right now, which is delaying the availability of the first testing snapshots. They'll still be available before the end of March.

The PPTP issues can be worked around to some extent by using multiple public IPs. See PPTP and GRE limitations here for an explanation:
http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43

cybercare

You know I was able to get tftp to work through the pfsense 1.2 at one point because I watched the phone download the config. I think it was when I turned off the default block all rule. But I was messing with a lot of things.. i did that, had 1:1 nat with everything open going to just one phone. It would download config but after that would not register…

The TFTP part is not sooo bad, I mean it still sucks butt however at least getting the phones to work beyond that would be great! :)

Crashit

@toddhumphries:

The phone registering problem occurs because the pfsense box only holds UDP state information for 60 seconds and the PBX sends a qualify packet every 60 seconds to see if the phone is still available. This causes a race condition where sometimes the qualify packet is received before the state expires, and sometimes it doesn't, causing the phone to become unavailable.

If there was a way to change the UDP_First state timeout in pfsense it would solve the registering problem.

I am not sure what will be availble in 1.3 to fix this however I will relay my stop gap solution for using pfSense with VOIP phones in certain situations today. I use this currently with SIP and MGCP phones and it works. I do indicate a setting of 180 seconds, this may be overkill so adjust to your needs.

First some quick background; Several VOIP protocols use UDP for signaling, although the SIP protocol and some SIP devices do support TCP for signaling you are probably at the mercy of your VOIP provider to decide. Additionaly almost any VOIP engineer would cringe to hear you want to use TCP for SIP. SIP at Layer-4 has reliability mechanisms built in and doesn't need the additional overhead applied by TCPs chatty'ness. That being said MGCP is another VOIP protocol that most certainly uses UDP by standard without deviation.

When communicating with a VOIP service provider over the Internet it is probable they are using a SBC(Session Border Controller). These devices provide a basic firewall solution among other features the provider needs at the edge of their VOIP network where it peers with the Internet. A main functionality of these SBCs are to provide "Hosted Nat Traversal". This technique allows the service provider to peer with you on a dynamic nature without the need for you to go through the trouble of "fixing" VOIP protocols like SIP and MGCP. The most common and most effective technique for this is "pinhole". This is where the SBC will modify the protocol at Layer-4 if necessary and change source/destination ports at Layer-3 to poke a hole in your firewall for the UDP communications to get through. This applies to both the audio path(RTP) and signaling, they both need pinholes to work. In the example of MGCP and NAT/PAT, your device will source MGCP packets at 2427, the firewall translates the packet to a random source port(54678) then forwards it on to the provider. The provider's SBC looks inside the packet, modify's any private IP to your public one. Then on the return MGCP message modifies the destination port of the packet to be your PAT port, or in our example's case 54678. The NAT/PAT service in the firewall will then translate it back to the correct port and IP and send it on. Now this is a simplified version of all this, but you get the picture. This works in almost 100% of situations where the firewall you the consumer use isn't VOIP aware or you aren't using the NAT traversal techniques provided in the device behind said firewall.

All that being said, and yes I am sorry for the long post, one thing that needs to be done on your side is that you need to keep the "pinhole" open. This can be a problem if the UDP "MULTIPLE:MULTIPLE" states created for the protocol are timing out or the negotiation timeouts out in getting to the "MULTIPLE:MULTIPLE" state. This applies to both the firewall rule and NAT/PAT state. This can happen when the protocol isn't sending a "Keepalive" in a timely manner or the protocol doesn't use a keepalive. Both SIP and MGCP do use a form of keepalive while idle and the SBC usually can force it both idle and during conversation. In the case of MGCP these are AUEP messages, SIP they are usually NOTIFY, OPTIONS or similar. In both cases the device only needs to respond, not necessarily a valid response but any UDP message directed to the service provider in response to the keepalive will restart the state timeout counter.

In the case of pfSense the UDP timeouts are too short for most service providers taste. I can say this faithfully as I work for a VOIP service provider and this is our stance. Unfortunately I cannot modify this setting in the products we use and the timers provided are too short for MGCP by default. I have seen a couple of posts indicating to use the advanced tab's optimization setting for this, once again this doesn't bump the timeout high enough. Secondly other posts indicate using the advanced/timeout setting on a rule designed to match the protocol, device's source or service destination address. There are two reasons this won't work, one is that pfSense only sets the tcp.established timeout this way, arguably a bug. Secondly this will not fix the NAT/PAT timeout, another need for keeping pinholes alive. Below are some simple code changes that will allow you to select a "voip" optimization on the Advanced tab that will fix most cases where UDP timeouts are too short. Use the code at your own risk, remember you must be in a shell and have mounted the root directory read/write to perform the modifications.

/etc/inc/filter.inc

if ($config['system']['optimization'] == "voip") {
$rules .= "set optimization normal\n";
$rules .= "set timeout udp.first 180\n";
$rules .= "set timeout udp.single 180\n";
$rules .= "set timeout udp.multiple 180\n";
} elseif ($config['system']['optimization'] <> "")
$rules .= "set optimization {$config['system']['optimization']}\n";
else
$rules .= "set optimization normal\n";

/usr/local/www/system_advanced.php

/usr/local/www/javascript/system_advanced/system_advanced.js

descs[4]="set timeouts optimized for VOIP UDP IE MGCP";

It should be easy to determine where to place the code snippits and what to replace, if not then you may want to wait for 1.3 as this fix may be beyond your abilities to apply. Another reminder, the above settings of 180 are pretty high and in most cases overkill. Though if you are not producing a crazy amount of random source/destination port UDP traffic even a setting of 180 seconds won't impact the router much. Plus it will probably work for about any SIP/MGCP device and service out there.

superwormy

Is there any update on this? When will the alpha/beta releases of 1.3 be public?

Cry Havok

As usual, when they are ready.

Seriously, asking the question won't make things happen any sooner ;)

David_W

I'm sure the developers have very good reason not to offer an easy way of downloading and bootstrapping 1.3 at the moment. If it was made publicly available, some people will expect at least a modicum of support if it doesn't work in their setup, will report bugs that the developers may be aware of and are looking to fix, and there might be disruptive changes waiting to be committed that end users will not find easy to handle.

The pfSense team will be wanting to let people see their work as soon as possible - but it has to be ready for public viewing.

mkreafle

I have been a lurker on the forums for a while. Many questions have been answered. And I am sorry to bump the thread. But I just wanted to say I am really really really excited and can't wait to take a look at your next release! Keep up the ~~good~~ outstanding work!

cybrsrfr

If you want it to happen faster offer a donation or a bounty for pfSense 1.3. These can help the developers devote more time to pfSense development.