Comment 0 for bug 1833175

I have a VM with pptp vpn installed, and the vpn server is running. And I use security group rules like this:
# neutron security-group-rule-create --protocol tcp --port-range-min 0 --port-range-max 65535 --remote-ip-prefix 0.0.0.0/0 --direction ingress all
# neutron security-group-rule-create --protocol 47 --port-range-min 0 --port-range-max 65535 --remote-ip-prefix 0.0.0.0/0 --direction egress all
# neutron security-group-rule-create --protocol 47 --port-range-min 0 --port-range-max 65535 --remote-ip-prefix 0.0.0.0/0 --direction ingress all

Then I create a new VM to connect with vpn server, but seems there is a problem in the connectivity that no reply from the vpn server. I captured the vpn server's tap device with tcpdump, the information like this:
16:09:15.486548 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 4, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
16:09:18.490483 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 5, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
16:09:21.494344 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 6, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
16:09:24.498097 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 7, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
16:09:27.501446 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 8, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
16:09:30.504937 fa:16:3e:26:7f:fe > fa:16:3e:e2:bd:f9, ethertype IPv4 (0x0800), length 75: 192.168.111.57 > 192.168.111.45: GREv1, call 0, seq 9, proto PPP (0x880b), length 41: LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27

Seems the vpn server has replied the packet, but these packets are dropped somewhere. After some investigation, I found the packets are set to mark=1:
47,orig=(src=192.168.111.57,dst=192.168.111.45,sport=3840,dport=0),reply=(src=192.168.111.45,dst=192.168.111.57,sport=0,dport=3840),zone=2,mark=1

This flow set the incoming packet to mark=1:
 cookie=0x8bbcb4f28e827fee, duration=81.097s, table=82, n_packets=2, n_bytes=158, idle_age=1, priority=40,ct_state=+est,ip,reg5=0x23 actions=ct(commit,zone=NXM_NX_REG6[0..15],exec(load:0x1->NXM_NX_CT_MARK[]))

When I add 2 flows into br-int, the connectivity will be normal:
cookie=0x90b502a419df13a0, duration=0.477s, table=72, n_packets=0, n_bytes=0, idle_age=115, priority=70,ct_state=+est,ip,reg5=0x23,nw_proto=47 actions=resubmit(,73)
cookie=0x90b502a419df13a0, duration=0.450s, table=82, n_packets=0, n_bytes=0, idle_age=115, priority=70,ct_state=+est,ip,reg5=0x23,nw_proto=47 actions=NORMAL

Because pptp vpn is based on Grev1, I think there is a problem with Grev1.

BTW, if I create gre tunnel between VMs, the connectivity between them is also OK. The gre tunnel is based on Grev0, so seems there is no problem with Grev0.