Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Wed Aug 07, 2019 14:03 Post subject:
At least progress
Make also sure "No DNS rebind" on services tab is disabled (it should be, otherwise it could not work)
You are probably using Policy Based routing on the VPN tab.
Be sure to not include the IP address of the interface (wl0.1 ) itself (like 10.0.10.1) in the PBR range so do not use 10.0.10.1/24.
Consider setting the DHCP range from .64 to .127 so that you can use 10.0.10.64/26 in the PBR field.
Problem with the PBR implementation of DDWRT is that there are no local routes in the alternate routing table.
For you not a problem because you do not want access to local clients but in this case the Pi is local.
I am not 100% sure that this will work because I always implement either a script from @eibgrad to copy the local routes to the alternate routing table or use the following PBR implementation: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318662
The latter is a bit overkill for your situation I think, it is usefull if you want to inlcude or exclude certain websites like Netfilx etc..
I tried the 0.0.10.64/26 in the PBR field, with the DHCP settings: start = 64, max = 64. Unfortunately no internet connection.
I will first read up on the @eibgrad's script. I would like to be able to exclude Netflix from the VPN.
Would it also be possible to run a second pi-hole as both DHCP- and DNS-server on the guest network? Just like I do on the private network. I have a spare OrangePi that is loaded with pi-hole.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Thu Aug 08, 2019 8:17 Post subject:
Sorry I could/should have known that it would not work
Although DNSMasq hands out the interface address as DNS server and this is not in the PBR, this will not work if the forced DNS redirect option is used.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Thu Aug 08, 2019 8:28 Post subject:
Regarding your other question, "Can a second Pi be used as DHCP server for the guest wifi"
DHCP requests are confined to the subnet so there is no easy way out especially as this guest network is isolated.
That is not to say it is impossible, heck, in theory it is even possible to use the Pi you already have installed for this.
But setting this up is not your usual SOHO setup, this is a kind of setup used in large professional networks.
The way it is normally done is using a DHCP forwarder, this runs on the subnet, forwarding request to the main DHCP server.
An other way I can think of is using VLANs to extend the subnet into the Pi.
You create an interface on the existing Pi for each subnet and use VLANs/trunking to get to the Pi, the Pi can then serve as DHCP/DNS server for all subnets.
A really complicated setup and not sure if it is really possible
I decided to go with your Simple PBR script, as it seems easier to setup than eibgrad's script and because I would like to be able to exclude Netflix from the VPN.
On the primary R7000 the Simple PBR script rules look like:
# --------------- BEGIN RULES ---------#
# specify source ip(s)/network(s)/interface(s) to be rerouted
add_rule from 10.0.10.64/26 # prim-R7000 wl0.1
add_rule from 10.0.20.64/26 # prim-R7000 wl1.1
add_rule from 10.0.30.64/26 # sec-R7000 wl0.1
add_rule from 10.0.40.64/26 # sec-R7000 wl1.1
add_rule from 192.168.178.109 # kodi
add_rule from 192.168.178.200 # PC
add_rule from 192.168.178.201 # laptop
# --------------- END RULES -----------#
and the fire wall rules look like:
# route all DNS requests through pi-hole
iptables -t nat -I PREROUTING -i br0 -s ! 192.168.178.3 -p tcp --dport 53 -j DNAT --to 192.168.178.3:53
iptables -t nat -I PREROUTING -i br0 -s ! 192.168.178.3 -p udp --dport 53 -j DNAT --to 192.168.178.3:53
# make pi-hole available on guest network
iptables -I FORWARD -d 192.168.178.3 -p tcp --dport 53 -j ACCEPT
iptables -I FORWARD -d 192.168.178.3 -p udp --dport 53 -j ACCEPT
On the primary R7000 everything is working fine now.
Do I need to install the Simple PBR script also on the secondary R7000 or can the guest network also be routed through the primary R7000?
In my original setup both R7000s acted as OpenVPN clients. Per Yngve Berg suggested to use static routes to run this through the primary R7000 (https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1166356#1166356):
Because you have turned on NAT, These packets will no longer have these sources addresses when they reach the primary router.
Instead of NAT on the secondary router, you can add static routes on the primary:
10.0.30.0/24 gateway 192.168.178.2
10.0.40.0/24 gateway 192.168.178.2
Where/How do I set these static routes?
The current fiewall rulls on the secondary R7000 are:
iptables -t nat -I POSTROUTING -o br0 -j SNAT --to $(nvram get lan_ipaddr)
iptables -I FORWARD -i wl0.1 -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -m state --state NEW -j REJECT
iptables -I FORWARD -i wl1.1 -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -m state --state NEW -j REJECT
iptables -I INPUT -i wl0.1 -m state --state NEW -j REJECT
iptables -I INPUT -i wl1.1 -m state --state NEW -j REJECT
iptables -I INPUT -i wl0.1 -p udp -m multiport --dports 53,67 -j ACCEPT
iptables -I INPUT -i wl1.1 -p udp -m multiport --dports 53,67 -j ACCEPT
iptables -I FORWARD -d 192.168.178.3 -p tcp --dport 53 -j ACCEPT
iptables -I FORWARD -d 192.168.178.3 -p udp --dport 53 -j ACCEPT
Furthermore I would like to allow printing on the guest network, through a printer at 192.168.178.4.
I've tried this with the firewall rule:
iptables -I FORWARD -d 192.168.178.4 --dport 137, 9100 -state --new -j ACCEPT
or
iptables -I FORWARD -d 192.168.178.4 -p tcp --dport 137, 9100 -j ACCEPT
iptables -I FORWARD -d 192.168.178.4 -p udp --dport 137, 9100 -j ACCEPT
Both were however unsuccess.
How to allow guest to print on a printer on the private network, without giving guests access to the printer GUI at port 80?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Aug 09, 2019 9:55 Post subject:
In my first answer I began with:
Quote:
Wow a complicated setup
You are going to make it even more complicated (love it )
I use static routes for my OVPN server instead of NAT, actually to try this here so that you can use only one VPN is an interesting suggestion of Per Yngve (he is our networking and VLAN expert among other things)
Had not thought of that myself but it could work (I guess), problem is that you do not want the guest network to have access to the rest of your network but for this you need access at least to the primary router.
The following is all done on the secondary router:
I would start with deleting (just comment them out with a #) the firewall rules on the secondary router dealing with the isolation of the guest network (the drop and reject rules)
Also delete he NAT rule, that is the one which does the NATting.
Disable VPN of course
The next settings you do on the primary router:
Two things:
You have to set a static route on the primnary router so that this router knows where to send packet coming from the guest network those are the static routes.
On Setup/Advanced Routing you make two static routes for the two guest networks of the secondary router:
Destination: 10.0.30.0
Subnet 255.255.255.0
Gateway: 192.168.178.2 (IP address of secondary router)
Make the second static route for the other guest network
Now the second thing to do is to make a NAT rule to route traffic coming from the guest network out to the internet:
This is done because DDWRT only NAT's traffic from its own subnet onto the internet.
However you do not want to route traffic out via the internet but via the VPN so you actually do not need this rule, but I mention it so that you know that without this rule you do not have internet via the ISP/WAN for the guest networks of the secondary router (the guest networks of the primary router have their own NAT rules if you enabled NAT in the GUI for the interfaces which is enabled by default).
The OVPN client also has to NAT the traffic but in contrast to the NAT rule for the WAN the NAT rule for TUN1 by defaults NAT's all traffic.
You already have set the PBR rules for these guest subnets so it might work.
The added static routes will also be copied to the alternate routing table per the PBR script, take note it runs every 60 seconds so it can take up to a minute for the routing to work.
As said this is really complicated and not sure if or when it will work, we probably also need advice and help from others to get everything working
If it works then we have to deal with the Net isolation and will also deal with the printer
I am glad you are enjoying this as well!
This indeed sounds complicated, but maybe it does not need to be…
Per Yngve's instructions looked less complicated, so I decided to first go only with the static routes on the primary R7000. On the secondary R7000 I deleted the SNAT firewall rule and turned off the VPN client. Net isolation and NAT are enabled in the wl0.1/wl1.1 settings.
This already seems to do the job! https://www.whatismyip.net/ confirms wl0.1/wl1.1 on the secondary R7000 are using the VPN. Furthermore wl0.1/wl1.1 are isolated from the private network and using pi-hole.
Do I need to cleanup the firewall rules on the secondary R7000?
Netflix does not seem to be blocking my VPN provider (PIA), so for now I am safe and do not need to filter VPN traffic.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Aug 09, 2019 12:24 Post subject:
Great,
The INPUT rules on the secondary router prevent your guest networks from entering the secondary router and should be kept in place.
The FORWARD rules on the secondary router should actually prevent you from reaching anything on your network, so should also be kept in place.
I presumed that it would work with those rules in place but wanted to start with them disabled and enabling them when everyting was working (just in case ) .
Net isolation and enabling NAT does only work on the primary router that is why you need to manually add those rules on your secondary routers (as it is setup as a WAP)
With my explanation of setting the static routes I tried to give some background information that normally just setting those routes is not enough as you also have to add the extra NAT rule I described.
But in your case that is not necessary as the VPN NAT's all traffic.
So all you had to do is just setting the static routes either by GUI or manually
But my explantion was not an example of clarity I admit
Strangely enough wl0.1 on the secondary R7000 lost internet connection, while all settings seem similar to wl1.1.
Commenting out:
# iptables -I INPUT -i wl0.1 -m state --state NEW -j REJECT
# iptables -I INPUT -i wl1.1 -m state --state NEW -j REJECT
# iptables -I INPUT -i wl0.1 -p udp -m multiport --dports 53,67 -j ACCEPT
# iptables -I INPUT -i wl1.1 -p udp -m multiport --dports 53,67 -j ACCEPT
in the firewall rules of the secondary R7000 does not change anything for wl1.1, which still has internet connection.
I already copied the wl1.1 firewall rules and replaced wl1.1 with wl0.1. To be sure a hyphen/typo is not the cause.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Aug 09, 2019 14:37 Post subject:
Mozzy77 wrote:
Strangely enough wl0.1 on the secondary R7000 lost internet connection, while all settings seem similar to wl1.1.
Commenting out:
# iptables -I INPUT -i wl0.1 -m state --state NEW -j REJECT
# iptables -I INPUT -i wl1.1 -m state --state NEW -j REJECT
# iptables -I INPUT -i wl0.1 -p udp -m multiport --dports 53,67 -j ACCEPT
# iptables -I INPUT -i wl1.1 -p udp -m multiport --dports 53,67 -j ACCEPT
in the firewall rules of the secondary R7000 does not change anything for wl1.1, which still has internet connection.
I already copied the wl1.1 firewall rules and replaced wl1.1 with wl0.1. To be sure a hyphen/typo is not the cause.
Hmm, those INPUT rules are just there to shield your secondary router, they should have nothing to do with internet access.
The internet acces is taken care of by your primary router.
What is possible is the dreaded VAP bug, VAP's on Broadcom routers behave eraticaljy but not spontaneously, did you reboot or alter something?
To use unbridged VAP's I have to use a workaround and place the following rule in my start up script:
sleep 20; stopservice nas; wlconf eth1 down; wlconf eth2 down; wlconf eth1 up; wlconf eth2 up; startservice nas; logger "VAP workaround executed";
But there are other VAP workarounds circulating which also work
But first reboot primary router and then secondary router and see if that helps, check if the VPN is running
I decided to remove the wl0.1 VAP from the secondary R7000 for the time being. Most of our devices are 5GHz capable, so this should not be to big a problem. The wl0/wl1 (and VAPs) carry the same SSIDs on both R7000 .
)