Shorewall with DHCP: finding the subnet the host is on
Niels Penneman <niels <at> penneman.org>
2014-07-26 11:54:08 GMT
In a setup with a dedicated server that's connected to the public
internet, I intend to split the different services that run on this
server over a number of virtual machines.
The server has one single 'global' IPv4 address and a whole subnet of
IPv6 addresses. In the future I may want to occasionally allocate a
publicly accessible IPv6 address to a VM, but for now I'm relying on NAT
with IPv4 only.
My goal is to make the VMs portable with respect to network
configuration, so that I can easily test them on different machines.
Therefore I've set up DHCP for all VMs. The DHCPv4 server is running
directly on the server, and it's pushing settings like the default
gateway, NTP server, etc. to the VMs.
I run Shorewall on the physical server, and I would also like to run
Shorewall on the individual VMs. Configuring Shorewall with DHCP is not
so straightforward though, especially because I'd like to differentiate
between traffic coming from subnet the VM is on (as a nested zone that
represents the internal network), and traffic coming from WAN (through
NAT on the physical server).
I've seen that in recent versions Shorewall can detect the default
gateway (findgw script) and the IP address but I don't see a variable to
get the subnet mask. If there is one, you can stop reading here and just
tell me which one it is!
I know what the subnet is going to be on the server, but if I move a VM
to my desktop to play around with it, I do not want to reconfigure it.
Hence, I cannot hardwire the subnet into the Shorewall configuration. I
see many different ways to tackle this issue but I'd like some input to
see which is the best way to go forward.
What I've come up with so far are the following:
1. Shorewall is started by the DHCP client AFTER the DHCP client gets a
lease from the DHCP server. The DHCP client writes DHCP options like
default gateway, subnet, etc. to a file which gets included from the
Shorewall params file. The Shorewall configuration can hence rely on a
gateway and subnet variable to define a nested zone for the internal
network. The DHCP client reconfigures Shorewall when the IP changes
(hypothetically speaking since it will never happen in my setup) and
stops Shorewall when the lease is released. This does not necessarily
imply that the server is wide open before Shorewall starts. It's easy to
use some tricks to only let DHCP traffic pass before Shorewall runs and
after Shorewall stops using plain iptables or another mechanism. I have
tried this and it works but it comes with some security implications:
the DHCP client must be able to update a Shorewall-readable
configuration file AND must be able to control Shorewall. The latter is
not a good thing.
2. I could try to write an extension script for Shorewall that much like
findgw reads the default gateway, queries the DHCP configuration to find
the subnet, and then uses this in the definition of a nested zone that
represents the internal network. The problem here is that I have never
written extension scripts. I have tried Googling a bit but so far I
still have no idea where to start.
3. The most vague idea of all. I have read that Shorewall supports
dynamic zones using ipset. If it is possible to make a nested zone
dynamic, perhaps the DHCP client can configure this zone to contain the
subnet that represents the internal network whenever it gets an IP, and
deconfigure it when it loses the IP.
All of the above would enable Shorewall to learn more about DHCP
parameters other than the subnet as well (e.g. NTP server). Information
regarding the above ideas as well as new ideas are welcome. Thanks!
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.