I realize the subject question is somewhat simplistic (or dumb), but let me explain:
My home-based Asterisk PBX box is behind a NAT (with public static adrs), but I wanted
to increase the security - so I started playing with fwbuilder (v 3.04 build 794 on Ubuntu
Intrepid ) since I didn't wish to delve into the iptables. By the way this is a great
product and effort. My router only forwards SIP udp port 5060 and rtp (ports 10000+),
and IAX2 udp port 4569 to the static IP Asterisk box.
Since my VOIP provider has all of his proxy servers at the same subnet and I register
TO his proxy, I figured I could stealth ALL my ports. So I installed FwBuilder on the
Asterisk box and manually execute the *.fw script and manually clear the iptables
so as not to reboot my phone system during the testing. Everything 'seems' to work
NOW THE PROBLEM:
I inserted the the firewall.fw script in the file /etc/rc.local to be
executed at boot-up. HOWEVER, after a reboot with this method, my outgoing "register"
signals are being blocked. If I then (without rebooting) empty the iptables and then
run my *.fw script manually, "register" signals are now unblocked and everything is OK..
Although the files displayed (via "iptables -t filter -n -L --line-numbers", and also
a command for the "mangle" tables) are indentical for both the "manual" method and
the "auto-boot" method, it's obvious something is different. Are there some iptables
that I'm not displaying to the screen with the above iptables commands?
Only user "root" has file permissions, by the way.
Do I HAVE to use the built-in Installer? I noticed in the recent pdf, "Using Built-in
Policy Installer in Firewall Builder" from Vadim Kurland that I CAN use ssh on the
same machine, but do I HAVE to? What is different with the two methods?
you do not have to use installer. The actual goal is to transfer generated .fw file to the firewall and run it there. Since you run fwbuilder GUI on the same machine, you can just run it there. It is not very convenient to have to do it by hand but its your choice.
As for why the firewall blocks your connections after reboot, probably it is because your firewall machine activates its own iptables script before or after rc.local runs. Script generated by fwbuilder should purge all iptables rules that might be there when it runs, so it should work if it runs after the default script.
When you say you empty the iptables and then run generated .fw script manually, how exactly do you empty iptables ?
To check and compare the state of iptables you can use commands
iptables -t filter -L -n
iptables -t mangle -L -n
iptables -t nat -L -n
You may want to disable standard default iptables setup on your firewall so that it does not interfere with the script generated by fwbuilder. I am not familiar with Asterisk configuration so I am not sure how to do that. If Asterisk is based on a RedHat-like Linux distribution, you would run "service iptables stop" "chkconfig --level 2345 iptables off" commands to turn it off. Since you call script generated by fwbuilder from rc.local, it will always run even if you use these commands to disable default system iptables script.
Last, but not least, I recommend you make sure option "Load modules" is turned on in the "Script" tab of the firewall object dialog.
Thanks for the response.
Answer to your question-
I empty the iptables with a script that has the 4 bash command lines:
for CHAIN in INPUT OUTPUT FORWARD ; do iptables -P $CHAIN ACCEPT ; done
In reading your response I thought of something that I have should have done in
the first place - I mentioned that I checked the firewall after a manual install and a
rc.local execution which resulted in no iptables difference. What I should have done
and will try is to write the iptables status just before and just after the *.fw script inside
the rc.local script.
I compile the Asterisk source (on Ubuntu Intrepid), so there is no (obvious)
firewall generated (by Asterisk) that would cause the "blocking". But, I will
try some further checking, and get back to you if I solve or further confuse
the problem. By the way, I haven't used the NAT rule(s), since I'm behind a
router. Planned on adding those when I move the Asterisk box to the DMZ.
Follow up to my previous email:
The good news is that the problem is gone because of what I did;
the bad news is that I don't have an exact idea of why. As I stated
in my previous email I inserted a write of the iptables (to a disk file)
just before and just after the *.fw script (inside the rc.local script).
My Asteris box was no longer blocking my retistration to the VOIP
provider. To make certain, when I commented out the "writes" (and
rebooted), I was again blocked. So I just put in a "sleep" of 2
seconds in place of the "writes", and everything with Asterisk is now
So, what do you think, a timing problem? Hardware? I do have a
dual core in this machine, and I would presume the boot process
uses both CPUs - or not?
what if you do not run .fw script at all, and then check the state of iptables using "iptables -t filter -L -n" command (and also for mangle and nat tables) ? If any rules get loaded, then you still have some other iptables script that gets activated at startup time in parallel with .fw script and your delay of 2 sec just fights this race condition
Answer to your last question:
In rc.local I ONLY wrote out (to a disk file) the 3 tables - no *.fw.
There were no additional rules in the iptables - just a table name
with the "ACCEPT" and in the next line just the column headings.
After logging in (after the reboot), I also displayed all 3 tables
and the results were exactly as what was displayed from the
rc.local script during the boot process. So, I'll stick with the
"sleep" commands in rc.local.
I have just finished another Asterisk box (on a different public IP)
that will peer to the current box over the IAX2 protocol: so if there
is any difference in behavior I'll let you know.
I don't think that Firewall Builder is causing the blocking effect,
but I do recall from somewhere that it does alter/modify some kernel
parameters. If it really does, I have a question concering this
aspect as it relates to the kernel IP routing table, but I'll start
a new thread for this topic.
Again, your GUI Firewall Builder is a great product, and I never
would have become involved with the iptables before - would
have just continued to rely on the router in front of the Asterisk
script created by fwbuilder loads iptables modules into the kernel. It does it at the very beginning, before any rules are added to tables. You need modules for stateful tracking of protocols, including SIP and others used for VOIP.
Script can also turn on/off ip forwarding in the kernel and few other parameters. You can find GUI controls for these in the "advanced" dialog for Linux os. Just hit the button "Host OS Settings" in the firewall object dialog.
However I would assume all these things would cause immediate and permanent breakage if they were configured in a wrong way. There must be something else that is working during boot time in parallel with rc.local and the delay you added to rc.local makes firewall policy activate slightly later, when this "other thing" has finished.
I noticed you said that default policy was ACCEPT in all chains. Perhaps you forgot to add a rule to permit some communication that firewall wants to do. So, if firewall has few seconds to do this something before your firewall script is activated, it works. But without delay it can;t do it. This is just a hypothesis of course.
Yes, I saw the Host OS options, but I didn't want to touch those without a better
understanding of their significance ( and don't want to break my phone system).
When I finish installing Asterisk on my other Ubuntu box, I'll feel better about trying
As to your last paragraph: I am probably using poor terminology regarding the
iptables (always relied on my router for the firewall). When I use the terms clear,
empty, no firewall, no rules, the expert iptables guy probably envisions different
things. Here's what my FILTER (and MANGLE & NAT) table looks like BEFORE I
run the firewall builder script:
FILTER TABLE CHAINS
Chain INPUT (policy ACCEPT)
num target prot opt source destination
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
The "ACCEPT" line is what I was referring to in my previous posting. So, is it
(in iptables "speak") correct to say I have no rules in my firewall? Or, I have no
firewall? Or, my firewall accepts all packets? Honestly, in the Asterisk forum
when iptables were used/suggested, I just tuned it out :-). Have learned more
about iptables in the last month, than I had anticipated.
this output from iptables -L means that you have no rules and default policies are ACCEPT. In other words, this is "no firewall", yes.
As a final note of interest in this topic, I finished installing Asterisk
in a 2nd Ubuntu Intrepid box, and, wouldn't you know, I don't have
the issue of being blocked on my registrations to the VOIP. So, I
don't need the "sleep" command in rc.local for this machine. One
might expect this since it will only talk peer-to-peer (IAX2) with the other
Asterisk box and not do any registrations!!
But the hardware is quite different (AMD quad-core Phenom II with
fast memory) and I have the latest (actually a release candidate)
version of the asterisk software. So, the timing is entirely different.
Thanks for your help,
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.