Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 158630 Details for
Bug 246749
on shutdown, msg "unregister_netdevice: waiting for virbr3 to become free. Usage count = 1"
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
Description of problem setup, and workaround
junk.txt (text/plain), 7.73 KB, created by
Nathan Watson
on 2007-07-05 23:31:53 UTC
(
hide
)
Description:
Description of problem setup, and workaround
Filename:
MIME Type:
Creator:
Nathan Watson
Created:
2007-07-05 23:31:53 UTC
Size:
7.73 KB
patch
obsolete
> > +------------------------+ > | | > | | +---------------------+ > Internet +---+ 64.1.2.3(eth0) | |(Win Srv 2003 R2 SP2)| > + | | | | > | | 192.168.7.1 +----virbr4----+ 192.168.7.31 | > | | | | chefe. | > | | main.external.com. | | janelaz. | > | | (Fedora 7) | | com. | > | | 192.168.8.1 +----virbr3----+ 192.168.8.31 | > | | | | | | > +---+----+ | | | | Windows VPN server | > | | | | | | for 192.168.8.* | > | | | | | | | > | | | various other | +---------------------+ > | Host_A | | virtual networks ... | > | | | | + | > | | | iptables firewall | | | +---------------------+ > | | | running here | | | |(Win Srv 2003 R2 SP2)| > +--------+ | | | | | | > | | | +------+ 192.168.8.42 | > | | | | | > | | | | monstro. | > | | | | janelaz. | > | | | | com. | > | | | | | > | | | | | > +------------------------+ | +---------------------+ > | > | > | > | > +---+----+ > | | > | | > | | > | Host_B | > | | > | | > | | > +--------+ > >--- INTRODUCTION --- > > * Goal: among other things, (A) simulate a completely encapsulated > Windows network with virtual network/virtual machines, Windows > network being named 'janelaz.com'; (B) use standard security > best-practices for 'janelaz.com', by limiting direct external > access to 'janelaz.com' machines, and forcing external clients > to access 'janelaz.com' through VPN "gateway" chefe.janelaz.com; > (C) let external clients, e.g., HOST_A (outside host machine) > or HOST_B (virtual machine inside host machine, but external > to any network directly involved in 'janelaz.com' machines) > access the 192.168.8.* network via VPN. > >--- CONFIGURATION THAT DID NOT WORK, THAT LED TO PROBLEM IN BUG REPORT --- > > * I did what would be expected in the "real world": > * disallowed in main.external.com's iptables firewall any direct > access into 192.168.8.* or out of 192.168.8.* (well, that's not > real-world, that requirement's imposed by virtual nature of > what I was trying to do) > * set up chefe.janelaz.com as a Windows VPN server, with these > network, etc., configurations: > * 192.168.7.31 -- gateway == 192.168.7.1, DNS server = 127.0.0.1, > this is the "internet" side of the VPN server > * 192.168.8.31 -- gateway == NO_GATEWAY, DNS server = 127.0.0.1, > this is the "internal janelaz.com" LAN side of the VPN server > * included monstro.janelaz.com in the janelaz.com Windows network, > with these network, etc., configurations: > * 192.168.8.42 -- DNS server = 192.168.8.31, gateway == 192.168.8.31 > * Tests ran into problems: > * any network traffic from monstro.janelaz.com (e.g., > "telnet google-IP-address 80", or "tracert www.yahoo.com-IP-address", > or "ping www.redhat.com-IP-address" would indeed send packets > (verified through Ethereal) to 192.168.8.31 gateway, which would then > appear to prompt activity out from 192.168.7.31 to 192.168.7.1 ... > mimicking the "real world" ... but there were two problems that I saw: > * my firewall configuration would prompt interface at 192.168.8.1 > on the host to stomp on the 192.168.8.42-initiated TCP/IP connect > requests (apparently its prohibition on 192.168.8.* to outside > world already takes effect at this level, even though in the > "real world" and supposedly in this simulated situation these packets > would never actually travel through 192.168.8.1) > * ... AND SOMEHOW THIS WOULD LEAD TO THE 'unregister_netdevice: ' hang > on virbr3 during main.external.com's shutdown ... this was a > 'kernel: ...' message in /var/log/messages and also repeatedly occurred > (once every two-to-five seconds or so on the physical console) > >--- CONFIGURATION THAT DID WORK, A WORKAROUND ..., AND PROBABLY "MORE CORRECT" APPROACH --- > > * I'm still learning about the network/VPN/firewall/etc. stuff, this configuration > seems to work just fine > * modified interface 192.168.8.31 to use 192.168.8.1 as gateway > * modified interface 192.168.8.42 also to use 192.168.8.1 as gateway > * made sure 'iptables' firewall on main.external.com allowed incoming > traffic for 192.168.8.* only related to already-established > connections (initiated from 192.168.8.* going outward) -- the firewall > rules are: > > Chain FORWARD (policy ACCEPT) > num target prot opt source destination > ... > xx ACCEPT 0 -- 192.168.8.0/24 0.0.0.0/0 > xx ACCEPT 0 -- 0.0.0.0/0 192.168.8.0/24 state RELATED,ESTABLISHED > xx REJECT 0 -- 0.0.0.0/0 192.168.8.0/24 reject-with icmp-net-prohibited > ... > * this configuration worked fine, met the goals of the virtual network deployment, > and does not mess up 'virbr0' on main.external.com shutdown > * ... and of course, to enable HOST_A in the example to connect to the Windows VPN > directly, one needs to enable IP-forwarding of certain classes of packets > from 64.1.2.3 to 192.168.7.31 > >Since there's a workaround (and probably a "more correct implementation" considering the >environment in which it's implemented) I'll reduce the severity of this bug. I'm sure >there's some hole you might want to close in the kernel-resident services in which this >bug is exposed, but it might be lower priority now. > >---
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 246749
:
158523
| 158630