Mapping SSID to VPN Client

[dbell]

I have devices that can't run the NordVPN client like TV's and Apple TV so I was hoping to do a simple guest SSID mapping to OVPNx using VPN Director policy rules. Then if I want to use VPN on those devices I can simply connect to the specific guest network and not have to change router configs.

I'm running Merlin 386.4 on a pair of AX86U's and I want to use 5G guest slot 1 so that I can connect via either my router or aimesh node.

I set up the 5G wireless guest network, no intranet access, all works fine. I set up the NordVPN config on OVPN1 and it works fine. I created a vpn director rule and used the specific IP address of my iPhone as source with the OVPN1 interface. My iPhone connects to the wireless, gets that IP address but cannot connect to the Internet.

I have searched the forums and I see similar posts, and have tried the manual option here https://github.com/RMerl/asuswrt-me...or-VPN-and-SSID-for-Regular-ISP-using-OpenVPN but can't seem to get this working. When I run that script using wl1.1 and the 102.x network range I get errors like this:

RTNETLINK answers: File exists
RTNETLINK answers: No such process

I tried walking through the various parts of it doing the manual equivalent and commands were accepted but didn't work overall.

Have not tried YazFi yet.

Connectivity does work if I enable the guest intranet access, my iPhone gets a lan dhcp address instead of the 102.x address from the guest network, and if I use that IP as the source then the iPhone connects over the VPN as confirmed using iplocation.net.

Seems like the intranet access off is the blocking problem here but I'm not familiar enough with the bridges, interfaces, routes and firewall rules to fix it.

Any advice or assistance much appreciated.

UPDATE: I tried YazFi and after misreading the "allow internet access" for "allow intranet access" and thus needing to allow it, it seems to work !

 

[eibgrad]

If you're happy w/ YazFi, perhaps it doesn't matter anymore. But for those w/ a similar issue in the future ….

The reason you can't access the VPN from guest #1 is that the router creates the 192.168.101.x and 192.168.102.x IP networks, along w/ the br1 and br2 bridges (2.4GHz and 5GHz respectively), and there are firewall rules that specifically limit routing to the internet via the WAN for br1 and br2.

Notice in the following dump of the FORWARD chain of the filter table that br0 can route anywhere (*), but br1 and br2 are specifically limited to routing over the WAN (eth0 on my router).

admin@lab-merlin1:/tmp/home/root# iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination       
...
    0     0 ACCEPT     all  --  br1    eth0    0.0.0.0/0            0.0.0.0/0         
    0     0 ACCEPT     all  --  br2    eth0    0.0.0.0/0            0.0.0.0/0         
...
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

It's an artifact from ASUS changing guest #1 for the benefit of AiMesh. This shouldn't be a problem w/ either guest #2 or #3 since they both share the IP network and bridge (br0) as the private network (the way guest #1 *used* to be configured). That's why we generally recommend ppl avoid using guest #1 if at all possible.

If you insist on using guest #1, the solution is to add firewall rules (using a firewall-start script) to allow routing by br1 and br2 to any of the VPN network interfaces (tun11, tun12, etc.).

iptables -I FORWARD -i br1 -o tun1+ -j ACCEPT
iptables -I FORWARD -i br2 -o tun1+ -j ACCEPT

 

[dbell]

If you're happy w/ YazFi, perhaps it doesn't matter anymore. But for those w/ a similar issue in the future ….

The reason you can't access the VPN from guest #1 is that the router creates the 192.168.101.x and 192.168.102.x IP networks, along w/ the br1 and br2 bridges (2.4GHz and 5GHz respectively), and there are firewall rules that specifically limit routing to the internet via the WAN for br1 and br2.

Notice in the following dump of the FORWARD chain of the filter table that br0 can route anywhere (*), but br1 and br2 are specifically limited to routing over the WAN (eth0 on my router).

admin@lab-merlin1:/tmp/home/root# iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination      
...
    0     0 ACCEPT     all  --  br1    eth0    0.0.0.0/0            0.0.0.0/0        
    0     0 ACCEPT     all  --  br2    eth0    0.0.0.0/0            0.0.0.0/0        
...
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0

It's an artifact from ASUS changing guest #1 for the benefit of AiMesh. This shouldn't be a problem w/ either guest #2 or #3 since they both share the IP network and bridge (br0) as the private network (the way guest #1 *used* to be configured). That's why we generally recommend ppl avoid using guest #1 if at all possible.

If you insist on using guest #1, the solution is to add firewall rules (using a firewall-start script) to allow routing by br1 and br2 to any of the VPN network interfaces (tun11, tun12, etc.).

iptables -I FORWARD -i br1 -o tun1+ -j ACCEPT
iptables -I FORWARD -i br2 -o tun1+ -j ACCEPT

Thanks so much for the detail - that makes sense. Life would be simpler just avoiding guest slot 1, but the devices need the coverage area of both router and node.