2.0 with IP Phone
-
I have been playing with 2.0 and I'm having an interesting issue. I'm guessing it's probably something easy to fix.
I have an IP Phone for a Trixbox server that is located at another site. It's been working fine for a year or so, not a single issue and never needed any special configuration at all. Last week I decided to try out pfsense 2.0, I was using smoothwall (always awesome) and then endian (don't get me started about the bugs). The phone always just worked once it got an IP. Now with pfsense I can make calls and everything works fine. If someone calls me after I make a call, the call comes through just fine and rings my phone. If the pfsense box is rebooted or I don't use the phone for a while, I no longer receive calls. Once I make a call I can start receiving calls again for a while. Now I'm pretty savy and I was thinking that this was a NAT issue and after some research realized that I had to make some changes to the Outbound NAT configuration. I switched it to manual and made sure there was a NAT entry for port 5060 (udp and tcp just to be thorough) and it's marked as static. This seemed to fix the problem, but aparently it did not. After sitting all night, I can not receive calls the next day until I make a call first.
Now for shits and giggles I just now created a firewall rule to allow port 5060 (again udp and tcp just for the hell of it) so I don't know if that will fix the issue, but I really don't think it will.
We're looking at using some version of pfsense for a WAN balancing/failover setup for a client. We are aware that 2.0 is not production ready. I'm also playing with version 1.2.3 and I have this same problem.
So people, any ideas?
-
Sounds like the phone is relying on an idle but open state, and once the state disappears from pfSense (it will scrub states after a while) it loses connection and doesn't reset the state until the phone makes a call. I don't think the issue here is with pfSense, but with your trixbox/asterisk configuration - is the phone required to register with the trixbox and also is it using SIP's NAT traversal techniques at all?
I'm also using trixbox and Linksys SPA942 phones but all the gear is behind pfSense on the LAN side - the only SIP connection through the WAN are the SIP trunks from trixbox to my providers.
Alternatively, another path to look down is a package for pfSense called siproxd. for some it works better than others - but for me it makes my calls very unreliable and choppy so I don't use it. YMMV.
-
Possibly #1, 2 or a combination of those here.
http://doc.pfsense.org/index.php/VoIP_Configuration -
Thanks for the replies guys!
I tried to sip proxy package, but it didn't help at all. I had forgotten to mention that. I think that disabling the scrubbing should work though. I do not have any control over the Trixbox config but I assume it is setup to use standard nat-t tricks and such. I'll have to talk to the trixbox guy about it. I'm going to try and set the state table optimization for conservative and see how that works. I'll post back with my results so that other people in the future can find the answer :)
-
If you make an outgoing VOIP call there will be firewall state created so that an incoming VOIP call will go to the same place. After a while the state will timeout and disappear. If there is then an incoming call how will the firewall know where to forward it? Wouldn't you need a Port Forward rule or something like it to cover this situation?
-
If you make an outgoing VOIP call there will be firewall state created so that an incoming VOIP call will go to the same place. After a while the state will timeout and disappear. If there is then an incoming call how will the firewall know where to forward it? Wouldn't you need a Port Forward rule or something like it to cover this situation?
No, the connection is first initiated outbound (SIP registration and RTP) which lets the server reply back over that open connection (as long as it doesn't get closed, hence use keep alive on your phones, or make sure your state type is conservative).
-
@cmb:
No, the connection is first initiated outbound (SIP registration and RTP) which lets the server reply back over that open connection (as long as it doesn't get closed, hence use keep alive on your phones, or make sure your state type is conservative).
What is the difference in timeout between Normal and Conservative?
-
What I would recommend is to use "qualify=yes" for the trunk(s), that should keep the SIP registration active.
-
Try this:
http://doc.pfsense.org/index.php/Static_Port
-
He is already doing static port.
-
Hrmm…yeah, I guess I missed that in the original post. Well, that solved some VoIP issues for me, so I guess it's worth repeating even if it doesn't work in this specific case.
-
Does your Voip provider handle the audio of your calls or do they hand off that task?
Who is your provider… (Ill go back and re-read in case I missed...)
If your provider hands off the calls then the audio RTP streams will be coming from somewhere else and will be seen by the firewall as an unsolicited attempt to connect.
-
Not necessarily - the moment the IP phone sends any outbound RTP, this should establish a state table entry. Also, he was complaining about receiving calls, which is a SIP issue, not RTP.
-
My "will be seen" should read "could be seen" regarding the firewall… But I see your point...
Just throwing an idea out there. Initially got me on a PBX I tried to run internally...
But after re-reading... I had to turn the keep alive on with the ata's at the office behind the 1.2.3 install I have there to allow my Freeswitch install I have here to reach it after the states wanted to expire.
My providers send some form of keep alive from their servers to my home ata's that I can not duplicate on Freeswitch here. However it shouldn't matter what side it comes from.
You should not need port forwarding on the ata/ip phone side to make this work.
-
Try to configure your phone to re-register every 60 seconds. That will fix it. Sometimes it's a "re-register" field, sometimes it's called "Register expiry" or something like that.
As long as it re-registers faster than the firewall forgets your state, you'll be be ok. 60 seconds seems to do the trick on pfSense vanilla.
-
Well I got the problem sorted out for the most part, but now I have a new problem. The tftp-proxy is missing on 2.0 BETA1. I'm going back through the snapshots to see when it went missing, but I haven't found it yet. Does anyone have a copy of "/usr/local/sbin/tftp-proxy" that I can use? I'm getting
inetd[30822]: cannot execute /usr/local/sbin/tftp-proxy: No such file or directory
It's in the System Log whenever I try to push tftp traffic, so it appears that it's configured properly, just not there lol
-
Oh, and I'm also trying to get it to use tftp over an ipsec vpn. It doesn't seem to want to route the tftp traffic. I've confirmed that tftp is working on the remote network.
-
I got tftp to work over the ipsec, I had to disable the tftp proxy. well I couldn't disable it actually, i just switched it to OPT1 to it wouldn't interfere with LAN traffic.
so that's two things broken, missing tftp-proxy and the gui on the advanced page is broken. it doesn't highlight the enabled interfaces so it always looks completely disabled.
-
I fixed the select issue, there's a ticket open on the missing binary. You don't want or need the TFTP proxy in most routing scenarios including IPsec, only with NAT is that needed generally.
-
nice, yea I'm aware it isn't needed for ipsec. but i want to say that it being on and set to LAN made tftp not work over my ipsec tunnel so it must be doing something there. or maybe i'm just misunderstanding how to configure it. for an ip phone on LAN to work with a tftp server on the internet/WAN (bad practice i know), does the proxy have to be set to LAN or WAN?
