Bug 440986 - libvirt-0.4.1-2.fc8.x86_64/iptables/qemu/kvm not tunneling PPTP VPN protocols (GRE-proto-47 + TCP/IP-port-1723) as did previously
libvirt-0.4.1-2.fc8.x86_64/iptables/qemu/kvm not tunneling PPTP VPN protocols...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
8
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-04 16:00 EDT by Nathan Watson
Modified: 2008-04-04 19:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 18:09:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
yum update history for hosting FC9 Linux box (66.23 KB, text/plain)
2008-04-04 16:03 EDT, Nathan Watson
no flags Details

  None (edit)
Description Nathan Watson 2008-04-04 16:00:54 EDT
Description of problem:

  I have an x86_64 FC9 box that hosts (among other things)
  various Windows machines.  The Windows machines have an
  internal virtual network on 192.168.8.*.  One of the
  Windows machines, internally named "chefe.janelaz.com",
  has two network interfaces, one on 192.168.8.31 (on shared
  network with other Windows machines), and one interface on
  192.168.7.31 (the "public" interface to the outside world).

  The "chefe.janelaz.com" is a VPN gateway for the rest of
  this Windows network.  *** UP UNTIL 2008/04/02 WHEN MY
  "yum update" UPGRADED FROM "libvirt - 0.4.0-4.fc8.x86_64"
  TO "libvirt - 0.4.1-2.fc8.x86_64" IN MY SETUP OF THE COMPONENTS
  iptables/libvirt/qemu/kvm IT WAS POSSIBLE TO VPN TO THIS
  INTERNAL WINDOWS NETWORK FROM COMPLETELY OUTSIDE THE HOSTING
  WINDOWS BOX.  AS OF THE UPGRADE ON 2008/04/02 IT IS NOT LONGER
  POSSIBLE TO DO THIS. ***

  I will supply more details.  I'm also not sure whether there
  are additional Fedora components involved (e.g., 'kernel',
  tun/tap networks, other things I'm not intimately familiar
  with).  I will supply more info.

  NOTE THAT THIS WILL BE A PROBLEM NOT ONLY FOR THOSE DEPLOYING
  INTERNAL WINDOWS NETWORKS, BUT I ASSUME ALSO FOR THOSE
  DEPLOYING ANY INTERNAL ISOLATED VPN NETWORKS WITH 'pptp'
  TECHNOLOGY.

  The Windows VPN gateway in question is running under
  libvirt/qemu/kvm (i.e., hardware-accelerated) under Intel VT,
  and is an i386 (not x86_64) virtual machine.  This Windows
  machine last went through update on Microsoft "patch Tuesday"
  in 2008/03 (I believe 2008/03/10) and is known to have worked
  as a VPN gateway after that point.

Version-Release number of selected component (if applicable):

Versions of known involved components when working before 2008/04/02:

  Jan 22 16:52:20 Updated: libvirt - 0.4.0-4.fc8.x86_64
  Mar 03 04:13:54 Updated: qemu - 0.9.0-7.fc8.x86_64
  Mar 03 04:13:51 Updated: kvm - 60-3.fc8.x86_64
  Dec 05 09:14:58 Updated: iptables-ipv6 - 1.3.8-6.fc8.x86_64
  Mar 16 21:58:12 Installed: kernel - 2.6.24.3-34.fc8.x86_64

Updated versions of components where problem manifests 2008/04/02 and after:

  ... instance #1:
  Apr 02 22:52:17 Updated: libvirt - 0.4.1-2.fc8.x86_64
  Apr 02 22:54:47 Installed: kernel - 2.6.24.3-50.fc8.x86_64
  ... instance #2 (upgraded kernel):
  Apr 03 19:32:40 Installed: kernel - 2.6.24.4-64.fc8.x86_64

  (... note, this install is completely vanilla FC9, there are
  no specially compiled kernels or modules ...)

How reproducible:

  The problem happens consistently

Steps to Reproduce:
1. Set up libvirt/qemu/kvm virtual networks/machines as
   described later (will attach)
2. Ensure 'iptables' set up properly with proper protocol/port
   forwarding and network protection
3. attempt to establish VPN connection from outside hosting
   FC9/Linux box into internally hosted Windows network
4. this used to work ... and now doesn't
  
Actual results:

  Attempts to establish VPN network connection fails.

Expected results:

  Expect to be able to log in to VPN network

Additional info:

  ... will add more ...
Comment 1 Nathan Watson 2008-04-04 16:03:48 EDT
Created attachment 301331 [details]
yum update history for hosting FC9 Linux box

This is the yum upgrade history for the hosting FC9 Linux box.
Comment 2 Daniel Berrange 2008-04-04 16:12:23 EDT
The libvirt-0.4.1-2.fc8  update has broken virtual networking. Please try the
new build libvirt-0.4.1-3.fc8 which will be hitting updates-testing in the near
future, or grab it directly from Koji

http://koji.fedoraproject.org/packages/libvirt/0.4.1/3.fc8/
Comment 3 Daniel Berrange 2008-04-04 16:12:53 EDT
NB, you will need to reboot the host after applying this updated libvirt RPM
Comment 4 Nathan Watson 2008-04-04 16:16:40 EDT
Here is the IP tables setup for the hosting FC9 Linux machine
(all external-facing IP addresses changed):

Of note for this particular problem:
    
* The "native" 'eth0' interface for the FC9 Linux box is
  listening on several IP addresses, including 33.22.111.31

* the packets involved in PPTP are forwarded from
  33.22.111.31 to internal 192.168.7.31 (the IP address
  on which the external VPN interface on
  "chefe.janelaz.com" listens) ... these packets are
  IP protocol 47 (GRE) and also TCP/IP port 1723.  The
  lines that do the forwarding are:

    Table: nat
    Chain PREROUTING (policy ACCEPT)
    num  target     prot opt source               destination
    ...
    21   DNAT       tcp  --  0.0.0.0/0            33.22.111.231       tcp
dpt:1723 to:192.168.7.31:1723
    22   DNAT       47   --  0.0.0.0/0            33.22.111.231      
to:192.168.7.31
    ...

  * 192.168.8.* is mostly shut off from initiating contact from outside,
    except for 'ssh' port 22 on 192.168.8.31.  Here are the lines
    for that (mostly not relevant, pointing out for info sake):

    Chain FORWARD (policy ACCEPT)
    num  target     prot opt source               destination
    1    ACCEPT     all  --  192.168.8.0/24       0.0.0.0/0
    2    ACCEPT     tcp  --  0.0.0.0/0            192.168.8.31        state NEW
tcp dpt:22
    3    ACCEPT     all  --  0.0.0.0/0            192.168.8.0/24      state
RELATED,ESTABLISHED
    4    REJECT     all  --  0.0.0.0/0            192.168.8.0/24     
reject-with icmp-net-prohibited
    ...

*** full IP tables ***

Table: nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  --  0.0.0.0/0            33.22.111.232       tcp dpt:80
to:192.168.9.14:80
2    DNAT       tcp  --  0.0.0.0/0            33.22.111.232       tcp dpt:443
to:192.168.9.14:443
3    DNAT       tcp  --  0.0.0.0/0            33.22.111.232       tcp dpt:22
to:192.168.9.14:22
4    DNAT       tcp  --  0.0.0.0/0            33.22.111.248       tcp dpt:80
to:192.168.21.51:80
5    DNAT       tcp  --  0.0.0.0/0            33.22.111.248       tcp dpt:443
to:192.168.21.51:443
6    DNAT       tcp  --  0.0.0.0/0            33.22.111.248       tcp dpt:22
to:192.168.21.51:22
7    DNAT       tcp  --  0.0.0.0/0            33.22.111.247       tcp dpt:80
to:192.168.22.52:80
8    DNAT       tcp  --  0.0.0.0/0            33.22.111.247       tcp dpt:443
to:192.168.22.52:443
9    DNAT       tcp  --  0.0.0.0/0            33.22.111.247       tcp dpt:22
to:192.168.22.52:22
10   DNAT       tcp  --  0.0.0.0/0            33.22.111.246       tcp dpt:80
to:192.168.23.53:80
11   DNAT       tcp  --  0.0.0.0/0            33.22.111.246       tcp dpt:443
to:192.168.23.53:443
12   DNAT       tcp  --  0.0.0.0/0            33.22.111.246       tcp dpt:22
to:192.168.23.53:22
13   DNAT       tcp  --  0.0.0.0/0            33.22.111.246       tcp dpt:8080
to:192.168.23.53:8080
14   DNAT       tcp  --  0.0.0.0/0            33.22.111.246       tcp dpt:8443
to:192.168.23.53:8443
15   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:80
to:192.168.6.15:80
16   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:443
to:192.168.6.15:443
17   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:22
to:192.168.6.15:22
18   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:25
to:192.168.6.15:25
19   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:8025
to:192.168.6.15:25
20   DNAT       tcp  --  0.0.0.0/0            33.22.111.245       tcp dpt:993
to:192.168.6.15:993
21   DNAT       tcp  --  0.0.0.0/0            33.22.111.231       tcp dpt:1723
to:192.168.7.31:1723
22   DNAT       47   --  0.0.0.0/0            33.22.111.231       to:192.168.7.31

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  192.168.6.0/24       0.0.0.0/0
2    MASQUERADE  all  --  192.168.121.0/24     0.0.0.0/0
3    MASQUERADE  all  --  192.168.9.0/24       0.0.0.0/0
4    MASQUERADE  all  --  192.168.23.0/24      0.0.0.0/0
5    MASQUERADE  all  --  192.168.21.0/24      0.0.0.0/0
6    MASQUERADE  all  --  192.168.8.0/24       0.0.0.0/0
7    MASQUERADE  all  --  192.168.22.0/24      0.0.0.0/0
8    MASQUERADE  all  --  192.168.7.0/24       0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
3    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:67
5    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  192.168.8.0/24       0.0.0.0/0
2    ACCEPT     tcp  --  0.0.0.0/0            192.168.8.31        state NEW tcp
dpt:22
3    ACCEPT     all  --  0.0.0.0/0            192.168.8.0/24      state
RELATED,ESTABLISHED
4    REJECT     all  --  0.0.0.0/0            192.168.8.0/24      reject-with
icmp-net-prohibited
5    ACCEPT     all  --  192.168.21.0/24      0.0.0.0/0
6    ACCEPT     tcp  --  0.0.0.0/0            192.168.21.51       state NEW tcp
dpt:22
7    ACCEPT     tcp  --  0.0.0.0/0            192.168.21.51       state NEW tcp
dpt:80
8    ACCEPT     tcp  --  0.0.0.0/0            192.168.21.51       state NEW tcp
dpt:443
9    ACCEPT     all  --  0.0.0.0/0            192.168.21.0/24     state
RELATED,ESTABLISHED
10   REJECT     all  --  0.0.0.0/0            192.168.21.0/24     reject-with
icmp-net-prohibited
11   ACCEPT     all  --  192.168.22.0/24      0.0.0.0/0
12   ACCEPT     tcp  --  0.0.0.0/0            192.168.22.52       state NEW tcp
dpt:22
13   ACCEPT     tcp  --  0.0.0.0/0            192.168.22.52       state NEW tcp
dpt:80
14   ACCEPT     tcp  --  0.0.0.0/0            192.168.22.52       state NEW tcp
dpt:443
15   ACCEPT     all  --  0.0.0.0/0            192.168.22.0/24     state
RELATED,ESTABLISHED
16   REJECT     all  --  0.0.0.0/0            192.168.22.0/24     reject-with
icmp-net-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain RH-Firewall-1-INPUT (1 references)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 255
3    ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
5    ACCEPT     udp  --  0.0.0.0/0            224.0.0.251         udp dpt:5353
6    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:631
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:631
8    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state
RELATED,ESTABLISHED
9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp
dpt:22
10   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp
dpt:53
11   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp
dpt:53
12   ACCEPT     tcp  --  192.168.0.0/16       0.0.0.0/0           state NEW tcp
dpt:111
13   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:111
14   ACCEPT     tcp  --  192.168.0.0/16       0.0.0.0/0           state NEW tcp
dpt:2049
15   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:2049
16   ACCEPT     tcp  --  192.168.0.0/16       0.0.0.0/0           state NEW tcp
dpt:4000
17   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:4000
18   ACCEPT     tcp  --  192.168.0.0/16       0.0.0.0/0           state NEW tcp
dpt:4001
19   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:4001
20   ACCEPT     tcp  --  192.168.0.0/16       0.0.0.0/0           state NEW tcp
dpt:4002
21   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:4002
22   ACCEPT     udp  --  192.168.0.0/16       0.0.0.0/0           state NEW udp
dpt:123
23   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited

Comment 5 Nathan Watson 2008-04-04 16:17:50 EDT
... I was going to insert more info, but thanks for the quick reply,
I see the problem's already addressed, most likely, and I look
forward to trying the new libvirt update.  Thanks!! ...
Comment 6 Nathan Watson 2008-04-04 17:44:37 EDT
haven't yet tried to patch, will do so now.

I've been saying the Linux host box is running FC9 ... I meant
to say FC8.
Comment 7 Nathan Watson 2008-04-04 18:09:48 EDT
everything's working now.  thanks!  i'm closing this bug ...
actually, looks like I can't do this from bugzilla
interface.  i've verified though
that upgrading to "libvirt-0.4.1-3.fc8" fixes the problem
i'd witnessed.  PLEASE CLOSE BUG OR RESOLVE IN WHATEVER
STANDARD FASHION YOU USE.

interesting, even though you say virtual networking was broken,
i experienced problems only for the hosted virtual Windows VPN
setup -- my many other hosted VMs (mostly Linux) worked just fine.
did it have something to do with hosts with multiple
virtual network interfaces?
Comment 8 Daniel Berrange 2008-04-04 19:09:54 EDT
The specific problem was that a bunch of the iptables rules got messed up, which
will impact various aspects of connectivity

Note You need to log in before you can comment on or make changes to this bug.