"source-group" option in euca-authorize does not function

[Rohit Karajgi]

On specifying the -o <source_group_name> or --source-group=<source_group_name> option with euca-authorize, the traffic from the source group specified should be authorized and a corresponding rule entry be created in iptables. Currently this does not seem to be the case.

Steps to Test:-
1) Launch one VM instance
2) Associate floating ip address, say '10.2.3.96' to the VM instance
3) Add security group, say 'icmpgroup'

    $euca-add-group icmpgroup -d "test group"

4) Add rule to allow access from 10.2.3.0/24 for ICMP for icmpgroup security group

    $euca-authorize -P icmp -t -1:-1 -s 10.2.3.0/24 icmpgroup

5) Add rule by specifying icmpgroup security group using -o parameter to allow access to default group

    $euca-authorize -P icmp -t -1:-1 -o icmpgroup default

6) check if everything is added properly or now using euca-describe-groups

    root@ubuntu-openstack-network-api-server:/home/tpatil# euca-describe-groups
    GROUP admin default default
    PERMISSION admin default ALLOWS icmp -1 -1 GRPNAME icmpgroup
    GROUP admin icmpgroup test group
    PERMISSION admin icmpgroup ALLOWS icmp -1 -1 FROM CIDR 10.2.3.0/24
It looks good till now.

7) Try to ping to the VM instance using floating ip address 10.2.3.96.
    Ping is NOT successful.

To verify if icmp rule is added properly or not, I checked the iptables on the compute node and found out that the icmp rules wasn't added.
Compute node iptables
-----------------------------------

root@ubuntu-openstack-compute-01:~# iptables -n -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
nova-compute-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination
nova-filter-top all -- 0.0.0.0/0 0.0.0.0/0
nova-compute-FORWARD all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
nova-filter-top all -- 0.0.0.0/0 0.0.0.0/0
nova-compute-OUTPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain nova-compute-FORWARD (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain nova-compute-INPUT (1 references)
target prot opt source destination

Chain nova-compute-OUTPUT (1 references)
target prot opt source destination

Chain nova-compute-inst-260 (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT udp -- 10.0.0.1 0.0.0.0/0 udp spt:67 dpt:68
ACCEPT all -- 10.0.0.0/27 0.0.0.0/0
nova-compute-sg-fallback all -- 0.0.0.0/0 0.0.0.0/0

Chain nova-compute-local (1 references)
target prot opt source destination
nova-compute-inst-260 all -- 0.0.0.0/0 10.0.0.4

Chain nova-compute-sg-fallback (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain nova-filter-top (2 references)
target prot opt source destination
nova-compute-local all -- 0.0.0.0/0 0.0.0.0/0

[Kevin Bringard (kbringard)]

I've experience this issue as well. It's not just with floating IPs. If you have --allow_project_net_traffic=false VMs in the same project cannot talk to each other unless explicitly allowed by IP, even on their DHCP assigned addresses. It appears to be the same issue (source group chain is not applied)