When will 1.3beta go public?
-
When can we look for 1.3 to be out for playing with in beta?
I know 1.2 is done, but 1.3 has also been being worked on for a bit, and 1.2 just does not do everything we need in a firewall…
Thx!
-
What does 1.2 not do that you need?
1.3 will enter alpha within the next month.
-
It does not work well with our Cisco VOIP phones (even though we erase default block, something still gets blocked) and no one has a working sip proxy or anything.
Also we have problems with the PPTP… Which I know is known problem, but when the unit is hosting PPTP we cant VPN out to our clients running other hardware PPTP, only can connect to MS Windows Server PPTP hosted platforms.
Overall I love the thing, but it lacks in critical areas we need for our business and it seems the area's I have problems in no one has ways to work on them because of other limits?
-
I'm after the tftp proxy / helper application for my Cisco VoIP phones. Scott said it will be in after the 1.2 release.
But I'm in no hurry to push anybody to get this out. I think its great that 1.2 has be released, and I'll take this opportunity to say thank you for all the hard work you guys have put in.
Regards
Ben
-
I am hoping for this weekend. Keep monitoring the snapshot server.. This is where they will appear.
-
Just a quick question :
Is pfsense 1.3 based on FreeBSD 6.3 or 7.0 (released yesterday)?
Thanks and regards
-
I am hoping for this weekend. Keep monitoring the snapshot server.. This is where they will appear.
When you say watch the snapshot server are you saying that the tftp helper will go into 1.2? or you mean that 1.3 will be posted with it?
Thx
P.S. Is this whats causing the problems with most the Cisco's not working? I mean I know the tftp does not connect for the phones, but what about after that, the sip part? Anyone know of a sip proxy working being worked on or anything?
-
This I believe is what he meant by watch the snapshot server.
http://snapshots.pfsense.com/
It contains the latest work the developers are working on. These aren't releases and are only meant for testing purposes. So use them at your own risk.
I am still learning about all this so if I am wrong about any of this someone please correct me.
-
This I believe is what he meant by watch the snapshot server.
http://snapshots.pfsense.com/
It contains the latest work the developers are working on. These aren't releases and are only meant for testing purposes. So use them at your own risk.
I am still learning about all this so if I am wrong about any of this someone please correct me.
This is correct :)
-
no no no, sorry…
I know what the snapshot server is, have been using it for close to a year now...
But what I was wondering was is this update he is talking about, is it going to go into a 1.2 snapshot or are you saying 1.3 snapshot will be posted with the ability to do tftp proxy?
Thx!
-
We'll start posting 1.3 snapshots soon. 1.2 will only get security fixes when needed. All new features go to the 1.3- and head-branch.
-
what dosnt work with the cisco voip phones? got some here never a lick of trouble, use m5 for our phone service.
-
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.
-
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+qualifyI 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.
-
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 -
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! :)
-
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
<option value="voip" <?php="" if($config['system']['optimization']="="voip")" echo="" "="" selected";="" ?="">>voip</option>
/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.
-
Is there any update on this? When will the alpha/beta releases of 1.3 be public?
-
As usual, when they are ready.
Seriously, asking the question won't make things happen any sooner ;)
-
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.
