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