← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #78937

[Bug 1833175] [NEW] pptp vpn doesn't work with openvswitch firewall

  Thread Previous • Date Previous • • Thread Next 
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
  Thread Previous • Date Previous • • Thread Next