Creation of ICMPV6 rule through horizon is treating as invalid packet

Bug #1652619 reported by mahesh on 2016-12-26
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Medium
Radomir Dopieralski
neutron
Undecided
Unassigned

Bug Description

Go to the dashboard and select the access and security for admin role
1.Create a Security Group say SG1
2.Select the manage rule for security Group SG1
3.Click on ALL icmp and select the CIDR AS ::/0 for ingress and egress rule
4.Associate to the VMs
5.try to ping its treating as invalid because while creating the rule for ethertype=ipv6 as icmp

Please refer the snapshot for your reference

Note : Same configuration through CLI works fine.
example :
neutron security-group-rule-create --protocol icmpv6 --direction egress --ethertype IPv6 SG1
neutron security-group-rule-create --protocol icmpv6 --direction ingress --ethertype IPv6 SG1

After executing above command and its showing as icmpv6 in dashboard and its works fine.

This issue is seen in stable/mitaka branch.

mahesh (maheshloni) wrote :

Fix proposed to branch: master
Review: https://review.openstack.org/473481

Changed in horizon:
assignee: nobody → Radomir Dopieralski (deshipu)
status: New → In Progress
Radomir Dopieralski (deshipu) wrote :

Please note that users have always been able to create ICMPV6 rules by selecting "Other protocol" and specifying the "IP protocol" field value as "58".

Akihiro Motoki (amotoki) wrote :

The neutron security group allows 'icmp' for both IPv4 and IPv6. We can distinguish IPv4 and IPv6 based on 'ethertype' field.
You specify ethertype == IPv6 and protocol 'icmp', but IPv6 ICMP is not allowed, it should be a bug in neutron.
As my hat of neutron team, we didn't change the behavior (at least it is not intentional).

I don't think it is a horizon bug.

Akihiro Motoki (amotoki) wrote :

I added neutron as affected project.

I created a new security group named 'sg1' and then add a new rule by selecting "All ICMP" and specifying "::/0" as CIDR.
After that I see the following security group rules: http://paste.openstack.org/show/612436/

In the neutron API, we consider 'icmp' protocol with 'IPv6' ethertype as ICMPv6 packets (from the beginning) and in my understanding we haven't changed the behavior. I think it is a bug in neutron (if true). I haven't tried to reproduce it though.

Akihiro Motoki (amotoki) wrote :

@mahesh
What happens if you create a security group rule with protocol icmp from CLI?
I would like to clarify this is a neutron issue or horizon side.

neutron security-group-rule-create --protocol icmp --direction egress --ethertype IPv6 SG1
neutron security-group-rule-create --protocol icmp --direction ingress --ethertype IPv6 SG1

As the design of neutron API, it should work in the same way as when specifying --protocol icmpv6 or --protocol ipv6-icmp.

Radomir Dopieralski (deshipu) wrote :

Well, if you do the equivalent of "neutron security-group-rule-create --protocol icmp --direction ingress --ethertype IPv6 SG1" from Horizon, the ip_protocol ends up being set to "icmp". However, if you do "neutron security-group-rule-create --protocol 58 --direction ingress --ethertype IPv6 SG1" (using the "custom protocol" option, you get the correct ip_protocol set to "icmpv6".

Radomir Dopieralski (deshipu) wrote :

@amatoki
This:
neutron security-group-rule-create --protocol icmp --direction egress --ethertype IPv6 SG1

Results in this being displayed by Horizon:

    Direction Ether Type IP Protocol Port Range Remote IP Prefix
    Egress IPv6 ICMP Any ::/0

Whereas this:

neutron security-group-rule-create --protocol icmpv6 --direction egress --ethertype IPv6 SG1

Results in a separate rule being added, reading:

    Direction Ether Type IP Protocol Port Range Remote IP Prefix
    Egress IPv6 ICMP Any ::/0
    Egress IPv6 ICMPV6 Any ::/0

Note, that if I try this:

neutron security-group-rule-create --protocol 58 --direction egress --ethertype IPv6 SG1

I get this error:

Security group rule already exists. Rule id is 4d125465-cbfa-4716-980b-fa2b85361243.

Which points to the ICMPV6 rule.

Brian Haley (brian-haley) wrote :

We are tracking a fix the neutron server with bug https://bugs.launchpad.net/neutron/+bug/1582500

When complete, the API will only accept 'ipv6-icmp' for IPv6 rules like this, and complain if either 'icmpv6' or 'icmp' is used. Horizon could start using that today to be consistent.

mahesh (maheshloni) wrote :

Akihiro,

Sorry for delay response :

looks like its neutron issues and after creating icmp rule from horizon and getting the following flow update in
neutron CLI prompt :

In CLI , getting the following output:
                                                         |
| | | ingress, IPv6, icmp, remote_ip_prefix: ::/0

but issue is occurring, when you send icmpv6 packets, security group is dropping the packet as invalid since flows are creating as icmpv6 but not as icmp.

BRs,
Mahesh Loni

Akihiro Motoki (amotoki) on 2017-10-07
tags: added: neutron
Akihiro Motoki (amotoki) wrote :

@mahesh,
sorry for late response. Precisely neutron should allow ICMPv6 packets if ethertype IPv6 and protocol ICMP is specified. This is the original intention and if the neutron behavior was changed somehow it should be fixed. The reason ICMPv6 was introduced is because ICMPv6 has a different type from ICMPv4, but the original behavior should be kept.

Akihiro Motoki (amotoki) wrote :

Summarizing the current situation....

there are two separate issues around this bug:

(1) In horizon side, ICMP with ethertype IPv6 actually does not work expectedly as reported here. It sounds reasonable to change the protocol type to 'ipv6-icmp' (or 'icmpv6' ) when ICMP is requested for IPv6 packets. If it addresses the problem reported here, it really sounds nice.

(2) neutron defines three variants for ICMPv6: icmp (with IPv6 ethertype), icmpv6, ipv6-icmp, and integer 58. 'ipv6-icmp' will be used as the standard one (as mentioned in #9). All variants should be handled equally and this is being tackled as bug 1582500.

Thus, I think this bug should focus on (1) and neutron is not related.
(2) should be tackled as part of bug 1582500.

Akihiro Motoki (amotoki) wrote :

On (2), neutron is still related. My previous comment was not correct on this point.

Akihiro Motoki (amotoki) on 2017-10-22
Changed in horizon:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers