Disable internet access via command line

[threemonks]

I tried to disable internet access via command line using the following command:

nvram set wan_enable=0
nvram set wan0_enable=0
nvram commit

But it does not work, because internet is still accessible after the above command. Any suggestion what I am doing wrong?

Thanks

 

[ColinTaylor]

Try this:

service stop_wan

 

[threemonks]

Thanks. That works well.

 

[threemonks]

Also, I tried to schedule this as cron job on the router itself, but it seems that the openvpn service installed a cron job that checked and re-enabled wan every 2 minutes:

*/2 2-23 * * * /etc/openvpn/server1/vpns-watchdog1.sh #CheckVPNServer1#
30 00 * * * /sbin/service stop_wan #stop wan#
00 06 * * * /sbin/service start_wan #start wan#

The cron job I added via crontab -e seems to be gone a few hours later even without router reboot. So the wan ends up stay offline until I manually intervene. Any idea what else might be causing the cron job to be removed?

 

[eibgrad]

Why not just block/unblock the WAN's network interface (I assume this is intended only for the clients behind the router)?

iptables -I FORWARD -m time --timestart 23:00 --timestop 06:00 --days Mon,Tue,Wed,Thu,Fri -o $(nvram get wan0_ifname) -j REJECT

IOW, no internet access from 11:00 PM until 6:00AM, Mon thru Fri.

Notice you don't even need to use cron. The rule itself determines the time that it's valid. Only caveat is that I found the --days option was NOT supported on my version of the firmware. Worst case, you can use the following w/ cron.

# deny internet access by clients
iptables -I FORWARD -o $(nvram get wan0_ifname) -j REJECT

# grant internet access by clients
iptables -D FORWARD -o $(nvram get wan0_ifname) -j REJECT

The advantage using the firewall is that at least the router itself continues functioning normally, including DHCP renewals, time updates, etc.

 

[ColinTaylor]

The cron job I added via crontab -e seems to be gone a few hours later even without router reboot. So the wan ends up stay offline until I manually intervene. Any idea what else might be causing the cron job to be removed?

You shouldn't add cron jobs that way. It's better to put a "cru" command in a services-start script.

I think the disappearing cron table is caused by a faulty third-party script.

 

[threemonks]

@ColinTaylor that could be it. I will try the `cru` command in services-start script.

@eibgrad Thanks. I will try iptables without days parameter as well.

 

[threemonks]

It seems my iptables rule are also removed by some other job or software. So is the authorized keys that I added for passwordless ssh login. The router was not rebooted while those happens. So there appear to be some job that is refreshing iptables from content on disk, and also overriding .ssh/authorized_keys.

I don't find any suspicious message in syslog.

 

[eibgrad]

It seems my iptables rule are also removed by some other job or software. So is the authorized keys that I added for passwordless ssh login. The router was not rebooted while those happens. So there appear to be some job that is refreshing iptables from content on disk, and also overriding .ssh/authorized_keys.

I don't find any suspicious message in syslog.

Can't speak to the issue of the disappearing authorized_keys. That field should be stored in nvram and persistent across a reboot. Something else going on there that escapes me.

As far as the firewall rule I described intially, realize the router uses an event-driven model to add user-defined rules. Make sure to have JFFS Custom Scripts enabled (Administration->System) and that you create a file under /jffs/scripts called firewall-start that contains the rule.

You can paste the following into a shell and it will configure everything for you.

mkdir -p /jffs/scripts

cat << "EOF" > /jffs/scripts/firewall-start
#!/bin/sh
iptables -I FORWARD -m time --timestart 23:00 --timestop 06:00 --days Mon,Tue,Wed,Thu,Fri -o $(nvram get wan0_ifname) -j REJECT
EOF

chmod +x /jffs/scripts/firewall-start

 

[threemonks]

iptables uses UTC by default, so I adjusted the time to use UTC timestamp. The firewall rule is effective in blocking internet traffic, but it blocks internet traffic even after the specified period.

Do I need to do anything else to refresh the firewall rules at the beginning and end of the specified period?

Thanks

 

[ColinTaylor]

Check that your iptables rules are being excepted. With newer versions of iptables --days has been replaced with --weekdays. Regarding UTC, you can then add the --kerneltz option to use your local timezone. So you would end up with something like this:

iptables -I FORWARD -i br0 -m time --timestart 23:00 --timestop 06:00 --weekdays Mon,Tue,Wed,Thu,Fri --kerneltz -j DROP

The firewall rule is effective in blocking internet traffic, but it blocks internet traffic even after the specified period.

Sometimes strange things happen when crossing midnight. You might have to split the rule into two.

iptables -I FORWARD -i br0 -m time --timestart 23:00 --timestop 00:00 --weekdays Mon,Tue,Wed,Thu --kerneltz -j DROP
iptables -I FORWARD -i br0 -m time --timestart 00:00 --timestop 06:00 --weekdays Tue,Wed,Thu,Fri --kerneltz -j DROP

EDIT: I've just re-read your post #4 and it looks like you're not restricting specific days and your blocking is after midnight. So your rule would be:

iptables -I FORWARD -i br0 -m time --timestart 00:30 --timestop 06:00 --kerneltz -j DROP

 

[threemonks]

So to achieve the goal of blocking internet connection, either -j DROP or -j REJECT would work. But what's the difference between -i br0 vs -o $(nvram get wan0_ifname)?

It still puzzles me why would the time range does not work as expected (The rule does kick in at the timestart (UTC), but the rule stays in effective even after timestop)

 

[ColinTaylor]

But what's the difference between -i br0 vs -o $(nvram get wan0_ifname)?

In the first case you are blocking traffic coming from the LAN, in the second case you are blocking traffic going out of the WAN interface. It is usually better to use the first method because the second can be bypassed by VPN rules.

It still puzzles me why would the time range does not work as expected (The rule does kick in at the timestart (UTC), but the rule stays in effective even after timestop)

Without having access to your router it's impossible to say. One thing to bear in mind is that hardware acceleration bypasses these rules for established connections. So don't expect to see an existing connection suddenly being terminated. It should effect new connections though.

This does raise an interesting point though. What you're doing is the same as what the Network Services Filter does. So you might as well use that and save yourself some effort. Actually the VPN client also bypasses the Network Services Filter, so forget that idea.

 

[itpp20]

One thing to bear in mind is that hardware acceleration bypasses these rules for established connections. So don't expect to see an existing connection suddenly being terminated. It should effect new connections though.

conntrack -D --src=192.168.1.100
Kill active links after FW change to block 'src'

 

[ColinTaylor]

conntrack -D --src=192.168.1.100
Kill active links after FW change to block 'src'

conntrack-tools is not included with the firmware. Or at least it isn't with mine.

 

[itpp20]

It is with merlin RT-AC68U_384.17_0

 

[threemonks]

One thing to bear in mind is that hardware acceleration bypasses these rules for established connections. So don't expect to see an existing connection suddenly being terminated. It should effect new connections though.

I understand this issue. I can move the timestart earlier or disable hardware acceleration. But the issue for me now is that the internet blocking continues to be in effect even after the specified timestop, that completely defeats the desired blocking time period.

 

[ColinTaylor]

But the issue for me now is that the internet blocking continues to be in effect even after the specified timestop, that completely defeats the desired blocking time period.

Try disabling hardware acceleration and see if that makes a difference, although I can't think why it would.

Otherwise post the output of the following command (when the firewall rule is in effect).

iptables-save | grep time

 

[brummygit]

conntrack -D --src=192.168.1.100
Kill active links after FW change to block 'src'

Apologies for going slightly off topic. I've been looking for a way to reset all active connections once FlexQoS (or other QoS implementations) have been loaded up as existing connections simply continue outside of the QoS using bandwidth that QoS thinks it has available. This causes me problems if my IoT devices such as CCTV cameras connect and starts streaming before QoS is up and running.

Would this conntrack command reset every open connection?

 

[ColinTaylor]

@brummygit https://conntrack-tools.netfilter.org/conntrack.html