Bug #5344

VM with ipv6 (Error in ip6tables chain)

Added by Tobias Rehn about 1 month ago. Updated about 1 month ago.

Status:ClosedStart date:09/05/2017
Priority:HighDue date:
Assignee:Vlastimil Holer% Done:

0%

Category:Drivers - Network
Target version:Release 5.4.1
Resolution:fixed Pull request:
Affected Versions:OpenNebula 5.4

Description

We have started to deploy VMs with IPv6 addresses and found out that the VMs were not pingable. After some further researching we found out, that there is a superfluous rule in the chain for the outgoing packets of the VM interface:

Example for VM with ID 74:

Chain one-74-0-i (1 references)
target prot opt source destination
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-advertisement
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp redirect
ACCEPT all anywhere anywhere state RELATED,ESTABLISHED
RETURN all anywhere anywhere
DROP all anywhere anywhere

Chain one-74-0-o (1 references)
target prot opt source destination
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement
DROP all anywhere anywhere MAC ! 02:00:3E:71:C5:02
DROP all anywhere anywhere
ACCEPT all anywhere anywhere state RELATED,ESTABLISHED
RETURN all anywhere anywhere
DROP all anywhere anywhere

We are using the default security group, so we are not limiting any traffic via firewall.

I have underlined the wrong line.

Associated revisions

Revision 8faf007f
Added by Vlastimil Holer about 1 month ago

B #5344: Set IP spoofing filter also for static IPv6

Revision 7eae5ca5
Added by Vlastimil Holer about 1 month ago

B #5344: Set IP spoofing filter also for static IPv6

(cherry picked from commit 8faf007f3c02b5e01f45a34e953f26ce3af6d18b)

History

#1 Updated by Ruben S. Montero about 1 month ago

  • Assignee set to Vlastimil Holer

#2 Updated by Vlastimil Holer about 1 month ago

Hello Tobias,

IP spoofing protection works only if the IP addresses are managed (assigned) by the OpenNebula. You must have IPv4/6 or IPv6 address ranges in your network, OpenNebula selects the appropriate IP for the VM and configures the anti-spoofing rules via iptables/ipset. As you point to the "DROP all anywhere anywhere", I guess you use only Ethernet ranges. IP spoofing protection can't work in this case and has to be disabled, there is no autolearning from the VM's traffic. You have to set FILTER_IP_SPOOFING=no in the attributes of your virtual network.

I can't reproduce the problem with correct IPv4/6 ranges. If your configuration follows the previous requirements and still misbehaves, we would need you to provide more details about your virtual network and virtual machine configuration. Outputs of

$ onevnet show $ID --xml
$ onevm show $ID --xml

Please, obfuscate any sensitive information. You can also use direct e-mail if you prefer.

Best regards,
Vlastimil Holer

#3 Updated by Tobias Rehn about 1 month ago

Hello Vlastimil,

thank you for your reply. I am not using Ethernet ranges - I am using a real mixed IPv4/IPv6 range managed by OpenNebula. So far IPv4 is working without any problems. IPv6 just has the problem that I have this DROP rule in the output chain for the vm interface. For my understanding it should be the final statement and not at position 5. The problem exists for every VM created.

I have just emailed you the outputs of the two commands. They are not obfuscated so you have the real data.

If you need more input just get back to me.

#4 Updated by Vlastimil Holer about 1 month ago

Hello Tobias,

I can see the problem; it's related to the static IPv6 introduced in the ONE 5.4. Filters work fine with old IPv6 SLAAC addresses. The fix will be part of the upcoming 5.4.1 bugfix release. If you need to workaround the problem on your infrastructure now, you can check the change https://github.com/OpenNebula/one/pull/451/files and apply on your scripts and synchronize the scripts on the nodes.

Thank you for your bug report and for the metadata!

Best regards,
Vlastimil Holer

#5 Updated by Tobias Rehn about 1 month ago

Hey Vlastimil,

No problem. I also have to thank you for fixing so fast.

Have a nice day.

#6 Updated by Tobias Rehn about 1 month ago

Hello Vlastimil,

bad news. I just applied your patch and tested. The same rule still exists for newly created VMs:

Chain one-90-0-o (1 references)
target prot opt source destination
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement
DROP all anywhere anywhere MAC ! 02:00:3E:71:C5:09
DROP all anywhere anywhere
ACCEPT all anywhere anywhere state RELATED,ESTABLISHED
RETURN all anywhere anywhere
DROP all anywhere anywhere

Does not work :(

#7 Updated by Vlastimil Holer about 1 month ago

Tobias, are you sure the change is really distributed also on your hypervisors?
For a quick check, look into /var/tmp/one/vnm/security_groups_iptables.rb on some node.

Best regards,
Vlastimil Holer

#8 Updated by Tobias Rehn about 1 month ago

Ok, great. Didn't know they were cached on the hypervisors. It is now working as expected.

#9 Updated by Vlastimil Holer about 1 month ago

  • Status changed from Pending to Closed
  • Resolution set to fixed

Also available in: Atom PDF