KILLMON KILLMON v1.1.2 -Feb 29, 2024- IP4/IP6 VPN Kill Switch Monitor & Configurator (Now available in AMTM!)

[Viktor Jaep]

That is because you are clever and an awesome coder! Keep up the brilliant works!

@Viktor Jaep for his musical montage!

Hahaha you crack me up @SomeWhereOverTheRainBow! Thank you!

 

[eleVator]

Following happened.

Killmon enabled, watching vpnmon-r2 and also watching dns traffic with eibgrad script, also pinging 8.8.8.8 from LAN PC.
Made a change in web UI WAN Internet connection and pressed apply.
Once the UI finished loading 100% and page was reloading i pressed R for reset in vpnmon-r2.
Ping window on LAN PC as expected stopped, though just for a second or two and whilst vpnmon was going through it's reconnect cycle the ping window started again for 5 lines before killmon fw setup blocked it again, effectively bypassing killmon.

 

[Viktor Jaep]

Following happened.

Killmon enabled, watching vpnmon-r2 and also watching dns traffic with eibgrad script, also pinging 8.8.8.8 from LAN PC.
Made a change in web UI WAN Internet connection and pressed apply.
Once the UI finished loading 100% and page was reloading i pressed R for reset in vpnmon-r2.
Ping window on LAN PC as expected stopped, though just for a second or two and whilst vpnmon was going through it's reconnect cycle the ping window started again for 5 lines before killmon fw setup blocked it again, effectively bypassing killmon.

How do you have killmon configured? What IP address is your lan PC that's pinging 8.8.8.8? Also, what exactly did you change in the UI that caused it to update and reset?

 

[eleVator]

How do you have killmon configured? What IP address is your lan PC that's pinging 8.8.8.8? Also, what exactly did you change in the UI that caused it to update and reset?

I am working on having no DNS leaks and making sure that ALL traffic goes always through the VPN hence why i come to killmon.

vpnmon is watching over 2 vpn clients with same exit point.
VPN Director has 2 rules, ovpn1 and ovpn2 both for 192.168.50.0/24
killmon paranoid mode wouldn't let vpnmon get it's nordVPN updates so i tried ranged mode, leaving router IP out of that range, router IP 192.168.50.20, ranged mode 192.168.50.21 - 192.168.50.255
In this range is the LAN PC and a rpi pihole server. Pihole ip is in DNS Server 1 (DNS and WINS Server Setting) field. DNS Director ON, Global Redirection Router and Client list has the pihole with No redirection.
webUI changes were checking out what happens regarding leaks in Advanced_WAN_Content when changing DNS fields.

I have not found a way have killmon/vpnmon working without leaking DNS as much as i do not understand how a fw rule that is supposed to be persistent could be bypassed.

 

[Viktor Jaep]

I am working on having no DNS leaks and making sure that ALL traffic goes always through the VPN hence why i come to killmon.

vpnmon is watching over 2 vpn clients with same exit point.
VPN Director has 2 rules, ovpn1 and ovpn2 both for 192.168.50.0/24
killmon paranoid mode wouldn't let vpnmon get it's nordVPN updates so i tried ranged mode, leaving router IP out of that range, router IP 192.168.50.20, ranged mode 192.168.50.21 - 192.168.50.255
In this range is the LAN PC and a rpi pihole server. Pihole ip is in DNS Server 1 (DNS and WINS Server Setting) field. DNS Director ON, Global Redirection Router and Client list has the pihole with No redirection.
webUI changes were checking out what happens regarding leaks in Advanced_WAN_Content when changing DNS fields.

I have not found a way have killmon/vpnmon working without leaking DNS as much as i do not understand how a fw rule that is supposed to be persistent could be bypassed.

Granted, I'm not using Pihole, but I am not able to duplicate this issue... it's killing all traffic for me, including DNS traffic.

I have tried single-IP and range mode both successfully in my testing this morning... my laptop is in the range, and was successfully blocked from pinging 8.8.8.8 as the VPN went down. Ping came back up as the tunnel was re-established.

I was simultaneously watching the DNS monitor, and could even see that it was trying to make connections to secondary DNS servers during this time, which it normally doesn't unless the primary is unreachable. I'm not sure what kind of magic Pihole has, or perhaps it's finding some other way around the iptables rules?

The reason I asked what you changed in the router UI that caused it to apply/reset, because an event like this could very well likely reset the iptables and set them back to defaults, which would eliminate killmon's rules. This is why I cautioned that you need to keep an eye on killmon, check in every once in a while to ensure that its still showing that rules are found and verified.

 

[Viktor Jaep]

Minor update to v1.01 today... found a small typo in the ip6tables logic. Enjoy!

What's new?
v1.01 - (December 9, 2022)
* FIXED: Found a minor typo in the ip6tables logic. If you currently have IP6 rules enabled, please disable and re-enable to reset them.

Download link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/KILLMON/master/killmon-1.01.sh" -o "/jffs/scripts/killmon.sh" && chmod a+rx "/jffs/scripts/killmon.sh"

 

[Viktor Jaep]

Just a testament that killmon is working as advertised... I mistakingly stopped my VPN connection from remote, and killmon blocked everything from making it out over the WAN. My wife and kids thought the internet went down. Started getting google camera/doorbell alerts that all devices had become unavailable. TeamViewer was no longer functional, and all my backdoors to get into my home network we're locked securely. Nothing was going in or out. After this "incident" and profuse apologies to my family for the unintended downtime, I have high confidence that killmon will do the job for those who need this extra layer of protection.

 

[visortgw]

Just a testament that killmon is working as advertised... I mistakingly stopped my VPN connection from remote, and killmon blocked everything from making it out over the WAN. My wife and kids thought the internet went down. Started getting google camera/doorbell alerts that all devices had become unavailable. TeamViewer was no longer functional, and all my backdoors to get into my home network we're locked securely. Nothing was going in or out. After this "incident" and profuse apologies to my family for the unintended downtime, I have high confidence that killmon will do the job for those who need this extra layer of protection.

"Sorry, honey, just completing my testing."

 

[Viktor Jaep]

"Sorry, honey, just completing my testing."

Exactly... "you all are going to get something extra in your Christmas stockings for being such awesome beta testers". Lol

 

[eleVator]

Just a testament that killmon is working as advertised... I mistakingly stopped my VPN connection from remote, and killmon blocked everything from making it out over the WAN. My wife and kids thought the internet went down. Started getting google camera/doorbell alerts that all devices had become unavailable. TeamViewer was no longer functional, and all my backdoors to get into my home network we're locked securely. Nothing was going in or out. After this "incident" and profuse apologies to my family for the unintended downtime, I have high confidence that killmon will do the job for those who need this extra layer of protection.

The leak that happens is for a very short time window, enough to expose LAN clients but not enough for all this IoT and other software you mentioned to stay up.

I am not saying that your coding is at fault but you indicate yourself that the router is not to be trusted and can ignore any rules defined by the user.

because an event like this could very well likely reset the iptables and set them back to defaults,

One would have to have another watchdog script preferably running on another lan client to check if the router scripts are running, though wouldn't that be to late in some cases.

I am testing this on my new GT-AX6000.

Replicate the leak:
It is easier to see if you set up your VPN clients for this test to a far away exit point making the ping higher but not necessary if you can switch TABs quick.

1. Start a ping on LAN client, not by name but by IP, example: ping 8.8.8.8
2. Start a ssh session to router and check if killmon is still working
3. screen into vpnmon and watch it is going through it's cycle successfully
4. In Browser open a TAB to vpn Director and another TAB with the WAN page
5. in the WAN Page click on Assign and switch to another DNS. ( in my test i used ISP and switched back and forth between ISP & Manual Setting DNS Server1 to 1.1.1.1)
6. click OK
7. click Apply and wait for it to reach 100%
8. the moment the page refreshed go click (R)eset in the vpnmon
9. switch to VPN Director TAB and keep refreshing it, you will see the VPN connection being up and then get disconnected
10. look at your ping window, few pings will go through then be blocked again at the same time DNS Director Page is still showing that there is no VPN up when this few pings go through bypassing killmon rules
11. if you used a far away exit point your pings would have a higher reply time showing at start and the moment killmon fails your ping 8.8.8.8 would drastically drop to quicker replies for a brief moment, quicker because now you are not using the VPN and get quicker replies from your local ISP exit point

That brief moment is the leak, that should not happen but i understand that this is what you get from this kind of application devices.

 

[SomeWhereOverTheRainBow]

One would have to have another watchdog script preferably running on another lan client to check if the router scripts are running, though wouldn't that be to late in some cases.

I wouldn't necessarily say a watchdog is needed, this could simply be corrected with a script that runs based on events. The script would obviously work better with a small delay perhaps a service event end. One would only need to understand the events that cause the breaking changes.

 

[SomeWhereOverTheRainBow]

Just a testament that killmon is working as advertised... I mistakingly stopped my VPN connection from remote, and killmon blocked everything from making it out over the WAN. My wife and kids thought the internet went down. Started getting google camera/doorbell alerts that all devices had become unavailable. TeamViewer was no longer functional, and all my backdoors to get into my home network we're locked securely. Nothing was going in or out. After this "incident" and profuse apologies to my family for the unintended downtime, I have high confidence that killmon will do the job for those who need this extra layer of protection.

You got this!

Exactly... "you all are going to get something extra in your Christmas stockings for being such awesome beta testers". Lol

We are all beta testers.

 

[Wrkdbf_Guy]

We are all beta testers.

His wifey and his little Viks might differ with you on this. (grin)

 

[SomeWhereOverTheRainBow]

His wifey and his little Viks might differ with you on this. (grin)

That is because they are the at home beta testers - a.k.a. team vik.

 

[Viktor Jaep]

The leak that happens is for a very short time window, enough to expose LAN clients but not enough for all this IoT and other software you mentioned to stay up.

I am not saying that your coding is at fault but you indicate yourself that the router is not to be trusted and can ignore any rules defined by the user.

Good catch, @eleVator! Thanks for the great step-by-steps... I was able to confirm what you're seeing. As I suspected, after making such a major change to the WAN settings, it basically resets everything, and all custom iptables rules are thrown out... thus leaving you momentarily exposed until rules are reset again through the firewall-start event...

Dec 11 09:29:55 rc_service: httpd 1958:notify_rc restart_wan_if 0;restart_stubby
Dec 11 09:29:55 custom_script: Running /jffs/scripts/service-event (args: restart wan_if)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 stopping)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 disconnected)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 stopped)
Dec 11 09:29:55 wsdd2[3753]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 stopped)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 init)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 connecting)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/service-event-end (args: restart wan_if)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/service-event (args: restart stubby)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 disconnected)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/wan-event (args: 0 stopped)
Dec 11 09:29:55 custom_script: Running /jffs/scripts/service-event-end (args: restart stubby)
Dec 11 09:29:56 wsdd2[3753]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Dec 11 09:29:56 custom_script: Running /jffs/scripts/wan-event (args: 0 connected)
Dec 11 09:29:56 wan-event[1981]: Started wanuptime with pid 1983
Dec 11 09:29:56 wanuptime[1983]: Started by wan-event, new event date/time recorded in RAM save file
Dec 11 09:29:56 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 11 09:29:56 wan: finish adding multi routes

I noticed that that it's definitely not instantaneous, and there is a good little stretch of time until those firewall rules are reset. When this happens, the killmon UI will indicate this:

and vpnmon-r2 UI will indicate this (when you're running the upcoming version that integrates checking for killmon rules):

but then, shortly after the firewall-start script takes effect, all rules are back in place.

So lessons learned here:
1.) Don't trust using consumer devices (like these) to run hardened kill switch environments that catch 100% of security exceptions. If you want to do this right, I'm sure there are commercial solutions or nice open-source software packages that run on a linux box out there that perform this function admirably.
2.) Don't make major WAN changes while a kill switch is in place because doing so will reset all your iptables rules, leaving you exposed until they are reset. If you truly want to be safe, take the WAN down, disconnect your router/firewall... make your critical changes, test, test, test, reconnect and bring the WAN back up.
3.) Killmon should work in most stable scenarios, granted your are not making major configuration changes your router while the kill switch is running... but evenso, like you said..

That brief moment is the leak, that should not happen but i understand that this is what you get from this kind of application devices.

And unfortunately that's what we have to live with...

 

[Viktor Jaep]

That is because they are the at home beta testers - a.k.a. team vik.

@Wrkdbf_Guy @SomeWhereOverTheRainBow ... all I get to hear is this endless "why can't we be like a normal family, with a normal internet connection, where it just WORKS all the time". No appreciation for the amount of country blacklisting, DoT, whole-home secure random VPN tunnels all over the country, kill switch blackouts, or all the ad/malware blocking that is going into all this... little do they know. But man, if that internet goes down, I'm definitely on the receiving end.

 

[eleVator]

2.) Don't make major WAN changes while a kill switch is in place because doing so will reset all your iptables rules, leaving you exposed until they are reset. If you truly want to be safe, take the WAN down, disconnect your router/firewall... make your critical changes, test, test, test, reconnect and bring the WAN back up.

Yes and there might be other times when this happens, might want to check if this also can happen when ISP do they there daily reset.
I was happy snipping the GT-AX6000 for a good price and was looking forward to a new deep dive and setup with rpi pihole but it turned out in allot of frustration from this above problem to DNS leaking when trying to set up pihole behind the vpn.

Anyways, thanks for your work and scripts, just wish ASUS would do a better job.

 

[Dean.viens]

Hahaha you crack me up @SomeWhereOverTheRainBow! Thank you!

can this script be used with original firmware? i have GT-AX6000 and i seem to be having issues seperating devices from using the VPNor not unless i stay with the regular firmware. I tried Merlin for the kill switch but I couldn’t get the vpn director to work. I will try again just to be sure but yeah this could be also what i was looking for. all I really need is a kill switch so if this would work with regular firmware it would be better. My VPN fusion is doing most of the work i need.

 

[SomeWhereOverTheRainBow]

Hahaha you crack me up @SomeWhereOverTheRainBow! Thank you!

The new musical number!

 

[Dean.viens]

@Wrkdbf_Guy @SomeWhereOverTheRainBow ... all I get to hear is this endless "why can't we be like a normal family, with a normal internet connection, where it just WORKS all the time". No appreciation for the amount of country blacklisting, DoT, whole-home secure random VPN tunnels all over the country, kill switch blackouts, or all the ad/malware blocking that is going into all this... little do they know. But man, if that internet goes down, I'm definitely on the receiving end.

i just tried to install the script on original asus firmware. it installed and configured correctly but when I disconnected VPN my 4 clients I have on the list still have internet access. how can I fix it?