Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Sep 17, 2018 0:35 Post subject: SOLVED sharing a printer across VAPs with network isolation
I have two wifi virtual access points (VAPs), each configured with network isolation. (I have more than two, but just two that matter to this story.) VAP1 does not have AP isolation and has a wifi printer on it. VAP2 has AP isolation (and is routed through a VPN with PBR, but I think/hope that's irrelevant here).
Is there a way, short of disabling network isolation for both and substituting a pile of custom iptables commands (a task way over my head), to make the printer on VAP1 available to the (isolated) users on VAP2 as well as to the VAP1 users? This is about configuring an exception to the isolation rules.
To allow this br1 access to a printer, web server, or other network device, add this rule last:
iptables -I FORWARD -i br1 -o br0 -d {IP address} -m state --state NEW -j ACCEPT
with br1, br0, and the {IP address} replaced appropriately. That is from a very obsolete discussion of guest networks, and in this context it seems it would be trying to revive packets already discarded by the network-isolation rules (not to mention that it offers no way for the printer to respond to the enquiring computer). Seemed like the wrong way, but of course I noobly tried it anyway. Not useful.
So is there a way?
For the record, I'm running brainslayer's 36698 on a Linksys WRT1900ACSv2.
Last edited by SurprisedItWorks on Tue Dec 10, 2019 1:39; edited 1 time in total
Joined: 18 Mar 2014 Posts: 12884 Location: Netherlands
Posted: Mon Sep 17, 2018 11:22 Post subject:
The rule can maybe work but it presumes the following:
VAP2 is on br1, the printer is on br0 and the Net isolation rule is done by blocking state new
(otherwise return traffic would not be possible as you mentioned.)
(And I presume the printer's IP address is not on the VPN)
You can try by only using the in-interface (the interface of VAP2).
Code:
iptables -I FORWARD -i br1 -d {IP address of printer} -m state --state NEW -j ACCEPT
iptables -I FORWARD -s {IP address of printer} -m state --state ESTABLISHED,RELATED -j ACCEPT
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Sep 17, 2018 16:45 Post subject:
Many thanks for the quick reaction here.
The printer is on the VAP with no vpn and has a static lease. Hence my guess that the vpn is irrelevant here.
But both VAPs are currently unbridged. Are bridged setups (even though each bridge would contain only a single VAP) for some reason necessary? What about instead just using VAP interfaces ath1.1 and ath1.2 right in the iptables rules?
Aside: I have used ath1.1 in my clueless adaptation of NordVPN's iptables rules to realize a vpn kill switch, but that kill switch is untested. Not really sure how to test it, actually. Just disable the vpn client temporarily?
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Sep 17, 2018 20:30 Post subject:
Tried your
Code:
iptables -I FORWARD -i ath1.1 -d brother -m state --state NEW -j ACCEPT
iptables -I FORWARD -s brother -m state --state ESTABLISHED,RELATED -j ACCEPT
where "brother" is either the printer IP address or actually just "brother", the name it acquires in the static-lease table. Guessed that'd be as good, as "iptables -L -v" replaces the actual IP with "brother" in its listing anyway. Anyway, real IP or "brother" turns out to makes no difference in the outcome here. I also tried including "-o ath1.2" before the "-d" in the first line. None of these variations matter, as in each case I can ping brother from ath1.2, where it "lives" normally, but not from ath1.1, where I'm trying to make it visible. And iOS fing can see the brother when connected to ath1.2 but not when connected to ath1.1. After such experiments, the command
Code:
iptables -L -v | sed -n -e 2p -e '/brother/p'
in a router (ssh) terminal yields this:
Code:
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- any any brother anywhere state RELATED,ESTABLISHED
0 0 ACCEPT 0 -- ath1.1 any anywhere brother state NEW
So it seems that nothing from ath1.1 even reaches the firewall to be affected by these commands. My guess is that pbr in the vpn-client setup is grabbing all would-be printer traffic from ath1.1 and stuffing it into the vpn's tun1 before the firewall even gets to express an opinion. (What becomes of those pings then? Am I pinging something at the other end of the tunnel far, far away?)
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Sep 17, 2018 21:19 Post subject:
New experiments just confirm your conclusion. To see if perhaps it was simply the network isolation of ath1.1 that was dropping printer-bound packets before the new iptables lines had a go at them, I changed a single character in the firewall commands: I changed ath1.1 to ath1.3, another VAP that is set up identically to ath1.1 except that there is no vpn client associated with it. In this configuration, I could not discover the printer with fing from ath1.3, but fing was able to ping it. Then three Windows 10 experiments.
Connecting to ath1.3 and trying to print returned "printer offline."
Connecting to ath1.2 and printing (to discover the printer's IP) printed fine,
Connecting to ath1.3 and printing printed fine.
So if we keep the vpn out of the picture, this scheme makes the printer usable but not discoverable on the other subnet.
Restoring the firewall commands to address ath1.1 again, I confirmed that Windows 10 could not print. Printer offline.
So it certainly does seem that the issue is pbr grabbing the traffic. I don't see a way around that no-local-routes bug short of monkeying with dd-wrt source code.
Posted: Tue Sep 18, 2018 5:37 Post subject: Possible solution ...
1. Set up a new Virtual Interface which does not broadcast SSID.
2. Place this printer and all such common items on this Virtual Interface.
3. Grant complete access to this Virtual interface from all the subnets that you currently have. VPN should not be an issue here.
Depending on your current security concerns, you may need to block (in firewall) anything that originates from VAP1 and tries to access VAP2 (and vice versa) via this new virtual interface.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Sep 18, 2018 23:57 Post subject:
Every programmer gets way too much experience muddling through and making changes in unfamiliar languages and systems. This is very much in that category for me. I have no idea what I am doing and am still googling for basics.
That said, here's how my router handles vpn routing before I make any changes. Routing table 10, per "ip route show table 10", appears to be for preliminary routing of packets selected by pbr to go to the tunnel. Right now on my router it's a one-liner:
Code:
default via 10.8.8.1 dev tun1
Everything else is handled in the main routing table, including packets that table 10 sends to 10.8.8.1, the gateway at the server end of the vpn tunnel. Those packets are routed by the line
Code:
10.8.8.0/24 dev tun1 scope link src 10.8.8.215
in the main table. My (client) end of the vpn tunnel is 10.8.8.215. Everything else in the main routing table, per "ip route show", appears to be what it would be with no vpn (though I have not disabled the vpn to check).
Now the script by @eibgrad. To my eye it waits for table 10 to be created when the vpn is brought up and then replaces those lines in it that do not begin with "default" (an empty set in my case) with those lines of the main routing table that begin with neither "default" nor "0.0.0.0/1" nor "128.0.0.0/1" (I have only a "default" line), and it does all that every 60 seconds indefinitely, in case there are changes. Seems like it (together with the firewall openings discussed above) should work for my printer problem.
Do NOT combine the PBR feature of the GUI w/ the script. They are NOT compatible. If you use the script, you'll need to use it exclusively for all your PBR needs.
But I do not see why this is an issue. It seems to me that if I were to leave pbr in place and use the script, everything from the subnet it selects would be grabbed by one of the new lines in Table 10 and routed exactly as it should be. I'd still need the firewall lines we discussed earlier to get to my printer, but other than that, everything should work, no?
However, even if all that would work fine, rather than introducing an entire page of script into the startup commands, would it not be simpler to just add
Code:
192.168.X.Y dev ath1.2 scope link src 192.168.3.1
to Table 10, where 192.168.X.Y is the printer ip address? Isn't this just a matter of three lines of code?
Code:
#table 10 routes packets from pbr-selected sources.
#wait for table 10 to be created as the vpn client is brought up.
while [ ! "$(ip route show table 10)" ]; do sleep 10; done; sleep 3
#add a printer route to table 10
ip route add '192.168.X.Y dev ath1.2 scope link src 192.168.X.1' table 10
#make the routing system use the changed table
ip route flush cache
(X and Y are as before.) This is of course an enormously stripped down and tailored version of @eibgrad's script, the point being to avoid confusion over why things are being changed and to make clear just how minimal the effect sought actually is. This minimalism would be to avoid reader (me in a year) panic over "conflicting" (how?) with pbr in the GUI or over making extensive table changes.
Joined: 18 Mar 2014 Posts: 12884 Location: Netherlands
Posted: Wed Sep 19, 2018 7:38 Post subject:
If you set the MAX_PASS to any value other than 0 the script is executed only a limit number of times and not infintely.
Regarding the warning, I am pretty sure that is not meant for this script but for his script which replaces the PBR from the GUI.
I use PBR from the GUI and his script to get local access.
And yes this script does exactly as you described, it just copies the local routes to table 10, and yes you could do that manually also or adapt the script to just copy local routes you want.
The route you add is for the ath1.2. But, I think, you also need to add local routes to other subnets if that is where you print from.
One more thing to consider, is the local firewall of the clients. i.e. Windows by default only accepts incoming packets from its own subnet, in these cases packets are incoming form other local subnets so you have to tweak the windows firewall (can send instructions if needed).
Maybe you printer has a firewall too which need to be tweaked to accept other subnets then its own? _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Sep 19, 2018 16:30 Post subject:
Thanks for the insights. Appreciated. Will give it all a try soon.
A Windows 10 experiment using subnets without a vpn found it happy to print to 192.168.3.X while itself having a 192.168.4.Y address, so its firewall, which has never been tweaked in any way, does not appear to be an immediate obstacle in this household. If the tweak to allow such is a simple matter though, it would be nice to have it in the record in case others hit more of a "wall" than I did. And I'd certainly be clueless if I did ever need to tweak it, as I'm a Fedora linux and occasional Mac person and know pretty much zip about Windows.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Sep 19, 2018 21:57 Post subject:
The local-routing script works great: the two routing tables are kept identical except for their default lines. I also have your firewall command in place to provide printer access:
Code:
iptables -I FORWARD -i ath1.1 -d 192.168.X.Y -m state --state NEW -j ACCEPT
(X and Y point to the printer.) I can now print from ath1.1, even though off-site traffic from there goes through the vpn client and even though the printer is on ath1.2. We flirted with the additional command
but it turned out to be unneeded. The "ESTABLISHED,RELATED" case is covered globally it seems.
That's the good news. The bad news is twofold. I assume these are unrelated, but both are firewall matters mentioned already in this thread, so I'm putting them out there.
First, not only can I ping and use the ath1.2 printer from ath1.1 (where the vpn is) as intended, I can also ping other devices on ath1.2 from ath1.1. Before I added the new iptables command, I could ping nothing on ath1.2 from ath1.1, but it seems now that network isolation has been breached in an undesired way. It does appear that the iptables command was installed as intended:
Code:
root@DD-WRT:~# iptables -L -v | sed -n -e 2p -e '/brother/p'
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- ath1.1 any anywhere brother state NEW
(Here brother is the name given the printer IP in the static-lease table.) What might be the issue?
Second, I've been using the kill switch recommended by NordVPN for their dd-wrt setup:
There is nothing from the last, "--reject-with udp-reset" iptables command, even when I search the entire output of "iptables -L -v" by eye or emacs incremental-search or whatever. When I enter that iptables command by hand at the ssh terminal, it is quietly accepted without complaint, but again there is nothing in the table afterward. If I disable the vpn client, visiting a website or pinging across the network will indeed fail, with incremented dropped-packet counts on the two lines above. But I'm not sufficiently networking aware to know how to test udp in particular.
Any of this trigger any potentially interesting thoughts?
Joined: 18 Mar 2014 Posts: 12884 Location: Netherlands
Posted: Thu Sep 20, 2018 12:09 Post subject:
I start with your las question first, regarding udp. Actually i do not know the answer, I only use the first line as kill switch, thjsi blocks all traffic regardless if it is tcp or udp, Maybe one of our more networking savvy members can answer it?
Regarding the net isolation, how did you implement it in the first place did you tick/enable net isolation in the GUI or use a firewall rule?
The firewall rule to isolate ath1.1 from the rest of your net work is:
Code:
iptables -I FORWARD -i ath1.1 -d 192.168.0.0/16 -m state --state NEW -j REJECT
This rule blocks all traffic to 192.168.x.x
Very important is the order of your firewall rules.
The unblocking rule should be entered last!
Code:
iptables -I FORWARD -i ath1.1 -d 192.168.0.0/16 -m state --state NEW -j REJECT
iptables -I FORWARD -i ath1.1 -d 192.168.X.Y -m state --state NEW -j ACCEPT
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Thu Sep 20, 2018 20:06 Post subject:
I have used explicit firewall rules only for the vpn kill switch and for the across-subnets printer access discussed in this thread. All my net isolation is by ticking the net-isolation boxes for wireless interfaces (including virtual ones). Specifically, I have four such boxes ticked, one for 5 GHz wifi and three for virtual interfaces associated with 2.4 GHz wifi. The main 2.4 GHz interface is not isolated (neither network nor AP) and is bridged, per the default, to the LAN via br0. So there are five subnets altogether, of which three have AP isolation as well (and one is pbr routed to the vpn client), so this makes for a lot of automagically generated firewall rules. Until the ping problem above arose, this setup has worked beautifully for me for months. All the various isolation requirements have appeared to be met fully, with no issues.
