Public bug reported:
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 fine. The gre tunnel is based on Grev0, so seems there is no problem
with Grev0.
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
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
+ 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[]))
+ 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.
+ is fine. The gre tunnel is based on Grev0, so seems there is no problem
+ with Grev0.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1833175
Title:
pptp vpn doesn't work with openvswitch firewall
Status in neutron:
New
Bug description:
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 fine. The gre tunnel is based on Grev0, so seems there is no
problem with Grev0.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1833175/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
