Replacing IPCop 1.4.21 with pfSense 2.0Beta
-
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
