Iptables mystery for linux newbie

I've got a Ubuntu (latest build) box at Rackspace which is running the telephony app Asterisk. This is working fine. I cloned it and the clone's Asterisk wouldn't let any phone registrations through.
Someone suggested turning off the iptables, and lo and behold,  it worked.
The iptables were cloned, why would they behave differently?
(the iptables were originally setup by someone who knew what they were doing-unlike me!, so i'd like to re-instate them but I don't know what stopped working)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Blind guessing here. Don't really know the answer, but I am assuming some parameter changed in the clone that the iptables scripts are using? For instance, if there are several NICs available, and the iptables scripts are depending on certain traffic for eth0 and other traffic for eth1, and these somehow now are named opposite of what they were in the original, but connected to the same networks, then the rules would be handeling the wrong interfaces.

For instance:
iptables -A INPUT -p tcp --dport 22 -i eth0 -j ACCEPT

Open in new window

Would then have to be changed to:
iptables -A INPUT -p tcp --dport 22 -i eth1 -j ACCEPT

Open in new window

I have no idea what parameter has changed in your clone. You would have to read your iptables script and debug it. Test portions of it and see how it works out.
I guess you could check /etc/udev/rules.d/70-persistent-net.rules to see the naming of the cards, if that would be the case.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Silas2Author Commented:
These are virtual servers so they don't have their own NIC cards, i'm guessing they must have the same form..
Silas2Author Commented:
Actually, thanks for your help. I think that solved it, I asked Rackspace if there was anyway the NIC cards could appear differently, then they admitted that when you clone a server, unless you tick the 'unsubscribe' box to monitoring, they add a ton of iptable rules, and when I compared the rules in the working server, there was only a couple.
Nice. If I remember correctly I had a similar problem once. In that case the clone still had the udev rules from the original, but thought its virtual nics were different ones and therefore generated new names and put them in the persistent net rules(/etc/udev/rules.d/70-persistent-net.rules). I think because the clone got new mac addresses for his nics, then then original had. So then then the iptable rules no longer matched the nic names.

If you see this article here (you almost have to have javascript enabled to view that page):

You will see a script at the end that prepares a Centos VM to be a template for further deployment. One of the things that the script does is to remove the udev rules (rm -rf /etc/udev/rules.d/70-persistent-net.rules) so that the problem I described above does not happen. Doing so is fine for a template, but not necessarily a good idea for your original.
Silas2Author Commented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.