VOIP on Linux behind pfSense
-
I have a pfSense firewall between my home network and the internet. I installed VOIP application X-Lite on a Windows Vista system and installed siproxd package on the pfSense box and successfully got VOIP working making international calls to landline phones.
I recently bought a netbook running Linux and now want to get a VOIP application running on it but have been unable to get any of those I tried to work. Anyone had any positive experience with Linux VOIP applications behind pfSense.
The netbook runs gOS and it seems all the assocaited VOIP applications are at least somewhat old. I've tried ekiga (2.0.12), kphone (4.2), Twinkle (1.1) wengophone (2.1.2) and Linphone (2.0.1) but not been able to get any of them to work. They mostly seem to fail to register, reporting timeout. I've tried a tcpdump on the WAN interface on pfsense and generally see traffic TO the VOIP provider but nothing coming back.
-
I connected the netbook into the 4 port switch of my ADSL modem (upstream of pfSense), reconfigured ekiga to remove the proxy entry and ekiga then registered with my VOIP provider and I was able to call my home phone.
I'd prefer to work with my netbook downstream of pfSense but my present configuration is useful enough for experimenting with VOIP.
-
The gOS on the netbook is based on Ubuntu 8.04 (Hardy).
I installed Twinkle 1.2 which I downloaded from a link on http://www.getdeb.net/release/2573
and after I figured out the configuration entries I got it to work reliably behind pfSense. At least one of the problems in Twinkle 1.1 seems to be that it sends out requests with a call id of xxxx@ <ip-address of="" netbook="">and the response which it reports has a call id of xxx@ <ip-address-of-netbook incompletely="" overwritten="" by="" ip="" address="" of="" pfsense="" wan="" interface="">which ends up not matching the sent call id.
In Twinkle, in the user profile I set the Sip Account Domain to my VOIP provider's gateway and the Sip Server Registrar to my pfSense box running siproxd (I initially thought this should have been the VOIP provider's gateway), enabled proxy and set the Outbound proxy to my pfSense box.
I still haven't been able to get any of the other VOIP applications I listed working downstream of pfSense (except for Ekiga which registered and worked only very intermittently) so I've given up on them and will stick with Twinkle unless the voice quality is terrible.
I have siproxd inbound interface as LAN and outbound as WAN. I have LAN and WLAN bridged. Twinkle works over both LAN and WLAN.</ip-address-of-netbook></ip-address>
-
Why not post the solution on board? so other people with the problem… like me... can get help?
-
I found siproxd to be flaky. Without it, what turned out to be necessary was static port for AON rule and all was well - one of my providers didn't seem to like seeing the RTP port rewritten :)
-
I do not use siproxd either…
I simply make a firewall rule for my providers servers to allow them access...
-
I do not use siproxd either…
I simply make a firewall rule for my providers servers to allow them access...
It might work with one phone but I doubt it will work for serveral phones behind pfSense.
-
Why not post the solution on board? so other people with the problem… like me... can get help?
I thought I did: I use Twinkle 1.2.
Or are you referring to another problem?
-
I do not use siproxd either…
I simply make a firewall rule for my providers servers to allow them access...
It might work with one phone but I doubt it will work for serveral phones behind pfSense.
Sorry should have said I use Voipo for a couple of lines then Vonage for all my business lines when I bring them home… Multiple lines and providers.
No port forwarding however. Just firewall rules.
-
Ah, a voipo customer :) I just ported my number out of them. Not from unhappiness, but because they made a (totally understandable) business decision to not support BYOD customers, which I am an extreme example of :) I am using the freepbx service which uses bandwidth.com. voipo worked fine with pfsense, but the other service got confused due to the source RTP ports being rewritten, hence my need to use the static_port directive.
