I have a virtual network under “Bridged & Security Groups” mode.
I have a VM with an IP address 185.113.128.31 and an aliased IP address 185.113.128.32.
I am unable to ping from the aliased IP address even though everything appears to be configured correctly. I can ping from the .31 IP address just fine.
From what I can tell, the problem appears to be with ipset.
My iptables rules for this particular VM are:
Chain opennebula (1 references)
target prot opt source destination
one-22-1-o all -- 185.113.128.32 0.0.0.0/0 PHYSDEV match --physdev-in one-22-0 --physdev-is-bridged
one-22-1-i all -- 0.0.0.0/0 185.113.128.32 PHYSDEV match --physdev-out one-22-0 --physdev-is-bridged
one-22-0-o all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in one-22-0 --physdev-is-bridged
one-22-0-i all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out one-22-0 --physdev-is-bridged
Which makes sense. The outbound chain in question is:
Chain one-22-1-o (1 references)
target prot opt source destination
RETURN udp -- 0.0.0.0 255.255.255.255 udp spt:68 dpt:67
DROP all -- 0.0.0.0/0 0.0.0.0/0 ! match-set one-22-1-ip-spoofing src
RETURN all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RETURN all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
Which also makes sense. However, the match-set argument for this (via ipset list) is:
# ipset list one-22-0-ip-spoofing
Name: one-22-0-ip-spoofing
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 296
References: 1
Number of entries: 1
Members:
185.113.128.31
From the above, it appears to be missing the aliased IP address.
If I run ipset add one-22-0-ip-spoofing 185.113.128.32 then I can ping from the IP address correctly.
I’ve given it a bit of a bodge-test in my environment, just replacing the affected .rb file which I hope is enough. I think there’s still an issue though.
From what I can see, this now correctly creates a load of rules in the opennebula chain, e.g.:
Chain opennebula (1 references)
num pkts bytes target prot opt in out source destination
1 280 14442 one-32-2-o all -- * * 185.113.129.159 0.0.0.0/0 PHYSDEV match --physdev-in one-32-0 --physdev-is-bridged
2 337 16851 one-32-2-i all -- * * 0.0.0.0/0 185.113.129.159 PHYSDEV match --physdev-out one-32-0 --physdev-is-bridged
3 2273 181K one-32-1-o all -- * * 185.113.129.158 0.0.0.0/0 PHYSDEV match --physdev-in one-32-0 --physdev-is-bridged
4 272 13351 one-32-1-i all -- * * 0.0.0.0/0 185.113.129.158 PHYSDEV match --physdev-out one-32-0 --physdev-is-bridged
5 3477 262K one-32-0-o all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in one-32-0 --physdev-is-bridged
6 2221 254K one-32-0-i all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out one-32-0 --physdev-is-bridged
Outbound packets from 185.113.129.158 correctly skip rules 1 and 2, and enter the chain referenced in the third rule, one-32-1-o. They then correctly pass the match-set in that chain and hits the RETURN target.
However, the packet continues to traverse the opennebula chain, skipping rule 4 and hitting rule 5, which is the one-32-0-o chain:
Chain one-32-0-o (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 MAC !02:00:b9:71:00:01
2 0 0 RETURN udp -- * * 0.0.0.0 255.255.255.255 udp spt:68 dpt:67
3 2771 217K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set one-32-0-ip-spoofing src
4 751 52475 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
5 338 22913 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
6 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Of course, the one-32-0-ip-spoofing set just contains the primary IP address:
Name: one-32-0-ip-spoofing
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 248
References: 1
Number of entries: 1
Members:
185.113.129.157
And because this doesn’t match, the packet is dropped.
What are your thoughts? Is there still a bug remaining?
Thanks for that. I didn’t know about the synchronisation script - I assumed the SSH connection did the firewall rules.
Using both the update security_groups_iptables.rb and command.rb ended up with deployments totally failing.
Honestly, this could be due to anything as I’m well aware I’m cherry picking two files that are probably related to a whole load of other files in the git HEAD so I’ll back off with this one, at least until this goes into a community release.
