Re: xen networking

[Greg Troxel <gdt%lexort.com@localhost>]

Iain Hibbert <plunky%ogmig.net@localhost> writes:

>> There should be something about your network configuration. I suppose you
>> make this setup complexed because you have some limitations in real network
>> connected to wm0, but we need to know what they are.
>
> Well, I only have a single IP available. I was trying to run these 
> services on the domU rather than the dom0 for security. Perhaps that is 
> not ultimately necessary.

A bridge in NetBSD is just like a virtual version of an ethernet
switch.   So think about the network diagram you are building and if it
would work if all physical.

I was assuming that you expected the DHCP server on the same ethernet as
dom0-wm0 to hand out an address for a new, previously unknown MAC
address.   Obviously that is not the case, so you just are only going to
have the one address.

>> As it sounds to me - DHCP server which you try to use accept only dom0's wm0
>> mac address. If it is so - you can either use dom0 as a router/NAT instead
>> or swap mac addresses between dom0 and domU-router.
>
> Hm ok, perhaps that would be an option. I can assign whatever MAC address 
> on the domU that I like. I don't think I can actually remove the wm0 MAC 
> but could add something else as the active address.

This seems to me to be asking for trouble.   To me, dom0 stability is
the most important thing, as it is how you manage everything else.  So I
would leave the true mac on wm0 and that IP address on the dom0 and not
even consider messing with that.


If your real goals are:

  have each domU be able to just run dhcpcd and get a (local) address
  and have NATed connectivity

  optimize dom0 security

  keep things not super complex, so they remain reliable

(which I admit is what my goals would be if I were in your position,
as a discussion starting point), then I would do one of

OPTION 1

  use dom0 wm0 normally, with the single real IP address

  create bridge0 on dom0, with xvifN.0 for each domU in it, so that it is
  as if you had another switch, and plugged all the domU computers into it

  (here's the awkward part) Put wm1 in bridge0, and assign it
  192.168.1.1/24.  It would be nice if NetBSD had an pseudoethernet
  interface that could have an address and be bridged, just not with a
  physical backend.  I suppose tap(4) is basically this, assuming it
  works if you just don't open the userspace control part.

  run NAT on dom0 from wm1's addr to wm0, and DHCP server also

  set up firewalls as restrictively as possible

OPTION 2

  (mostly the same)

  create a domU, call it Z, just for NAT with xennet0 and 1.  create bridge1 on dom0
  and put xvifZ.0 in bridge1

  on bridge0, don't add in wm1.  But do put in all the other domUs

  put 192.168.2.1/24 on wm1, and then put wm1 in bridge1

  on dom0, do nat from 192.168.2.0/24 to wm0

  on domU Z:
    configure 192.168.1.1/24 on xennet0 (the domU LAN)
    configure 192.168.2.2/24 on xennet1 (a host on the dom0 NAT LAN)
    run dnsmasq
    do NAT from xennet1 to xennnet0

    perhaps run your recursive resolver on Z

  with this scheme, a domU will be NATed twice.  The security benefit is
  that the dnsmasq code on domU-Z is the thing that is exposed to the
  other domUs.  So if they exploit it, they get access to domU-Z.  But
  because you have statically configured domU-Z's IP address, there is
  no dhcp server code on the dom0 to attack from Z.


I don't know how safe dnsmasq is, if it does privsep, etc.   So I can't
say if it's worth it to do option 2 instead of 1.   It is certainly more
complicated and requires more processing.   I would lean to trying to
run servers with privsep only, and all the various hardening things
turned on.