iptables-save fails to write to file

I can run iptables-save and dump output to stdout but if I redirect to a file - the file is empty:

    [root@nhd-vlx2 tmp]# iptables-save  
    # Generated by iptables-save v1.4.7 on Sun Dec 18 15:11:42 2011
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [90971:17757587]
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
    -A INPUT -p icmp -j ACCEPT 
    -A INPUT -i lo -j ACCEPT 
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 9090:9999 -j ACCEPT 
    -A INPUT -j REJECT --reject-with icmp-host-prohibited 
    -A FORWARD -j REJECT --reject-with icmp-host-prohibited 
    COMMIT
    # Completed on Sun Dec 18 15:11:42 2011
    [root@nhd-vlx2 tmp]# iptables-save  > save
    [root@nhd-vlx2 tmp]# cat save
    [root@nhd-vlx2 tmp]# 
    [root@nhd-vlx2 tmp]# 

Piping works (iptables-save | cat), and so saving to file through tee works too, but why would iptables-save not allows saving to a file?

The only reason I can think is that this machine may be infected by a virus (an attempt to weaken a firewall)

Long shot, but:

Somebody else posted a similar problem in another forum. As it turns out, the SELinux context is wrong.

Run ls -laZ on iptables-multi. It should return with:

-rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /sbin/iptables-multi

All the other iptables files are symlinked to it:

[root@cacti tmp]# ls -laZ /sbin/iptables*
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables -> iptables-multi
-rwxr-xr-x. root root system_u:object_r:iptables_exec_t:s0 /sbin/iptables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-restore -> iptables-multi
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/iptables-save -> iptables-multi

If the SELinux context is not correct, change it with the chcon command on the main file:

chcon -u system_u -t iptables_exec_t /sbin/iptables-multi

If the SELinux context on the symlinks are not correct, fix them using the above command (although this time with the bin_t type)