On Sun, Aug 7, 2016 at 9:57 AM Dan Ritter <d...@randomstring.org> wrote:
> On Sat, Aug 06, 2016 at 04:56:06AM +0000, Mark Fletcher wrote: > > On Sat, Aug 6, 2016 at 2:48 AM Dan Ritter <d...@randomstring.org> wrote: > > Got it. You can change that by removing NAT from the AP. For > instance, plug your switch into a LAN port instead of the WAN > port: > > cable modem -- LFS -- switch ---- (LAN port) AP ---- wifi client > | \___ wifi client > | > ---- other wired machines > > You can either set up a flat addressing space, perhaps with a > range reserved for DHCP machines and the rest doing static, or > you can route at the LFS machine and the AP. I would recommend > a flat space unless you have a really large (>25) number of > machines. That's what I do. > > I also have my equivalent of your LFS running dhcpd for the > whole network, rather than having another configuration point > on the AP to worry about. All filtering can be done there. > > -dsr- > In the end I got what I needed by using Lars' pointer of the iptables extensions. I copied the iptables systemd service unit from my LFS box to the machine in question, and then created a script in /etc/systemd/scripts that first sets the iptables output chain policy to DROP, then adds these rules: iptables -A OUTPUT -m time --starttime 00:00 --stoptime 12:00 -j ACCEPT iptables -A OUTPUT -d 192.168.11.0/24 -j ACCEPT followed by rules specifying protocols and ports to allow DHCP, NTP and Avahi to work at all times. The first of the above rules matches every single outgoing packet and lets them through between the hours of 9am and 9pm JST (midnight to noon UTC) and matches nothing the rest of the time. Since Japan does not observe daylight saving time I don't have that wrinkle to worry about. So between 9am and 9pm the other rules are superfluous and get no exercise. Once 9pm arrives the first rule stops matching anything and the others start getting work to do. The second allows anything aimed at my local network through, except connections to my firewall which isn't on the 192.168.11.xxx subnet, but I don't need this box to be able to ssh into the firewall so that's no problem. I could have made it 192.168.0.0/16 but then I would have been allowing a bunch of other subnet addresses I don't need. In this case, not a major problem, but generally a bad habit when it comes to packet filter rules. The other rules allow DHCP, NTP and Avahi to work (the second rule doesn't allow Avahi to work as it uses a broadcast address). Without the Avahi rule, I found that the machine could talk to the rest of my network by ip address but not by network name during the out-of-hours period. Duh, hadn't thought of that. So between 9am and 9pm everything hits the first rule and gets allowed. Between 9pm and 9am anything not specifically aimed at my local nework that isn't DHCP, NTP or Avahi falls all the way through the rules and hits the policy rule, which is DROP. No changes needed anywhere else on the network. If the machine can't get requests out, it isn't going to get any responses back. And the firewall at the front door of my network is blocking anything trying to come in from the internet that wasn't invited. # systemctl enable iptables.service makes sure this gets run every time the machine is booted. And that's it. However, I'm finding the discussion with Dan very interesting so I'd like to continue it if you don't mind, albeit on a hypothetical basis. The first problem I'd have with Dan's suggestion is that the firewall box only has 2 network ports -- one built into it and one I added using a USB3.0 to Ethernet adaptor. So the cable modem is plugged into the native Ethernet port and the USB-to-Ethernet passes on through an Ethernet cable to the WAN port of the AP. This would be the connection that Dan suggests shifting to a LAN port of the AP. Despite some clucking from various sources about the performance I'd get from using a USB to Ethernet adaptor, in practice I see no practical difference in internet access speed by having used such an adaptor. I guess I'd need to add a third Ethernet port to the firewall to migrate the wired devices, using another USB to Ethernet adaptor, and plug some kind of hub device into it so I could plug in more than one wired Ethernet device. Then the firewall would have to be a dhcp client of the AP, instead of the other way round as now, as I can't turn the AP'S DHCP server off since I need it to supply IP addresses to my wireless devices. But I'd need to keep the DHCP server on the firewall so it could supply IP addresses to the wired machines. I am not a fan of static IP addressing on a home LAN, although I can see why it isn't a big problem for the wired part since wired devices tend not to wander about. :) But part of me is thinking that if I were going to migrate my wired devices away from the AP and to the firewall, I might as well go the whole hog, turn the firewall's WiFi device on, and serve up the WiFi from there too, eliminating the AP altogether. Except that the WiFi card in the firewall wasn't designed to be an AP and maybe its signal will be weaker. However, the last time I cracked open a common-or-garden WiFi router and looked inside, I found a PCMCIA WiFi adaptor of exactly the kind I was using in my computer at the time, inside... Mark
