Replacing IPCop 1.4.21 with pfSense 2.0Beta
-
Hello, just got started with this last weekend, after playing with pfSense in a VirtualBox environment to get a feel for it.
I want to replace an IPCop installation at a private school where I do the IT support. I've used IPCop for years, but it doesn't seem to be actively developed any more.
The configuration is a Static WAN IP and two Internal LANs: one for the office staff and Asterisk VoIP server, and one for the classrooms/wireless.
When I installed pfSense, I put the same NAT forwarding rules in as I had in IPCop. However, I'm having problems with one-way audio for inbound calls to the Asterisk. Outside callers can hear the staff, but staff can't hear outside callers. Calls originating from the office have two-way audio.
The Asterisk is configured with the usual externalip and asterisknet parameters, NAT is set to no. It has worked just fine using IPCop for about 3 months now (when we switched to VoIP).
Here's a twist: If I call into the system and access the school directory, and choose one of the office phones, two-way audio works! Something in the Asterisk SEEMS to be fixing the audio problems.
Does anyone have a suggestion? I've researched here and on the PBX In A Flash website and have read recommendations to set the Clear DF bit option to ON and uncheck the block RFC1918 addresses on the WAN port. Also considering installing siproxd.
-
I want to replace an IPCop installation at a private school where I do the IT support.
However, I'm having problems with one-way audio for inbound calls to the Asterisk. Outside callers can hear the staff, but staff can't hear outside callers. Calls originating from the office have two-way audio.
…http://doc.pfsense.org/index.php/Asterisk_VoIP
http://doc.pfsense.org/index.php/Category:VoIP -
I want to replace an IPCop installation at a private school where I do the IT support.
However, I'm having problems with one-way audio for inbound calls to the Asterisk. Outside callers can hear the staff, but staff can't hear outside callers. Calls originating from the office have two-way audio.
…http://doc.pfsense.org/index.php/Asterisk_VoIP
http://doc.pfsense.org/index.php/Category:VoIPI do understand what the word BETA means. However, I would think/hope something as simple as NAT forwarding would be easily understood by the firewall in the BETA, and would be the LEAST of the problems to deal with.
Thanks for your input.
-
Hello Mitch.
Some of us ARE using PFsense 2.0 in a production environment and the risk is something you will have to bear if anything goes wrong that results in a detailed explanation of your action to implement a BETA system as a firewall, or long, frustrating nights away from home to get things righteous again if an update breaks something.
Because time is linear for us, PFsense 2.0 appears to be long in development, but better sure than sorry. Only you can weigh the risks because the choice is yours to implement PFsense 2.0 and if you do, be sure to report, in detail, with relevant information included anything that doesn't work the way it should and as always…have a backup plan ready to go because Aunty and Uncle Murphy likes to show up when you least expect them too.
As in my case, I've been foolish enough to use PFsense 2.0 in a production environment precisely because of it's BETA status. Real world feedback and issue resolution can only make PFsense even better than the competition once detailed and relevant information on errors, etc are "parsed" (heh, heh) back to the developers and resolved in future releases, not that I'm perfect or even relevant. Just my two cents.
-
Hello Mitch.
Some of us ARE using PFsense 2.0 in a production environment and the risk is something you will have to bear if anything goes wrong that results in a detailed explanation of your action to implement a BETA system as a firewall, or long, frustrating nights away from home to get things righteous again if an update breaks something.
Because time is linear for us, PFsense 2.0 appears to be long in development, but better sure than sorry. Only you can weigh the risks because the choice is yours to implement PFsense 2.0 and if you do, be sure to report, in detail, with relevant information included anything that doesn't work the way it should and as always…have a backup plan ready to go because Aunty and Uncle Murphy likes to show up when you least expect them too.
As in my case, I've been foolish enough to use PFsense 2.0 in a production environment precisely because of it's BETA status. Real world feedback and issue resolution can only make PFsense even better than the competition once detailed and relevant information on errors, etc are "parsed" (heh, heh) back to the developers and resolved in future releases, not that I'm perfect or even relevant. Just my two cents.
Hi, jits.
First, I'm not b***hing about the BETA status of pfSense, nor its development timeline (having only come across it about a month ago). My apologies if it sounds like I am. I am fully aware of what beta means, and yes, I am willing (and the school I support is willing, since they get free support AND the promise of a secure network) to accept the inherent risk of using beta software.
Next, to clear up a potential source or confusion: I am not charging forward blindly. I installed a hard drive specifically to install PFsense on, with the ability to fall back to IPcop by powering down, swapping the IDE cable and rebooting. That's what I've been doing after several long evenings of troubleshooting this problem. IPCop works, it's just (apparently) no longer supported, and I prefer to run software which is.
Speaking of my specific problem, I do want to thank the first responder for the link to installing siproxd and the other link. I do plan on installing siproxd when I next get the chance to work on the problem. Would be nice if it solved the problem because otherwise, PFsense meets every other need I have for a firewall router, and then some.
As I stated in my response above, despite being "beta", it seems logical to assume that the firewall in PFsense from 1.2.3 to the 2.0 Beta would operate essentially the same. If NAT forwarding of SIP worked in 1.2.3, why would it suddenly be broken in 2.0? And, if that assumption is wrong, then consider this a trouble report to the developers ;^)
Thank you (sincerely!) for your 2 cents.
-
one way audio is definetely a nat issue on asterisk.
how are your outgoing nat rules in pfsense configured? manual or auto?
and are you forwarding the correct ports with the correct firewall rules? -
one way audio is definetely a nat issue on asterisk.
how are your outgoing nat rules in pfsense configured? manual or auto?
and are you forwarding the correct ports with the correct firewall rules?Hi, louis-m,
When I am running IPCop, there are no NAT issues with asterisk, because I have the appropriate port forwarding rules for SIP and RTP traffic, and I have Asterisk set up with the externip=xxx.xxx.xxx.xxx and localnet=192.168.1.0.
When I boot into PFsense, I set up the forwarding rule with the exact same port numbers (1024:65535) and UDP. Since there are several possible source IPs the traffic could come from (the provider is Broadvox) I have any source IP configured, any source port, and the destination is the WAN address, ports 1024:65535, redirecting to my Asterisk at 192.168.1.99, port range 1024:65535. NAT reflection box was unchecked.
The twist is when the incoming call goes to the Asterisk directory service, the caller selects any phone, the phone rings, someone answers and what do you know, two-way audio.
-
i always thought asterix was:
5060 tcp for sip
&
10000:20000 udp for rtpi'd also think about tightening the source rule up to only accept sip etc from your sip provider range. there's many a person had a very expensive bill due to weak passwords on asterisk.
if nat isn't correct, you will get intermittent audio issues. one minute it works, the next it doesn't.
you mentioned two lans. is you outbound nat rule for your voip lan set to 192.168.1.0/24 (the same subnet as your asterisk box is on)i don't run pfsense 2 yet but when using multiple lans, i find it better to manually configure the outbound nat (rather than leave to auto)
i would imagine pfsense 2 is the same -
You are correct about the default ports Asterisk uses for SIP/RTP. However, the SIP trunk provider, Broadvox, "requires" that all ports between 1024 and 65535 be opened. I plan on tightening up the firewall from any remote ip to the dozen or sip Broadvox-specific ones once the one-way audio issue is resolved.
Thanks for the pointer on the outgoing NAT rules being manually set. I did have it set for automatically generated. After all, that's what a good firewall should do, right?
But, since the one-way audio is working outgoing, that shouldn't be an issue.
That twist I mentioned previously indicates, to me, that the audio is actually getting through. Perhaps the destination address or port is being mangled?
i always thought asterix was:
5060 tcp for sip
&
10000:20000 udp for rtpi'd also think about tightening the source rule up to only accept sip etc from your sip provider range. there's many a person had a very expensive bill due to weak passwords on asterisk.
if nat isn't correct, you will get intermittent audio issues. one minute it works, the next it doesn't.
you mentioned two lans. is you outbound nat rule for your voip lan set to 192.168.1.0/24 (the same subnet as your asterisk box is on)i don't run pfsense 2 yet but when using multiple lans, i find it better to manually configure the outbound nat (rather than leave to auto)
i would imagine pfsense 2 is the same -
Thanks for the pointer on the outgoing NAT rules being manually set. I did have it set for automatically generated. After all, that's what a good firewall should do, right?
not nescessarily. depends on how you want the outgoing traffic to appear to the outside world.
it could be getting mangled as you said but generally i've fixed these issues with nat.
have you tried changing the asterisk ip & nat config on asterisk and then tried recreating the pfsense nat/firewall (incoming & outgoing) rules to match? -
As I stated in my response above, despite being "beta", it seems logical to assume that the firewall in PFsense from 1.2.3 to the 2.0 Beta would operate essentially the same. If NAT forwarding of SIP worked in 1.2.3, why would it suddenly be broken in 2.0? And, if that assumption is wrong, then consider this a trouble report to the developers ;^)
A lot of things changed under the hood, no assumption is safe, even in the firewall area. However, your last point is correct: If it worked in 1.2.3 and not in 2.0, it's a regression an should be treated as a bug. Defaults have changed in some regards though. Upgraded configurations should not regress in functionality, but new configurations may need to be done slightly different in some areas.
-
Thanks for the pointer on the outgoing NAT rules being manually set. I did have it set for automatically generated. After all, that's what a good firewall should do, right?
not nescessarily. depends on how you want the outgoing traffic to appear to the outside world.
it could be getting mangled as you said but generally i've fixed these issues with nat.
have you tried changing the asterisk ip & nat config on asterisk and then tried recreating the pfsense nat/firewall (incoming & outgoing) rules to match?Thanks for the response. I haven't tried changing anything on asterisk, mainly because it worked with IPCop, which, to me, pointed to a misconfiguration issue in pfsense. I agree it's in NAT, and had thought to install siproxd to make NAT a non-issue.
However, it all has to be put on hold for a few weeks. I have a business trip coming up, so I promised myself to leave well enough alone until I get back. I'll be trying all the suggestions here then.
I do appreciate all the helpful responses. This is my first serious foray into a BSD-based system. I mistakenly assumed that FreeBSD's firewall (ipfw?) and Linux iptables, while they may be configured differently, operated essentially the same way. I now know better. I usually don't make mistakes like that.
-
As I stated in my response above, despite being "beta", it seems logical to assume that the firewall in PFsense from 1.2.3 to the 2.0 Beta would operate essentially the same. If NAT forwarding of SIP worked in 1.2.3, why would it suddenly be broken in 2.0? And, if that assumption is wrong, then consider this a trouble report to the developers ;^)
A lot of things changed under the hood, no assumption is safe, even in the firewall area. However, your last point is correct: If it worked in 1.2.3 and not in 2.0, it's a regression an should be treated as a bug. Defaults have changed in some regards though. Upgraded configurations should not regress in functionality, but new configurations may need to be done slightly different in some areas.
You're right, as I told louis-m, I goofed. I've been working with computers a long time, I should have known better. Thanks for your help.
-
A top ranking Canadian Air Force Colonel whose long time flight assignment to fly Queen Elisabeth, The Canadian Prime Minister and other dignitaries was arrested for Murder, Forced confinement, and Rape.
Still think you goofed?
-
Hi Mitch,
You will solve the problem by simply doing the following:
Firewall > NAT > Outbound > Select "Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))" > Then make sure the following rule is located in the table below:
Interface > WAN
Source > Your Internal LAN Subnet
Source Port > *
Destination > *
Destination Port > *
NAT Address > *
NAT Port > *
Static Port > YESI have the exact same setup and has the exact same problem, I almost pulled my hair out until a friend showed me the light! :)
Cheers,
Andy
-
I also have the following ports open for TrixBox (Asterisk):
TCP/UDP - 5060
UDP - 6000 > 60000
TCP/UDP - 5061 > 5082Eveything works a dream for me :)
Any questions just ask!
Cheers,
Andy
-
A top ranking Canadian Air Force Colonel whose long time flight assignment to fly Queen Elisabeth, The Canadian Prime Minister and other dignitaries was arrested for Murder, Forced confinement, and Rape.
Still think you goofed?
Wow.
Yeah, but with a little 'g'…
That's a BIG 'G' Goofed!
Thanks for keeping it in context ;^)
-
I know it's been a few months, but wanted to follow-up for closure. Been waiting for Christmas break.
Your changes worked great! Thanks, again.
Hi Mitch,
You will solve the problem by simply doing the following:
Firewall > NAT > Outbound > Select "Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))" > Then make sure the following rule is located in the table below:
Interface > WAN
Source > Your Internal LAN Subnet
Source Port > *
Destination > *
Destination Port > *
NAT Address > *
NAT Port > *
Static Port > YESI have the exact same setup and has the exact same problem, I almost pulled my hair out until a friend showed me the light! :)
Cheers,
Andy
