Ask Your Question
0

Why instances GRE tunnel packets into Openstack/neutron are dropped ?

asked 2015-04-27 07:37:01 -0500

darthdragon gravatar image

updated 2015-04-28 08:13:42 -0500

Hi,

I'm using Openstack on Jessie Debian with neutron network (with ML2, L3_router and Openvswitch).

I have launched two instances of a Linux Debian on the same compute node. Both can ping each other and contact through SSH.

I use a "no security" secgroup:

root@cloud-controller-node:~# neutron security-group-show nosec
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field                | Value                                                                                                                                                                                                                                                                                                                                 |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| description          | No security                                                                                                                                                                                                                                                                                                                           |
| id                   | 5d3bd127-bf00-4417-9362-364f54addef4                                                                                                                                                                                                                                                                                                  |
| name                 | nosec                                                                                                                                                                                                                                                                                                                                 |
| security_group_rules | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "861c5516a7944f3f87569f9a13ef78ee", "port_range_max": null, "security_group_id": "5d3bd127-bf00-4417-9362-364f54addef4", "port_range_min": null, "ethertype": "IPv4", "id": "05a3bcd9-0dcf-450e-bf72-dd8ba430b546"}         |
|                      | {"remote_group_id": null, "direction": "ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": null, "tenant_id": "861c5516a7944f3f87569f9a13ef78ee", "port_range_max": null, "security_group_id": "5d3bd127-bf00-4417-9362-364f54addef4", "port_range_min": null, "ethertype": "IPv4", "id": "7c0b23e5-907b-4b10-aaa1-caf56b5d481a"} |
|                      | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "861c5516a7944f3f87569f9a13ef78ee", "port_range_max": null, "security_group_id": "5d3bd127-bf00-4417-9362-364f54addef4", "port_range_min": null, "ethertype": "IPv6", "id": "ddb8c76d-81d3-405f-8168-1c3ddfff0c8a"}         |
| tenant_id            | 861c5516a7944f3f87569f9a13ef78ee                                                                                                                                                                                                                                                                                                      |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Under each Linux instance I configure a GRE tunnel:

On "client" instance:

  ip tunnel add netb mode gre remote 192.168.2.10 local 192.168.2.11 ttl 255
  ip link set netb up
  ip addr add 192.168.2.11 dev netb
  ip route add default dev netb

And the peer "server" instance:

  ip tunnel add netb mode gre remote 192.168.2.11 local 192.168.2.10 ttl 255
  ip link set netb up
  ip addr add 192.168.2.10 dev netb

When I ping from my "client", I can see my encapsulated ping request in the GRE tunnel in the corresponding TAP and BRIDGE interface on my compute-node. But not on any other interfaces, so nothing goes to the "server" instance:

root@openstack2:~# brctl show qbra2788e60-ae
bridge name bridge id       STP enabled interfaces
qbra2788e60-ae      8000.ee577b13799c   no      qvba2788e60-ae
                            tapa2788e60-ae
root@openstack2:~# tcpdump -n -i tapa2788e60-ae
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tapa2788e60-ae, link-type EN10MB (Ethernet), capture size 262144 bytes
11:55:33.562599 IP 192.168.2.11 > 192.168.2.10: GREv0, length 88: IP 192.168.2.11 > 8.8.8.8: ICMP echo request, id 4128, seq 1, length 64

root@openstack2:~# tcpdump -n -i qbra2788e60-ae
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on qbra2788e60-ae, link-type EN10MB (Ethernet), capture size 262144 bytes
11:57:00.203464 IP 192.168.2.11 > 192.168.2.10: GREv0, length 88: IP 192.168.2.11 > 8.8.8.8: ICMP echo request, id 4129, seq 1, length 64

I verify the firewall rules on my compute node, packets ARE dropped:

root@openstack2:~# iptables-save -c | grep a2788e60 | grep DROP
[0:0] -A neutron-openvswi-ia2788e60-a -m state --state INVALID -j DROP
[0:0] -A neutron-openvswi-oa2788e60-a -p udp -m udp --sport 67 --dport 68 -j DROP
[426:46008] -A neutron-openvswi-oa2788e60-a -m state --state INVALID -j DROP
[0:0] -A neutron-openvswi-sa2788e60-a -j DROP

The MAC addresses in my GRE packet are correct.

So does anybody know why my internal GRE communication is seen as INVALID by the firewall ?

Thanks.

edit retag flag offensive close merge delete

Comments

Interesting, I'm not sure how GRE (IP protocol 47) is handled by the iptables rules. Can you try using vxlan instead - it's just UDP. Also make the MTU of the device small enough so the packets will fit.

darragh-oreilly gravatar imagedarragh-oreilly ( 2015-04-27 14:44:19 -0500 )edit

Hi, my "client" and "server" machine don't support vxlan :-( And I have trouble upgrading them.

But after a reboot to start all from a clean point, in fact I made an error, some packets are dropped (I update my original request accordingly).

darthdragon gravatar imagedarthdragon ( 2015-04-28 07:32:03 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
1

answered 2015-04-28 10:46:52 -0500

darthdragon gravatar image

Ok find it, must load the nf_conntrack_proto_gre kernel module and everything is fine.

edit flag offensive delete link more

Comments

if any of the rules of your rule-set use the state or ctstate iptables matches, you are indeed using it.

bishoy gravatar imagebishoy ( 2015-04-28 11:28:29 -0500 )edit

i'm running into the same issue. I'm using openstack with vxlan tunnels and i wanna set gre tunnel between two of my VMs.But when I do a tcpdump on my qbr and tap devices i don't see any flow comming out. Can you please tell me how did you manage to get your installation working?

ichi-the-one gravatar imageichi-the-one ( 2015-06-05 06:30:51 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2015-04-27 05:21:37 -0500

Seen: 1,130 times

Last updated: Apr 28 '15