Time Capsule firewall allows broadcast traffic

Question

It appears that Time Capsule will forward broadcast traffic from the LAN side to WAN and allow responses back. I would have thought that when the Router Mode was set to "DHCP and NAT" that this wouldn't happen. It seems like this might be a security flaw.
Here's my setup, and why I believe this is the case:
Comcast Xfinity service -> Motorola SB6121 -> Time Capsule (latest generation 7.6.1 software) -> Netgear GS116 -> home network with airport express and various hard-wired and WiFi devices.
The SB6121 cable modem is wired direclty to the WAN port on the Time Capsule. And then the first LAN port on the Time Capusule is wired direclty the Netgear switch. And then everything else is wired directly to the Netgear switch. The Time Capsule's DHCP server is set to hand out addresses in the 172.16.0.2 to 172.16.0.200 range and so everything in my home network should be getting addresses in that range.
The SB6121 is not a gateway or router - its just a modem, but does still have a weird little DHCP server that is supposedly only active when the cable service is dead, but in practice (at least for me) seems to always be on. And there's no way to turn it off, at least from my end - perhaps Comcast could, but that's a black hole. This weird little DHCP server is hard-wired to hand out addresses between 192.168.100.11 and 192.168.100.42 and there's no way to configure it differently.
What I see though I (which makes me think there is a security flaw in the Time Capsule firewall) is that DHCP requests from my home network are sometimes answered by the SB6121's DHCP server instead of the Time Capsule's. I say "sometimes" because most of my Apple equipment (laptops, iPhones, iPads and a Mac Mini) get configured with 172.16.0.X addresses. But most non-Apple equipment is getting 192.168.100.X addresses - this includes a Denon AV reciever and Comcast cable box. But I also have an Airport Express (latest version, 7.6.2 software) - its Router Mode is set to "Off (Bridge Mode)", but if its Internet -> Connect Using: is set to DHCP it also gets a 192.168 address.
I thought maybe it was just the hard-wired devices getting the 192.168 addresses, but they're not. The Mac Mini is hardwired and gets the right address range. And then I thought that all WiFi devices were getting 172.16 addresses, but they're not. I have a "Nest" thermostat that connects to the WiFi and gets a 192.168 address.
Obviously there are several problems here - having multiple DHCP servers on a network is a recipe for disaster. But it seems to me that the Time Capusule is mis-behaving. The weird little DHCP server on the cable modem on the WAN side of the Time Capsule shouldn't be accessible from my home network. The Time Capsule shouldn't be passing broadcast DHCPDiscover packets from the LAN side through to the WAN side.
I've been all through the Time Capsule settings and don't see a way to further lock down the WAN-LAN connection. I suppose I could get a managed switch or "real" firewall to stick between the cable modem and the Time Capsule and use it to block traffic, but I shouldn't have to. And I suppose I could ask Comcast to disable the DHCP server on the cable modem, but I don't have the fortitue to sit on hold for hours trying to explain it to them. Or I suppose I could get a different cable modem that doesn't have the silly DHCP server, and maybe that's the ultimate answer, but I still think the Time Capsule has a flaw.
I got the SB6121 plus Time Capsule combination specifically because I didn't want fidgety stuff to deal with. I could have gotten a router supporting DD-WRT if I wanted to play network engineer at home, but I do that at work and just wanted something I didn't have to debug or think about.
Anybody in a similar situation or have suggestions?
If you got this far, thanks for listening.
-dave.
(Oh yeah, I swapped the Time Capsule with the Aiport Express -- latest model with WAN and LAN ports -- and got the exact same behavior. I suspect that all Airport models just treat the multple ethernet ports as a dumb layer two switch and blindly forward ethernet broadcast traffic from one port to all the others.)

Answer 1

Thanks for reporting this.. I think you should advise Apple of this flaw.. It is a serious flaw.
The cable modems are always made with local IP address so you can check the settings and the DHCP in them is designed for using a block of public IP addresses.. ie.. if you were extremely rich.. you buy a block of IP addresses from the ISP, plug the modem directly to a switch. And every client that joined would get a public IP address. Since the ISP are not that generous as to actually hand out more than one IP, (our local cable ISP in Australia, Telstra actually gives out 3 for free). The modem however will switch from public to private IP address when it does so, once the first address is allocated. There is no security risk as that private IP has no internet connection. (Test it and see, but any device getting 192.168 address should have no internet connection). The Modem has no NAT.. so it is purely for internal purposes.
When you tested the Airport Express, did you set it up to 172.16.x.x range as well?
Could you please test if you haven't already the TC at its native IP address and range?
Domestic routers often fail to work properly if used off their default range.. somewhere in the coding they have fixed some addressing, instead of correctly using settings you put in. This is not at all unusual actually. My advice to people is always stick with default unless you really want some pain.
If you are happy with pain, I would ensure all names are set to SMB standard.. as it sounds like you know networks I presume you would already do this. Apple names are ghastly things.
Stick to short, no spaces, pure alphanumeric names for everything.
Make sure the dhcp range includes enough addresses that it cannot run out..the normal standard is 2-200.
If the lease time is set to 1day default, set it to 20min.
I would also turn off ipv6 (maybe only possible on the client). That does seem to lead to confusion.
If necessary you should be able to use static IP reservation via the dhcp setting in the TC.. that might also help.
Are you running a 5.6 utility to do the setup?? If not you must!!
You can load it even into Mountain Lion with a bit of fiddling.
Check logs and setup the reservation for any devices failing to get IP correctly.
And yes, in the end you may have to simply use a more standard router.. and hive off the TC to bridged role.