View filter logs in sunstone gui for security groups to debug them?

There haven’t been other questions already asked on this.

I can’t find any interface options to let me see the filter logs of Open Nebula security groups. Is there any such capabilities?

I had a misconfigured rule that was killing routing between two of our services and I had no viewpoint into what was happening from the server side, KVM node side, nor open nebula webgui.

What is the intended method to find and fix issues like these in Open Nebula?

hi Sam, I think you are expecting to find functionality in the wrong place;
Opennebula is a wrapper around existing software. So it depends if you use KVM with IPtables, or VXlan, or a combination of VMware with other network options. Depending on what tech lies below the functionality that opennebula offers, the option to debug and see logs will differ.
So, for troubleshooting issues, check the iptables logs or the default log location for whatever tech is in use.

1 Like

Hey thanks for the response. I was hoping there might be a way to view the iptables logs just like there is a management log location for open nebula in sunstone when you click the “Logs” tab at the very least. Sounds like this is not a thing, nor is there tooling for doing so provided by opennebula?

Ideally I’d prefer to not have to have host level access to the node servers to view the iptables logs to debug security groups which could be configured by another user that should not have system access for an opennebula node.

I kinda like the keep-it-simple approach OpenNebula uses. Assuming you use linux/kvm/iptables, opennebula creates a iptables chain and just adds rules defined, like the ones defined in security groups, ip and mac spoofing. Normally you wouldnt even have to troubleshoot iptables issues and leave opennebula to manage all that (and keep it simple).
If only opennebula manages the rules, you get an incoming and outgoing chain, filled with iptables rules. the VM log will stay part of the VM, even if you move it to another host, but iptables logs and rules are a network and linux kernel level thing, so they stick to the host the VM is running on.

Opennebula does move the iptables rules with the VM BTW, so if you move a VM to a different host, the iptables chains will be automatically removed on the old host and applied to the VM on the new host.

Here is an example of iptables rules applied to a random VM on opennebula, with VM id 37, and IP spoofing and mac spoofing rules enabled, without nyy security groups applied:

Chain one-37-0-i (1 references)
 pkts bytes target     prot opt in     out     source               destination         
5814M   27T RETURN     all  --  *      *              state RELATED,ESTABLISHED
  45M 6317M RETURN     all  --  *      *             
    0     0 DROP       all  --  *      *             

Chain one-37-0-o (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *              MAC ! 02:00:C0:A8:B2:80
    0     0 RETURN     udp  --  *      *          udp spt:68 dpt:67
    0     0 DROP       all  --  *      *              ! match-set one-37-0-ip-spoofing src
6464M 5278G RETURN     all  --  *      *              state RELATED,ESTABLISHED
  26M 2354M RETURN     all  --  *      *             
    0     0 DROP       all  --  *      *        

Is there a way to have access to these logs without giving someone host level access on the node though?

I’ve got about 20 people using this thing and I don’t trust them all to not break the node if they had that level of access on it, and I would like to not be the point of failure going forward on debugging the network configuration issues.

I wouldnt touch the configuration of the iptables rules at all, and let opennebula manage it. If you or users want to configure stuff related to the FW rules, use the security groups.

You can configure iptables to log to a specific log-file, like /var/log/iptables and have a service gather all those logs to a central place and make them available that way. (syslog, rsyslog, lots of options for it)