Attachment 158630 Details for Bug 246749 – Description of problem setup, and workaround

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:

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.
>
>---

Actions: View

Attachments on bug 246749: 158523 | 158630