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.

 

[Viktor Jaep]

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.

So basically 192.168.1.9 is calling 192.168.1.20 for DNS resolution when the killswitch kicks on, and it (the PiHole) can get around the killswitch in order to make those resolutions... perhaps you should try testing things out by killing your entire network, PiHole included, to see if that does the trick?

 

[bibikalka]

So basically 192.168.1.9 is calling 192.168.1.20 for DNS resolution when the killswitch kicks on, and it (the PiHole) can get around the killswitch in order to make those resolutions... perhaps you should try testing things out by killing your entire network, PiHole included, to see if that does the trick?

It's identical to when the stock DNS on 192.168.1.1 does resolutions. A killswitched device can call the main router 192.168.1.1 for DNS, and you would see those too since obviously the router itself is not killswitched. It's just that a PiHole instance made the monitoring more accessible.

Now, I could killswitch the entire router, or better yet, just turn it off for good. That would really block any and all traffic! But I don't really see much point in doing that given that I do want to connect to the Internet from time to time!

 

[Viktor Jaep]

It's identical to when the stock DNS on 192.168.1.1 does resolutions. A killswitched device can call the main router 192.168.1.1 for DNS, and you would see those too since obviously the router itself is not killswitched. It's just that a PiHole instance made the monitoring more accessible.

Now, I could killswitch the entire router, or better yet, just turn it off for good. That would really block any and all traffic! But I don't really see much point in doing that given that I do want to connect to the Internet from time to time!

Definitely a conundrum. Not saying blocking off the router, but perhaps include the PiHole in the range?

 

[bibikalka]

Definitely a conundrum. Not saying blocking off the router, but perhaps include the PiHole in the range?

So I think it's been doing these brief DNS requests whenever VPN is down since the very beginning. So far I have no seen ill effects, even if the device knows the IP, it still cannot connect to it because of the killswitch.

One could possibly block port 53 access on the router to killswitched devices. Or I could add the rule in PiHole not to resolve anything for a given IP. This is more a solution for those who don't want any and all DNS requests leak.

 

[rung]

I'm kind of curious why this is an issue either way. I thought the purpose of the kill switch is to ensure none of the destinations the clients are connecting ever learn the wan ip address. In this case no matter where the DNS requests go, whether it's to the pihole or to the vpn dns, the destination still only sees the vpn ip (due to the killmon iptable rule).