What's new

KillSwitch doesn't work anymore on RT-AC86U (386.3_2)

  • 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!

Onilaq

New Around Here
Hi, after the upgrade to firmware 386.3_2 the killswitch feature doesn't work anymore.
When I stop the vpn client the routed clients "switch" to wan and continue to stay connect. Before the upgrade they would've just stop but now that function doesn't work anynmore.

I tried to add 192.168.1.0/24 (all clients) and also with manual ip addresses .... but nothing changed.


Screenshot 2021-09-10 at 09.12.45.png


Screenshot 2021-09-10 at 09.14.14.png





Could you help me to resolve this problem?

Thanks
 
I've already read that thread but before the upgrade when I switched manually off the vpn all the connection to it stopped. Now it doesn't do that.

Maybe I should downgrade to the previous version.
Its working just fine. But you testing it in a wrong way. Use "killall" and test again. There is som instruktions in wiki to read.
 
Its working just fine. But you testing it in a wrong way. Use "killall" and test again. There is som instruktions in wiki to read.
Is there a way to use killswitch like in the old fw version? If I voluntery/manually stop the vpn client its blocks the connection.
 
Is there a way to use killswitch like in the old fw version? If I voluntery/manually stop the vpn client its blocks the connection.

 

Thanks for that, I didn't think about iptables.

Btw with REJECT I got this error:
Bad argument `REJECT'
Try `iptables -h' or 'iptables --help' for more information.
 
Thanks for that, I didn't think about iptables.

Btw with REJECT I got this error:

Realize that as written, that script will only function as a firewall-start script, since only then will it be passed the WAN's network interface name as a command-line argument ($1) and properly initialize the WAN_IF variable. If you try to execute it from ssh, that's why the rule is producing an error (the fact it refers to REJECT is misleading).

If you want to use that script both from ssh and as a firewall-start script, the following would be better, since if the command-line argument is missing, it grabs it from nvram.

Code:
#!/bin/sh
WAN_IF="$([ $1 ] && echo $1 || echo $(nvram get wan0_ifname))"
iptables -I FORWARD -o $WAN_IF -j REJECT
 
Realize that as written, that script will only function as a firewall-start script, since only then will it be passed the WAN's network interface name as a command-line argument ($1) and properly initialize the WAN_IF variable. If you try to execute it from ssh, that's why the rule is producing an error (the fact it refers to REJECT is misleading).

If you want to use that script both from ssh and as a firewall-start script, the following would be better, since if the command-line argument is missing, it grabs it from nvram.

Code:
#!/bin/sh
WAN_IF="$([ $1 ] && echo $1 || echo $(nvram get wan0_ifname))"
iptables -I FORWARD -o $WAN_IF -j REJECT
Okay, it worked as intended.

Thank you again for the support, the thread can be closed.
 

Similar threads

Sign Up For SNBForums Daily Digest

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