What I did to set up a wireless network and what I have left to do

August 13, 2016

I tweeted:

I didn't entirely plan on setting up a home wireless network tonight, but sometimes these things happen.

Up until now, what I have had at home is my home Linux machine and a DSL modem. I run PPPoE on my home machine and it sits directly on the Internet. This is an unusual setup, but it's all that I needed and I don't really like being behind NAT gateways and so on. In the beginning my DSL modem was just a DSL modem, but when I upgraded to VSDL I needed a new VDSL 'modem'. Well, you can't get things that are just VDSL modems (or not easily); instead you get multi-port VDSL routers with wireless capability that you can force to dumb themselves down to just being (V)DSL modems.

(I have this one, on the recommendation of my ISP, and it works. I can even SSH in to it to get interesting stats, which is occasionally useful.)

Recently (as in today) I somewhat impulsively picked up a gadget that not merely likes to use your wifi network but absolutely insists on doing so in order to get some important-to-me functionality. So I needed a home wireless network of some sort, ideally with as little disturbance to my current home machine's setup as possible. In the end this turned out to be less involved than I was worried about, although my current setup is an incomplete hack.

What I did:

  • Turned on the wireless access point functionality of my VDSL modem. I was worried that the modem might insist on the wireless being a captive network or running DHCP or some such thing, but it's happy to be just a basic access point that bridges wireless and wired traffic together. I changed the SSID to something nondescript and set a very non-default password (although I carefully picked one that would be reasonably easy to enter on constrained devices).

  • My wireless devices were going to need DNS, so I made my Unbound setup listen on the local network interface as well as localhost. I also added a local. zone with DNS entries for everything I expected.

  • I installed the Fedora dhcp-server package and configured it to do DHCP on my local network, where by 'configured it' I mean 'I copied bits and pieces out of the DHCP configurations we use at work'. As a cautious sysadmin I don't believe in letting just anyone use my wireless network, so I mostly plan to stick to static IP address assignment for known wireless MACs. To make life simpler for myself, I set up a very small dynamic pool with a low lease time; this way I can get a device's MAC by watching for new things in this pool, and the device itself will be pacified about 'having wifi' (since its DHCP requests will get answered, even if it can't do anything).

This left the small detail of outside connectivity, which means NAT. There are lots of guides for this on the Internet and I cribbed bits from several of them:

  • enabled IP forwarding on my local network interface and my external PPPoE interface. Failure to remember the latter caused my initial setup to fail; it took a while before the penny dropped. Some people enable IP forwarding globally, but I want to be more selective for hand-waving reasons. See my entry on IP forwarding settings for an explanation of why I needed both.

  • enable general iptables forwarding for established connections from my PPPoE interface to my local one:

    iptables -A FORWARD -i ppp0 -o enp7s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    

    Since my current FORWARD policy is a default-accept, I'm not sure this is currently required, but probably I should block other traffic from making this hop.

    (I think it would require something perverse that shouldn't happen to send traffic for a RFC 1918 IP address down my PPPoE link, but the Internet environment is full of perverse things.)

  • enable forwarding from the local interface to my PPPoE interface for the specific IPs that DHCP assigns to the wireless devices that I know about:

    iptables -A FORWARD -i enp7s0 -o ppp0 -s <IP> -j ACCEPT
    

    Again this is probably partly surplus currently because of the default accept state.

  • enable SNAT for the specific IPs of known wireless devices:

    iptables -t nat -A POSTROUTING -s <internal-IP> -J SNAT --to-source <my-public-IP>
    

    Since there is no broad default SNAT, this stops any other device on the local network from being able to do anything much on the Internet.

So what do I have left to do? Quite a lot, actually. First, I need to set things up so that this persists over a reboot. I was in a big hurry this evening so I just did all the commands by hand (since my goal was to get the gadget going and make sure it worked; building a home wireless network was just a prerequisite).

Next, I need to make it so that other IPs on the internal network are genuinely blocked from doing anything, as opposed to simply not working by side effect. This will need at least some catch-all entries to explicitly block all other local traffic going to the PPPoE link and probably from the PPPoE link to the local network. I should definitely write the iptables rules necessary to make sure that I don't leak un-NAT'd local network addresses onto the Internet.

More subtly, I was lazy when I picked the local network I was using. My VDSL modem's administrative IP lives on 192.168.1.0/24 by default, so I had enp7s0 set up with this network. However, there is no reason for the wireless network to be in the same subnet as the VDSL's administrative IP (even if they are sort of on the same wire). I should move the whole network to another subnet, say 192.168.2.0/24.

Right now I'm writing separate rules for each known good IP, but this is an obvious case for ipsets, especially if I expect to have more and more wireless devices show up. Maybe someday I'll take my work laptop home temporarily, for example. I think the interaction between ipsets and the other rules should be straightforward, but I'll get to find out once I have the energy.

My home machine has a whole complex policy based routing setup. At the moment this doesn't interact with the wireless NAT'ing at all, with the effect that the wireless devices can't talk with anything reached over my IPSec tunnel because their traffic goes out un-NAT'd and then the other end just throws it away because there's no route back to 192.168.1.* addresses. What I probably want here is something akin to isolated interfaces, where my IPSec tunnel to work just doesn't exist as far as wireless clients are concerned and all their traffic goes out my home machine's external IP regardless of where it's going.

(I don't feel confident and trusting enough in the security of my wireless network to let clever people on it have privileged access to work. Sure, I have a WPA2 key set, but my understanding is that those can be cracked.)

And of course all of this currently only supports IPv4. My home machine has IPv6 connectivity, so in theory I could offer IPv6 connectivity through to wireless clients. This probably shouldn't need any sort of NAT, but it would require me to figure out IPv6 DHCP and routing (and firewall rules, since I have no intention of allowing my wireless devices to be fully exposed to the Internet).

Written on 13 August 2016.
« I think I'm going to shift my style of Python indentation
Code alone can tell you the what but it cannot tell you why »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Aug 13 01:10:23 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.