What's new

VPN Director Rules not working with Guest wifi

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Steve2300

Occasional Visitor
Attached is how the VPN rules are configured.

Everything is working as expected apart from guest clients.

Any guest clients can't connect to the internet if OVPN4 is active, heck even tried to change VPN providers and I even changed the rule to OVPN5 with no luck.

The problem is in the 192.168.101.x clients.

If I use the 2nd or 3rd guest wifi, the router is giving them the same 192.168.1.x addresses as my main network. Are these devices/clients in an isolated network?

I want an isloated network for all my IoT devices and for any family/friends connecting to my wifi.

Thank you



VPN Director1.jpg
 
The problem has to do w/ the fact that guest #1 has been hacked by ASUS for the benefit of AiMesh. Unlike guest #2 and #3, guest #1 places its clients on a new bridge (br1 for 2.4GHz, br2 for 5GHz), which does NOT have a FORWARD rule in the firewall to allow it access to the OpenVPN client's tunnel.

Code:
admin@lab-merlin1:/tmp/home/root# iptables -vnL FORWARD --line-numbers
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination       
1        0     0 DROP       all  --  *      eth0    0.0.0.0/0            10.0.0.0/8           state NEW
2        0     0 DROP       all  --  *      eth0    0.0.0.0/0            172.16.0.0/12        state NEW
3        0     0 DROP       all  --  *      eth0    0.0.0.0/0            192.168.0.0/16       state NEW
4        0     0 ACCEPT     all  --  eth0   *       192.168.61.0/24      0.0.0.0/0            state NEW
5        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
6        0     0 OVPNSF     all  --  *      *       0.0.0.0/0            0.0.0.0/0         
7        0     0 WGNPControls  all  --  br1    *       0.0.0.0/0            0.0.0.0/0         
8        0     0 ACCEPT     all  --  br1    eth0    0.0.0.0/0            0.0.0.0/0         
9        0     0 WGNPControls  all  --  br2    *       0.0.0.0/0            0.0.0.0/0         
10       0     0 ACCEPT     all  --  br2    eth0    0.0.0.0/0            0.0.0.0/0         
11       0     0 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0         
12       0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0         
13       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
14       0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0         
15       0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0         
16       0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
17       0     0 OVPNCF     all  --  *      *       0.0.0.0/0            0.0.0.0/0         
18       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Notice in line #15 that br0 (the private network) has outbound access to anything, but in line #8 and #10, br1 and br2 (respectively) only have access to the WAN (eth0 in my case).

IOW, this isn't an issue w/ the VPN Director itself (the routing is correct), but the firewall is denying the access.

None of this was an issue before ASUS changed guest #1. Like guest #2 and #3, guest #1 was using the same IP network (br0) as the private network.

This is why we generally recommend staying away from guest #1 unless you are specifically using it for AiMesh purposes. ASUS messed with it to the point that it broke this and other things.
 
This commit was supposed to address Guest Network #1 and VPN tunnels in 386.3, but was lost in 386.4.


 
Last edited:
This commit was supposed to address Guest Network #1 and VPN tunnels in 386.3, but was lost in 386.4.



It's been an apparent regression for so long, I didn't even know it had ever been fixed! LOL

Thanks.
 
This is why we generally recommend staying away from guest #1 unless you are specifically using it for AiMesh purposes. ASUS messed with it to the point that it broke this and other things.


Thanks.

So if I use the 2nd or 3rd guest wifi, the router is giving them the same 192.168.1.x addresses as my main/private network.

Are these devices/clients in an isolated network?

I want an isolated network for all my IoT devices and for any family/friends connecting to my wifi.
 
Thanks.

So if I use the 2nd or 3rd guest wifi, the router is giving them the same 192.168.1.x addresses as my main/private network.

Are these devices/clients in an isolated network?

I want an isolated network for all my IoT devices and for any family/friends connecting to my wifi.

They are isolated provided the Access Intranet option is configured as Disabled. This enables an ethernet (layer 2) firewall called ebtables to prevent access between the wireless guests and any other wired devices on the same IP network. AP isolation prevents access between the wireless clients themselves.
 
They are isolated provided the Access Intranet option is configured as Disabled. This enables an ethernet (layer 2) firewall called ebtables to prevent access between the wireless guests and any other wired devices on the same IP network. AP isolation prevents access between the wireless clients themselves.

Even if they are in the same IP pool ?
 
Even if they are in the same IP pool ?

Yes. Although wired and wireless clients share the same IP network (which would normally make it impossible to use the router's IP firewall to enforce isolation between them), ebtables creates the isolation at the ethernet level.

In the following example, guest #2 on 2.4GHz (wl0.2) is bridged to br0 private network, yet that same interface is denied access w/ ebtables.

Code:
admin@lab-merlin1:/tmp/home/root# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.1cb72ccb0960    yes        vlan1
                            eth1
                            eth2
                            wl0.2

admin@lab-merlin1:/tmp/home/root# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 3, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

Only caveat is that the iolsation is limited to ICMP and TCP. Why? I have no idea. That's a decision made by ASUS.
 
Last edited:
Yes. Although wired and wireless clients share the same IP network (which would normally make it impossible to use the router's IP firewall to enforce isolation between them), ebtables creates the isolation at the ethernet level.

Thank you.

What if I connect an rt-ac68u via LAN and that router creates a separate wifi for IoT and guests ? Would that also means it is isolated?

Should I add/change anything in the settings to ensure total separation ?
 
Thank you.

What if I connect an rt-ac68u via LAN and that router creates a separate wifi for IoT and guests ? Would that also means it is isolated?

Should I add/change anything in the settings to ensure total separation ?

Depends on whether you connect the rt-ac68u via its WAN or LAN.

If the rt-ac68u is connected WAN to LAN wrt the primary router, then it's own local IP networks are isolated from the upstream network(s) of the primary router in the sense they are unreachable due to the rt-ac68u's firewall. But the rt-ac68u's networks can still reach the upstream local network(s) of the primary router. So you need to explicitly deny that access w/ firewall rules on the rt-ac68u.

If the rt-ac68u is connected LAN to LAN wrt the primary router, then by definition it becomes part of the primary router's private network.
 
Depends on whether you connect the rt-ac68u via its WAN or LAN

Thanks again for your helpful replies.

I admit my question was confusing.

My setup would be:

RT-AC86U running merlin
wifi = private (iPhones..etc)
Lan1 = PC 1
Lan2 = PC 2
Lan3 = PC 3
Lan4 ===> WAN rt-ac68u which wifi is only for IoT and guests.

Does that make sense? And what steps should take to ensure separation of networks.

Thank you
 
Thanks again for your helpful replies.

I admit my question was confusing.

My setup would be:

RT-AC86U running merlin
wifi = private (iPhones..etc)
Lan1 = PC 1
Lan2 = PC 2
Lan3 = PC 3
Lan4 ===> WAN rt-ac68u which wifi is only for IoT and guests.

Does that make sense? And what steps should take to ensure separation of networks.

Thank you

There's still some ambiguity here in your description.

The RT-AC68U provides more than just additional wifi options in a WAN to LAN (of the primary router) configuration. That router still has a private network w/ its own wifi, *plus* guest wifi options. It's unclear how you intend to deploy these options.

For example, you *might* decide to make the private network of the RT-AC68U an IOT network, particularly since then it could support wired devices too. Or perhaps you have other intentions for the private network, and quite literally intend to use the guest wifi for IOT purposes. But that limits you to wireless only w/ IOT, at least if we assume you're using Merlin (which does NOT natively support VLANs). But even the use of Merlin is an assumption. You could use FreshTomato (my preference) or DD-WRT so you *could* create VLANs to use w/ the guest wifi.

IOW, I don't want to get into the finer details until I know precisely your intentions beyond simply whether you're connected LAN to LAN vs. LAN to WAN.
 
For example, you *might* decide to make the private network of the RT-AC68U an IOT network, particularly since then it could support wired devices too.


You are absolutely correct here. Every device connecting via the rt-68u will be IoT or guest devices. I could use the private network or guests wifi, all the same to me.

I'm connecting LAN4 of the main router to WAN of rt-68u (which is running stock firmware) and in doing so they have their own network.

Is my understanding correct or are there steps or configuration I should do to ensure that devices connected via rt-68u don't see or interact with my main router's network.

I really appreciate your time and effort in replying and explaining it. Thank you.
 
I had recently a similar issue with VPN routing to Guest WLAN - I started with the VPN director rule by using 192.168.2.0/24 as sub network, but it did not work...

When I checked my Guest WLAN address range with ip addr is found:
25: wl1.1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether 24:4b:fe:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global wl1.1
valid_lft forever preferred_lft forever


Then I used 192.168.2.1/24 in VPN director and it worked for me!
 
You are absolutely correct here. Every device connecting via the rt-68u will be IoT or guest devices. I could use the private network or guests wifi, all the same to me.

I'm connecting LAN4 of the main router to WAN of rt-68u (which is running stock firmware) and in doing so they have their own network.

Is my understanding correct or are there steps or configuration I should do to ensure that devices connected via rt-68u don't see or interact with my main router's network.

I really appreciate your time and effort in replying and explaining it. Thank you.

Assuming Merlin, you just need to add a firewall-start script to the IOT router to deny its clients access to any upstream private IP network(s).

Code:
#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/firewall-start"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh

# optional: deny access to *any* upstream private ip networks
iptables -I FORWARD -o $1 -d 10.0.0.0/8 -j REJECT
iptables -I FORWARD -o $1 -d 172.16.0.0/12 -j REJECT
iptables -I FORWARD -o $1 -d 192.168.0.0/24 -j REJECT

# specifically deny access to immediate upstream private ip network
iptables -I FORWARD -o $1 -d $(nvram get wan0_ipaddr)/$(nvram get wan0_netmask) -j REJECT

exit 0
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

You'll need to enable JFFS scripts and configs in Administration > System. Then ssh to the router and copy/paste the above into the terminal window. It will automatically install and configure the script. Finally reboot.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top