I have discovered an interesting problem: one of my users has a private VNet created from a VNet template which has FILTER_IP_SPOOFING=yes. The problem is that the antispoofing rules are applied even to the router of that network (an ordinary VM with two network interfaces), so the router cannot send routed packets to that network, as they obviously violate the IP spoofing rule. Can FILTER_IP_SPOOFING be selectively disabled for one VM or one NIC of that VM only? Or should that router VM be marked as a virtual router in its template?
When I - as oneadmin - disable the FILTER_IP_SPOOFING parameter, the routed traffic starts coming through (after re-plugging all the interfaces to it, of course). However, when the user wants to do the same, the VNet enters the ERROR state.
When an ordinary user (an owner of a VNet) does Vnet → Update → Conf → Uncheck “IP spoofing filter” → Update, the VNet enters the ERROR state. This is clearly a bug and should be fixed.
The other question is, why the VNet/FILTER_IP_SPOOFING and VNet/FILTER_MAC_SPOOFING are restricted parameters at all? What could go wrong if the VNet owner can set up his own rules for that VNet?
OK, thanks for the report, We’ll double check that.
As for the IP_SPOOFING, it is a configuration parameter. Usually enforcing secure settings is a good practice. So if the admin decides that the VNET is not a trusted environment, and MAC spoofing should be enforced; an user should not be able to change the parameter.
If that is not your scenario, you can remove it from oned.conf. Note that oned.conf includes presets we consider reasonable in general; but for sure may be tuned for particular setups.
I think it’s not directly related to restricted attributes. I found a case where the network switch to ERROR state after empty network update from Sunstone. Link to GitHub issue.
If this is not your case, can you please share the output of onevnet show <id> and the error message in oned.log, which is generated after the network update