RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 723862 - "isolated" network is not actually isolated due to dns-tunneling via dnsmasq
Summary: "isolated" network is not actually isolated due to dns-tunneling via dnsmasq
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-21 12:14 UTC by nizamov.shawkat
Modified: 2011-12-06 11:17 UTC (History)
7 users (show)

Fixed In Version: libvirt-0.9.4-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 11:17:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
tcpdump for libvirt-0.9.3-8.el6 (544 bytes, application/octet-stream)
2011-08-05 07:39 UTC, dyuan 		no flags Details
tcpdump for libvirt-0.9.4-1.el6 (1.08 KB, application/octet-stream)
2011-08-05 07:39 UTC, dyuan 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description nizamov.shawkat 2011-07-21 12:14:28 UTC 
There are 3 possible network connections in libvirt:
1) bridge  
2) NAT
3) isolated (guest-host only)

Former two obviously have an access to the network. Latter is said to be isolated from network and serves for connection between host and guest only. However, there is no way to disable dnsmasq in libvirt, therefore, guest always has a working dns connection (if host has it of course). In this case one can not prevent guest from creating dns tunnel over working dnsmasq instance. That means that "isolation" is easily broken from the guest by simple dns-tunneling technique. 

In one of bugreports lack of control over dnsmasq was said to be by design: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/247583

Of course, there are possible workarounds for such particular cases, but they are all external to libvirt. If libvirt claims that connection is isolated than it should really do it (or at least allow to do so) without resorting to external trickery. Please, allow the easy way of disabling dnsmasq in libvirt.
Comment 2 Laine Stump 2011-07-22 04:16:55 UTC 
Rather than disabling dnsmasq, how about just isolating its DNS server? If we run dnsmasq with --no-resolv, it will then satisfy dns requests for names that it knows about (via static host entries in the <dhcp> section, host entries in the <dns> section, and host names learned from clients), but it will not forward any requests for unknown names to any other DNS server - it will just return failures for those requests.

This will allow interested parties to setup fully functional isolated environments without needing a separate DNS server.
Comment 3 nizamov.shawkat 2011-07-22 10:17:02 UTC 
If you are asking my opinion, then, yes - disabling DNS requests forwarding for isolated networks is really a much better and simpler solution.
Comment 4 Laine Stump 2011-07-29 21:28:07 UTC 
A fix for this problem has been pushed to libvirt's upstream git repository, and will be included in the upcoming release 0.9.4:

commit 513122ae93be9e21fd809a100580ce6fbb4e0ba5
Author: Laine Stump <laine>
Date:   Fri Jul 29 15:42:04 2011 -0400

    network: don't forward DNS requests from isolated networks
Comment 6 dyuan 2011-08-05 07:36:59 UTC 
Reproduced this bug with libvirt-0.8.3-8.el6.

# virsh net-dumpxml br1
<network>
  <name>br1</name>
  <uuid>bd74236a-34ce-aa65-bcad-22d197632f9d</uuid>
  <bridge name='br1' stp='on' delay='0' />
  <mac address='52:54:00:24:1B:77'/>
  <ip address='192.168.144.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.144.2' end='192.168.144.254' />
    </dhcp>
  </ip>
</network>

# ps aux|grep dnsmasq
nobody   31984  0.0  0.0  12940   596 ?        S    02:59   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/br1.pid --conf-file= --except-interface lo --dhcp-option=3 --listen-address 192.168.144.1 --dhcp-range 192.168.144.2,192.168.144.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/br1.leases --dhcp-lease-max=253 --dhcp-no-override

ping google.com in guest.

catch the pkgs
# tcpdump -i br1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes
03:09:40.163516 IP 192.168.144.43.36522 > 192.168.144.1.domain: 60838+ A? google.com. (28)
03:09:40.163849 ARP, Request who-has 192.168.144.43 tell 192.168.144.1, length 28
03:09:40.164031 ARP, Reply 192.168.144.43 is-at 52:54:00:81:9c:88 (oui Unknown), length 28
03:09:40.164037 IP 192.168.144.1.domain > 192.168.144.43.36522: 60838 6/0/0 A 74.125.93.105, A 74.125.93.104, A 74.125.93.103, A 74.125.93.99, A 74.125.93.147, A 74.125.93.106 (124)


Verified PASS with libvirt-0.9.4-1.el6, all dns query is refused.
qemu-kvm-0.12.1.2-2.176.el6
kernel-2.6.32-176.el6

# ps aux|grep dnsmasq
nobody   30549  0.0  0.0  12940   568 ?        S    02:48   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/br1.pid --conf-file= --except-interface lo --dhcp-option=3 --no-resolv --listen-address 192.168.144.1 --dhcp-range 192.168.144.2,192.168.144.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/br1.leases --dhcp-lease-max=253 --dhcp-no-override

ping google.com in guest.

# tcpdump -i br1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes
03:29:13.122275 IP 192.168.144.43.45622 > 192.168.144.1.domain: 34185+ A? google.com. (28)
03:29:13.122368 IP 192.168.144.1.domain > 192.168.144.43.45622: 34185 Refused 0/0/0 (28)
03:29:13.122526 IP 192.168.144.43.42169 > 192.168.144.1.domain: 34185+ A? google.com. (28)
03:29:13.122561 IP 192.168.144.1.domain > 192.168.144.43.42169: 34185 Refused 0/0/0 (28)
03:29:13.122732 IP 192.168.144.43.36311 > 192.168.144.1.domain: 38270+ A? google.com.localdomain. (40)
03:29:13.122757 IP 192.168.144.1.domain > 192.168.144.43.36311: 38270 Refused 0/0/0 (40)
03:29:13.122840 IP 192.168.144.43.49294 > 192.168.144.1.domain: 38270+ A? google.com.localdomain. (40)
03:29:13.122856 IP 192.168.144.1.domain > 192.168.144.43.49294: 38270 Refused 0/0/0 (40)
03:29:18.121576 ARP, Request who-has 192.168.144.43 tell 192.168.144.1, length 28
03:29:18.121708 ARP, Reply 192.168.144.43 is-at 52:54:00:81:9c:88 (oui Unknown), length 28
Comment 7 dyuan 2011-08-05 07:39:21 UTC 
Created attachment 516835 [details]
tcpdump for libvirt-0.9.3-8.el6
Comment 8 dyuan 2011-08-05 07:39:49 UTC 
Created attachment 516836 [details]
tcpdump for libvirt-0.9.4-1.el6
Comment 9 errata-xmlrpc 2011-12-06 11:17:30 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html
Note You need to log in before you can comment on or make changes to this bug.