Existem diferentes maneiras de atingir seu objetivo.
Se os convidados compartilharem uma rede virtual (ou seja, não estiverem apenas conectados à interface física), será fácil. Basta informar seus serviços para ouvir essa interface - ou criar um novo convidado e permitir que ele hospede o serviço.
Se os convidados forem vinculados a ethX , talvez você ainda deseje criar uma interface virtual guest + host apenas, pois esse tipo de encapsulamento faz sentido para todos os tipos de serviços (servidor de email interno, qualquer servidor de banco de dados, DNS local, etc.)
(E obviamente há a maneira que você já descartou por algum motivo: regras de firewall)
Quanto a lo : cada host lxc tem o seu próprio, e isso é bom imo
Todos os meus clientes lxc compartilham uma interface virtual e para cada serviço que deve ser exposto à Internet pública, eu crio regras de encaminhamento de porta no iptables do host. E tento executar o menor número de serviços possível no próprio host. Dessa forma, há pouco ou nenhum risco expondo acidentalmente qualquer serviço.
E por questão de integridade, aqui está minha configuração:
Meu arquivo interfaces (debian stable):
auto br0
iface br0 inet static
bridge_maxwait 0
bridge_fd 0
bridge_ports dummy0
address 192.168.x.1
netmask 255.255.255.0
# if there are lxc clients that need a public IP, add something like this (a.b.c.d being the public IP) and set the client's 'lxc.network.ipv4' config parameter to the same address:
#post-up route add a.b.c.d dev br0
A parte relevante da configuração do cliente:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.veth.pair = lxc-apache # each client gets their own .pair name
lxc.network.ipv4 = 192.168.x.y/24 # ... and of course their own address