RT-AC68U: guest networks in AP mode using vlan and iptables

[grifo]

You could try doing something like what @Adamm is doing for Skynet on the service-event script, using restart and wireless as args then calling the bridge-reset script.

grifo@r1:/jffs/scripts# cat service-event | grep Skynet
if [ "$1" = "start" ] && [ "$2" = "SkynetStats" ]; then sh /jffs/scripts/firewall debug genstats; fi # Skynet Firewall Addition
grifo@r1:/jffs/scripts#

 

[robca]

Yes, that's surely going to work as expected as soon as the right values are used for $1 and $2. As soon as I have time to test it, I'll post update here for everyone else in the future.

I was looking for examples and had not found that yet. You are an amazing resource for this forum!

 

[grifo]

Yes that looks better, pity it didn't exist when I did this script, I saw it a few months ago and thought about using that for it at some point, I don't want to mess around with my scripts too often when they work

Note that for this script it's best to use service-event-end not service-event, the former wasn't available until firmware 384.11 so for a while I used the latter but had to add in a sleep function else it ran before the wireless restart had completed and the wl interfaces were dropped back into br0.

Thanks for your words, I enjoy doing my bit for this great community.

 

[robca]

Ok, I'm back with the results of testing your suggestions.

I created the following script /jffs/scripts/service-event-end

#!/bin/sh
if [ "$1" = "restart" ] && [ "$2" = "wireless" ]
then
  logger -p user.info Wireless Service restart, fixing guest networks

  brctl delif br0 wl0.1
  brctl delif br0 wl1.1
  brctl addif br1 wl0.1
  brctl addif br1 wl1.1

  nvram set lan_ifnames="vlan1 eth1 eth2"
  nvram set lan_ifname="br0"
  nvram set lan1_ifnames="vlan101 wl0.1 wl1.1"
  nvram set lan1_ifname="br1"
  nvram commit

  killall eapd
  eapd
else   
  logger -p user.info $1 $2
fi

I decided to log all the service-event-end, to see how many times it gets called, and as a confirmation that it's actually better to have a conditional execution.

From the log, here is what I see when I add or remove a guest network:

May 19 15:37:03 custom_script: Running /jffs/scripts/service-event-end (args: restart wireless)
May 19 15:37:03 admin: Wireless Service restart, fixing guest networks
[…]
May 19 15:37:05 custom_script: Running /jffs/scripts/service-event-end (args: restart qos)
May 19 15:37:05 custom_script: Running /jffs/scripts/service-event-end (args: restart firewall)
May 19 15:37:05 admin: restart firewall
May 19 15:37:05 admin: restart qos

As you can see, the service-event-end script gets called three times, the first one for the wireless restart, the other times for QOS and firewall services.

With your current code, you execute the brctl/nvram/eapd instructions 3 times. Which is not going to do any real harm, but just wastes a bit of time

I would recommend everyone reading this in the future to have a /jffs/scripts/service-event-end as follows

#!/bin/sh
if [ "$1" = "restart" ] && [ "$2" = "wireless" ]
then
  # Optional: log event
  # logger -p user.info Wireless Service restart, fixing guest networks

  #insert your configuration here for brctl (only the part related to wlx.y, not the one about bringing up a new bridge)

  # insert nvram configuration

  killall eapd
  eapd
fi

As far as I can tell, there is really no reason to have two separate scripts, with the service-event-end calling the other. The code runs fast enough and it's guaranteed not to be blocking to be safe to run from just the service-event-end script. Only if there were code that can block and never exit, then it would be better to spawn a new script, so that in case that portion hangs, the system keeps working. A blocking statement in the service-event-end script would hang the system

 

[grifo]

Very good work and a definitive guide on how to use the service-event scripts that as far as I know wasn't available on the forum, these scripts can come very handy for a variety of purposes.

I've already updated my router an AP and the scripts are working fine.

 

[robca]

And one more note again for the users of Diversion (https://diversion.ch/), the amazing ad-blocker extension for AsusWRT Merlin.

When using Diversion with pixelserv-tls, clients on the vlan (br1) cannot access pixelserv-tls (usually on the router IP address+1), since all non DNS traffic from br1 to br0 is blocked by the IPTABLES rules. That prevents web pages from loading correctly, while everything else works normally. So two more IPTABLES rules are needed to allow certain pages to load properly

iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT

to unblock the web page. But this alone won't make pixelserv-tls reachable, only allows web pages to load with the ugly grey "can't load the element' box

adding also

iptables -I FORWARD -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT

allows clients on the vlan (hence br1) to reach pixelserv-tls, assuming that it is on 192.168.1.2 (change it to the proper pixelserv-tls address for your installation)

So the updates firewall-start script is

/jffs/scripts/firewall-start

# Allow BR1 to access WAN
iptables -D FORWARD -i br1 -m state --state NEW -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT

# Prevent BR1 from accessing BR0 and vice versa
iptables -D FORWARD -i br1 -o br0 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP

iptables -D FORWARD -i br0 -o br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP

# DROP NEW packets, will let thru only ESTABLISHED packets
iptables -D INPUT -i br1 -m state --state NEW -j DROP >/dev/null 2>&1
iptables -I INPUT -i br1 -m state --state NEW -j DROP

# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p tcp --dport 53 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT

# Allow DNSMASQ to distribute IP addresses for br1.
iptables -D INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -p udp -m multiport --dport 53,67 -j ACCEPT

# Allow guest network devices to access pixelsrv-tls on 192.168.1.2
iptables -D INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT >/dev/null 2>&1
iptables -I INPUT -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT

iptables -D FORWARD -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT >/dev/null 2>&1
iptables -I FORWARD -i br1 -d 192.168.1.2/32 -p tcp -m multiport --dport 80,443 -j ACCEPT

sleep 1
killall eapd
eapd