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

[Viktor Jaep]

192.168.48.0/21 vs 192.168.50.0 - 192.168.55.255 is this possible to add and what of the 2 would be better?

The only one that would work is the "192.168.48.0/21" option. Unfortunately the range has to be within the same /24 subnet if you want to do it that way.

 

[bibikalka]

@Viktor Jaep

I was looking at my PiHole logs, and noticed that for a brief moment a computer that is always tunneled through VPN is shown as requesting DNS outside of the tunnel:

2026-02-15 18:34:55        A    9.rarbg.to    honda

...

2026-02-15 18:37:13        A    9.rarbg.me    honda

This happened while VPN was getting restarted by vpnmon:

Feb 15 2026 18:34:45 RT-AC86U-9988 VPNMON-R3[14774] - WARNING: VPN1 PING exceeds max allowed (250 ms)

Feb 15 2026 18:35:16 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN1 Connection Restarted [RND] - New Server: us-dv1.jumptoserver.com

Feb 15 2026 18:35:36 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN Director Routing Service Restarted

Feb 15 2026 18:35:41 RT-AC86U-9988 VPNMON-R3[14774] - INFO: A new update (v1.8.3) is available to download

Feb 15 2026 18:36:46 RT-AC86U-9988 VPNMON-R3[14774] - WARNING: VPN1 is in an error state and being reconnected

Feb 15 2026 18:37:13 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN1 Connection Restarted [RND] - New Server: us-mia.jumptoserver.com

Feb 15 2026 18:37:33 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN Director Routing Service Restarted

And in the full log I can correlate the timestamps to these events:

Feb 15 18:34:53 RT-AC86U-9988 rc_service: service 2438373:notify_rc stop_vpnclient1

Feb 15 18:34:53 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)

Feb 15 18:34:53 RT-AC86U-9988 ovpn-client1[2540]: event_wait : Interrupted system call (fd=-1,code=4)

'''
Feb 15 18:36:51 RT-AC86U-9988 openvpn-routing: Clearing routing table for VPN client 1
Feb 15 18:37:13 RT-AC86U-9988 rc_service: service 2444373:notify_rc start_vpnclient1
Feb 15 18:37:13 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: start vpnclient1)
Feb 15 18:37:13 RT-AC86U-9988 ovpn-client1[2444515]: WARNING: Compression for receiving enabled. Compression has been used in the past to break e
...

 

[Viktor Jaep]

@Viktor Jaep

I was looking at my PiHole logs, and noticed that for a brief moment a computer that is always tunneled through VPN is shown as requesting DNS outside of the tunnel:

2026-02-15 18:34:55        A    9.rarbg.to    honda

...

2026-02-15 18:37:13        A    9.rarbg.me    honda

This happened while VPN was getting restarted by vpnmon:

Feb 15 2026 18:34:45 RT-AC86U-9988 VPNMON-R3[14774] - WARNING: VPN1 PING exceeds max allowed (250 ms)

Feb 15 2026 18:35:16 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN1 Connection Restarted [RND] - New Server: us-dv1.jumptoserver.com

Feb 15 2026 18:35:36 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN Director Routing Service Restarted

Feb 15 2026 18:35:41 RT-AC86U-9988 VPNMON-R3[14774] - INFO: A new update (v1.8.3) is available to download

Feb 15 2026 18:36:46 RT-AC86U-9988 VPNMON-R3[14774] - WARNING: VPN1 is in an error state and being reconnected

Feb 15 2026 18:37:13 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN1 Connection Restarted [RND] - New Server: us-mia.jumptoserver.com

Feb 15 2026 18:37:33 RT-AC86U-9988 VPNMON-R3[14774] - INFO: VPN Director Routing Service Restarted

And in the full log I can correlate the timestamps to these events:

Feb 15 18:34:53 RT-AC86U-9988 rc_service: service 2438373:notify_rc stop_vpnclient1

Feb 15 18:34:53 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: stop vpnclient1)

Feb 15 18:34:53 RT-AC86U-9988 ovpn-client1[2540]: event_wait : Interrupted system call (fd=-1,code=4)

'''
Feb 15 18:36:51 RT-AC86U-9988 openvpn-routing: Clearing routing table for VPN client 1
Feb 15 18:37:13 RT-AC86U-9988 rc_service: service 2444373:notify_rc start_vpnclient1
Feb 15 18:37:13 RT-AC86U-9988 custom_script: Running /jffs/scripts/service-event (args: start vpnclient1)
Feb 15 18:37:13 RT-AC86U-9988 ovpn-client1[2444515]: WARNING: Compression for receiving enabled. Compression has been used in the past to break e
...

In that case, you may want to try to start using the built-in kill switch, instead of KILLMON. I'm not sure how it's possible to get around the rules in place, or if something else might be interfering that would cause this to be allowed.

 

[rung]

@bibikalka Do you mind posting the output of:

iptables -v -L FORWARD | grep KILLMON

and

iptables -v -L KILLMON

This could be a lan vs wan issue.

 

[bibikalka]

@bibikalka Do you mind posting the output of:

iptables -v -L FORWARD | grep KILLMON

and

iptables -v -L KILLMON

This could be a lan vs wan issue.

admin@RT-AC86U-9988:/tmp/home/root# iptables -v -L FORWARD | grep KILLMON
45329 5311K KILLMON    all  --  br+    eth0    anywhere             anywhere
admin@RT-AC86U-9988:/tmp/home/root# iptables -v -L KILLMON
Chain KILLMON (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  any    any     anywhere             anywhere             source IP range 192.168.1.8-192.168.1.9 reject-with icmp-port-unreachable

@Viktor Jaep

Another thought is that I have global redirection in my DNS director to 192.168.1.20 - which is my on the router PiHole.

Could it manage to send DNS queries to PiHole whenever there is no VPN connected? Technically these are local queries, and local traffic is not blocked.

 

[Viktor Jaep]

admin@RT-AC86U-9988:/tmp/home/root# iptables -v -L FORWARD | grep KILLMON
45329 5311K KILLMON    all  --  br+    eth0    anywhere             anywhere
admin@RT-AC86U-9988:/tmp/home/root# iptables -v -L KILLMON
Chain KILLMON (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  any    any     anywhere             anywhere             source IP range 192.168.1.8-192.168.1.9 reject-with icmp-port-unreachable

@Viktor Jaep

Another thought is that I have global redirection in my DNS director to 192.168.1.20 - which is my on the router PiHole.

Could it manage to send DNS queries to PiHole whenever there is no VPN connected? Technically these are local queries, and local traffic is not blocked.

This setup is getting more interesting as time goes on. Or could it be that PiHole is responding but with cached results?

 

[bibikalka]

This setup is getting more interesting as time goes on. Or could it be that PiHole is responding but with cached results?

No, it definitely was not cached. I sorted DNS queries by the longest time, and that's how I noticed this odd behavior so PiHole was talking to a real site.

Unless one is actively looking - cannot see anything

So I don't think that computer was actually talking with anybody outside, only DNS queries went out through PiHole.

 

[Viktor Jaep]

No, it definitely was not cached. I sorted DNS queries by the longest time, and that's how I noticed this odd behavior so PiHole was talking to a real site.

Unless one is actively looking - cannot see anything

So I don't think that computer was actually talking with anybody outside, only DNS queries went out through PiHole.

Unless I'm seeing things incorrectly, isn't the killswitch only applied to "source IP range 192.168.1.8-192.168.1.9"... so that means the 192.168.1.20 PiHole is getting around the killswitch?

 

[bibikalka]

Unless I'm seeing things incorrectly, isn't the killswitch only applied to "source IP range 192.168.1.8-192.168.1.9"... so that means the 192.168.1.20 PiHole is getting around the killswitch?

The device in question is 192.168.1.9. When there is a VPN connection, its DNS queries flow through the VPN tunnel. When there is no VPN connection it's DNS queries go back to the router (PiHole in my case).

Naturally, neither the router nor PiHole are killswitched!

It seems 192.168.1.9 needs to have it's LAN DNS queries disabled by killswitch. So then if there is no VPN connection - it's not asking for DNS through the non-VPN channel.