As root, I get this result. Also, during IPL/ boot there appear to be 20 calls this that each get "permission denied." It takes an inordinately long time for initial boot, then everything seems to be fine. I recently 'upgraded' to 10.0-OSS from 9.3.

ls -l /sbin/iptables

it is possible that your system has been configured so only a firewall frontend can access this. Alternatively, something went amiss with the "upgrade". Usually it is better to backup and clean-install.

On my system it is:
/bin/ls: /usr/sbin/iptables: Permission denied.

I should have backed up and done a clean install; I may wait and do it with 10.1. I thought that root cannot be blocked from anything. THANKS

/usr/sbin # ll|more
/bin/ls: ip6tables-save: Permission denied
/bin/ls: iptables-save: Permission denied
/bin/ls: iptables-restore: Permission denied
/bin/ls: iptables: Permission denied
/bin/ls: xfs_admin: Permission denied
/bin/ls: ip6tables-restore: Permission denied
/bin/ls: xfs_bmap: Permission denied
/bin/ls: iptables-batch: Permission denied

Other files are '-rwxr-xr-x'...including:

-rwxr-xr-x 1 root root 44392 Sep 13 2005 ip6tables
-rwxr-xr-x 1 root root 48272 Sep 13 2005 ip6tables-batch
-rw-r--r-- 1 root root 48400 Mar 20 22:21 ip6tables-restore;441f7ecd
-rw-r--r-- 1 root root 48400 Mar 20 22:21 ip6tables-restore;441f7f40

SuSE sticks iptables in /usr/sbin/ does it?

Hmmm... that would suggest you have r/x permission for the directory. There's always the despirate, as root,

chmod 755 /usr/sbin/iptables

another is to check what groups root belongs to. (One of the troubles with the FC4 upgrade was that all users had no group membership, it may be the same here.)

The simplest fix is a reinstall - or at least, reinstall iptables.

And, yes, even root can be blocked.
I think I saw an example where the permissions were set to a group that root didn't belong to withowner and other permissions removed.