1

I am trying to design a guest wifi network for my existing network, but I'm unsure how to secure the guest wifi access point from the parent network, when the access point is contained within the parent network.

I've tried searching this, but I'm just getting results from consumer hardware that says "click this config" and typically assumes the main router is the wifi access point itself too, making logical segregation a lot easier.

              +----------+
              | Internet |
              +----+-----+
                   |
                   |
           +-------+------+
           | Linux Router |   10.0.0.0/24
+----------+              +--------------+
|          |   10.0.0.1   |              |
|          +-------+------+              |
|         Device A - 10.0.0.5            |
|                                        |
| Linux Guest Wifi Router - 10.0.0.200   |
|       +                                |
|       |                                |
+----------------------------------------+
        |
        |
        |   Guest Subnet 10.0.1.0/24
   +----+--------------------------+
   |                               |
   |  Guest Device X - 10.0.1.5    |
   |                               |
   +-------------------------------+

The main router is a dual NIC (ext/int) linux box (Debian 7 with iptables) and nothing more. The guest wifi access point is going to be a rasp PI I'm ordering, and I'm assuming that the necessary configuration will be contained on the guest wifi box.

But I'm unsure how to configure iptables(nftables?) on the PI to ensure the parent network is inaccessible except to route through to the internet.

  • How does "Guest Device X" get to the Main Router Gateway (10.0.0.1) while being denied access to Device A (10.0.0.5).
  • How do I know that the main router isn't going to send any request for 10.0.0.5 back onto the 10.0.0.0/24 subnet? Will I need to setup iptables on the main router to work in tandem with the wifi router?

Desired results from 10.0.1.5:

  • $ ping 10.0.0.5 - Destination unreachable / No Route to host etc.
  • $ ping 8.8.8.8 - OK
  • $ ping 10.0.0.1 - (assuming OK?)
  • $ ping 10.0.0.200 - Unknown?

Discussion for alternate potential solution below:

This would make things look like this:

Internet
  |
Linux Router
(eth1 10.0.0.1) (eth1:1 10.0.1.1)
  |                  |
Reg Network        Guest Wifi Router (10.0.1.2)
    (DHCP)           |
                   Guest Device (10.0.?.?)

So I'm not sure about a few things at this point

  1. How do I setup the routing table of the main router prevent traffic from 10.0.1.1 to 10.0.0.0/24 subnet? Or is this an iptables rule on the main router at this point? I'm not sure I'm seeing how this is different from having the guest wifi router on 10.0.0.0/24 since the main router would still be able to route to other devices on that network?)
  2. I'm assuming the guest wifi router would need a DHCP server for the guest devices. But would the guest devices use the 10.0.1.0/24 subnet with 10.0.1.1 as the gateway, or would I setup another subnet 10.0.2.0/24 for guest devices?
  • 2
    The better way to do this is put the guest network outside the private network. Failing that, the guest WiFi router should only forward packets to its default gateway and drop any attempts to communicate with other nodes on the 10.0.0.0/24 subnetwork. – Twisty Impersonator Apr 3 '18 at 2:44
  • guest wifi contained within is the key requirement, I can't have it outside or this would be a solved issue. You mention dropping everything going to something else on 10.0.0.0/24, but it's been so long I don't know if the main router would route back to the 10.0.0.0 subnet anyways? – Doug Apr 3 '18 at 2:53
  • why is it a key requirement? Couldn't you add another IP address to the router's LAN interface and make that the WiFi's default route, then ensure your router refuses to route between that subnet and the private one? – Twisty Impersonator Apr 3 '18 at 2:56
  • that sounds reasonable in theory, but I have no idea how to do either of those things, further, I wasn't aware I could "add another IP to a device" (adding info via edits shortly). I'm not sure I understand how I can simply have another IP "ignore" the routing table preventing the traffic from going back into 10.0.0.0/24? The whole issue here is that I cannot find docs to do this use case and help me through since my knowledge is rusty. Can you provide sample configs, route tables and iptable commands? – Doug Apr 3 '18 at 3:26
  • It's been years since I've worked in Linux. I don't know the commands you need. Someone else should come along who does though. – Twisty Impersonator Apr 3 '18 at 11:10
0

Recap of the situation, to verify if I understood correctly:

The Guest AP connects to the main router as part of the private LAN or WLAN. On top of that, you want a guest network that's separate from the private network, but will by necessity use the private network to reach the main router.

Brief outline of possible solution:

The only way to make this work securely is to have the main router be aware that there are two networks, and separate them properly with iptables rules. So you want your main router to see two network interfaces, one with 10.0.0.0/24 for the private segment, and one with 10.0.0.1/24 for the guest segment. I assume you know how to configure the main router with that, given the comments.

That means the connection from the guest AP (RaspPi) to the main router should use some kind of tunnel. The easiest variant would be a VLAN, which "overlays" (possibly multiple) virtual LANs on your private LAN.

Concretely, add both on the RaspPi and the Debian box a virtual network interface with something like

ip link add link eth0 name eth0.55 type vlan id 55.

(choose a VLAN tag), then use and configure eth0.55 like a normal network interface. Once it works, you can adapt /etc/network/interfaces to make it come up automatically.

Edit

For the firewall, you'll need iptables rules that prevent the interfaces eth0 and eth0.55 from talking to each other, so something along the lines of

#!/bin/bash
PRIVIF=eth0
GUESTIF=eth0.55
iptables -P FORWARD ACCEPT
iptables -F FORWARD
iptables -A FORWARD -i $PRIVIF -o $GUESTIF -j DROP
iptables -A FORWAD -i $GUESTIF -o $PRIVIF -j DROP

(untested). Or make it even safer with a default forward policy of DROP, and then enumerate all forwarding you allow, while preserving the NAT functionality of the router (if it has that).

There's plenty of online tutorials about firewalls and iptables, just pick the one you like most.

  • hey, thanks for the outline. I'm still not sure how to prevent traffic from getting onto the 10.0.0.0/24 subnet once the packets hit the main router through. Cause the main router would do exactly as it's designed to do, and route traffic trying for 10.0.0.0/24 out that NIC. I think overall this gives me a starting point to dig into it. – Doug Apr 4 '18 at 2:24
  • So the solution appears to be even easier than all of this. A single rule on the Access Point, and no need to modify anything on the primary router: iptables -A FORWARD -o eth0 -d 10.0.0.0/24 -j DROP. This appears to block any attempts to connect directly to anything on the internal network including services and network shares, while still allowing through connections to the internet. The idea came while seeing your suggested rules, even though your intention was to put them elsewhere. Further, because this is only the forward chain, direct connectivity like SSH into the AP is fine. – Doug Apr 15 '18 at 2:24
  • I forgot to mention that you should have a look at IPv6 packets, too. With your rule on the AP I'd be tempted to try to somehow trick the main router to rewrite packets in such a way that even though the main destination isn't 10.0.0.0/24, it will be after the rewrite, using some other feature of some protocol (and there are many to look at for stuff like this). While I don't see an obvious choice, and I'll probably not be spending the time to find one, it doesn't look watertight. Though it may be good enough for everyone except determined hackers. :-) – dirkt Apr 15 '18 at 16:56
  • yeah, at this point, I'm not concerned about hard malicious hacking efforts, although there could be the odd snoopy person who might just try and see what they can see. The primary use case is to just have a basic level of security that keeps them away from network and printer shares, as well as internally accessible admin pages like NAS, smart switches or Xen hosts. – Doug Apr 17 '18 at 2:36
  • The point I was trying to make is that in security, it normally doesn't pay off to try to be tricky and hack up something that looks simpler but will "still work" - in most cases there will be ways around it you didn't think of, and someone will find them. Do the straightforward thing (separate segments on the main access point, isolated from each other), make it as simple as possible, but not simpler. – dirkt Apr 17 '18 at 4:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.