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

[salvo]

Gotcha... In that case, it may be better to continue using eibgrads script since it does handle those exclusions better. I frankly haven't been able to wrap my head around that - eibgrad is a wiz, and started with wanting to keep KILLMON as simple and straightforward as possible. I will be planning on being able to allow for more ranges or more single IPs in the future, and I'll see where I get on taking VPN director into consideration.

Thank you for the confirmation. It's clear and maybe someday ;-) but on the other hand my use case may be too rare so don't bother.

 

[bibikalka]

...

Tried KILLMON - it seems right after installing it, it does not actually launch itself. I did a bunch of configs, but that did not start it. Copy/pasted line from firewall script to have it going.

My use case is a single computer forced through VPN on occasions. So I assigned a static IP to it, renewed, then set it up in VPN director, and also in KILLMON as to have a real network lock.

The tricky part was to get this same computer from under VPN/KILLMON back to the regular WAN access. So I ended up slightly changing it's static IP, and renewing. With a new IP - the rules do not apply

 

[Viktor Jaep]

Tried KILLMON - it seems right after installing it, it does not actually launch itself. I did a bunch of configs, but that did not start it. Copy/pasted line from firewall script to have it going.

After installing it, you need to define what you want to enable the killswitch for. You can choose an IP range, or a single IP... paranoid mode basically covers everything, so no definition is necessary. Once you're done defining the IP/Range, you enable the option you want. Once you do enable the particular mode you've chosen, it writes the necessary values to your IP tables to enable the block, and only allow traffic to traverse your VPN tunnel.

My use case is a single computer forced through VPN on occasions. So I assigned a static IP to it, renewed, then set it up in VPN director, and also in KILLMON as to have a real network lock.

That's the way to go... this will only work for all traffic for this IP that traverses through your VPN tunnel. When that tunnel goes down, so does any inbound/outbound traffic for this IP. If you only do this on occasion, you will need to make sure you disable & reverse all kill switch rules.

The tricky part was to get this same computer from under VPN/KILLMON back to the regular WAN access. So I ended up slightly changing it's static IP, and renewing. With a new IP - the rules do not apply

If you are no longer needing to cover this IP with the killswitch, simply hit "rr". That disables and reverses all rules.

 

[bibikalka]

...
That's the way to go... this will only work for all traffic for this IP that traverses through your VPN tunnel. When that tunnel goes down, so does any inbound/outbound traffic for this IP. If you only do this on occasion, you will need to make sure you disable & reverse all kill switch rules.

If you are no longer needing to cover this IP with the killswitch, simply hit "rr". That disables and reverses all rules.

Yes, your script helps to make this into the proper "classical" kill-switch or network lock that every VPN client out there has as an option. Thanks for putting this together!

For logistical purposes, I wanted to be able to add/remove a device from the VPN/kill-switch path at will using just the router web page, without ssh. I can change the static IP number from the interface, so that makes this approach preferable. The rules can persist and be active till next time I need them!

 

[Viktor Jaep]

Yes, your script helps to make this into the proper "classical" kill-switch or network lock that every VPN client out there has as an option. Thanks for putting this together!

For logistical purposes, I wanted to be able to add/remove a device from the VPN/kill-switch path at will using just the router web page, without ssh. I can change the static IP number from the interface, so that makes this approach preferable. The rules can persist and be active till next time I need them!

Great way to make life easiest for yourself, @bibikalka! Nice job!

 

[Goobi]

I got a couple of quick questions relating this script:

1. If using this, do you need to also use the kill switch option that is shown in the GUI for each VPN client?
2. When the VPN goes down, will all the traffic be blocked or just the client traffic that is associated with the VPN? I have about 12 or so clients that are not sequential in their IP assignments, and just want to know if this kill switch impacts all traffic or just the traffic that is assigned to the VPNs?

Thanks in advance!

 

[Viktor Jaep]

I got a couple of quick questions relating this script:

1. If using this, do you need to also use the kill switch option that is shown in the GUI for each VPN client?

Nope, you actually want to leave it off... but I don't think it can hurt leaving it on? I've personally always left it off... give it a try and see! LOL From what I know, this GUI killswitch that's present for each client only works if there's a fatal error that causes the VPN tunnel to go down... but like a dropped connection wouldn't enable that killswitch... which is kinda why KILLMON was created -- ie. to cover all the other bases.

2. When the VPN goes down, will all the traffic be blocked or just the client traffic that is associated with the VPN? I have about 12 or so clients that are not sequential in their IP assignments, and just want to know if this kill switch impacts all traffic or just the traffic that is assigned to the VPNs?

When the VPN goes down, then all the IPs that you have identified as being affected (whether it's a single IP, an IP range, or everything) will be blocked from getting out over the WAN. So when you configure KILLMON, you want to make sure you pick a range that these 12 clients fit in... then these will all be blocked from getting out over the WAN when VPN goes down.

 

[Goobi]

Nope, you actually want to leave it off... but I don't think it can hurt leaving it on? I've personally always left it off... give it a try and see! LOL From what I know, this GUI killswitch that's present for each client only works if there's a fatal error that causes the VPN tunnel to go down... but like a dropped connection wouldn't enable that killswitch... which is kinda why KILLMON was created -- ie. to cover all the other bases.

When the VPN goes down, then all the IPs that you have identified as being affected (whether it's a single IP, an IP range, or everything) will be blocked from getting out over the WAN. So when you configure KILLMON, you want to make sure you pick a range that these 12 clients fit in... then these will all be blocked from getting out over the WAN when VPN goes down.

Thank you for the insights Victor! Just curious, are there any plans to allow for multiple ranges or multiple single IPs into the configuration? Applicable to use cases that don't have IPs that need this functionality but don't fall into a sequential range?

 

[Viktor Jaep]

Thank you for the insights Victor! Just curious, are there any plans to allow for multiple ranges or multiple single IPs into the configuration? Applicable to use cases that don't have IPs that need this functionality but don't fall into a sequential range?

Definitely on the drawing board... I tried to start off easy dealing with the simplest use cases, but will look at seeing what it takes to increase complexity in allowing numerous non-sequential IPs, or multiple ranges.

 

[Goobi]

Definitely on the drawing board... I tried to start off easy dealing with the simplest use cases, but will look at seeing what it takes to increase complexity in allowing numerous non-sequential IPs, or multiple ranges.

Sounds good. Thanks!

 

[Caesar the Dictator]

Do you think people who use the Wireguard client should also use KILLMON? It says here that the protocol does not need a kill switch due to its nature.

I've seen a syntax added to the configuration file elsewhere, should we add this syntax just in case or should we just use KILLMON?

 

[Viktor Jaep]

Do you think people who use the Wireguard client should also use KILLMON? It says here that the protocol does not need a kill switch due to its nature.

I've seen a syntax added to the configuration file elsewhere, should we add this syntax just in case or should we just use KILLMON?

I guess theoretically it may work? In the case your wireguard goes down, then traffic wouldn't be able to get out over the WAN. The killswitch simply prevents any traffic coming across br0 to get to WAN0/WAN1... and so the only way out to the internet is a valid VPN tunnel, or wireguard connection in your case? I have never experimented with this, and couldn't tell you, but if you want to try it out and report back, please let me know!

 

[Caesar the Dictator]

I guess theoretically it may work? In the case your wireguard goes down, then traffic wouldn't be able to get out over the WAN. The killswitch simply prevents any traffic coming across br0 to get to WAN0/WAN1... and so the only way out to the internet is a valid VPN tunnel, or wireguard connection in your case? I have never experimented with this, and couldn't tell you, but if you want to try it out and report back, please let me know!

Honestly, if I had the possibility to set up a WireGuard server of my own, I would like to test KILLMON. As a regular user, I will follow your and RMerlin's explanation and keep using the default WG client configuration. Or I will add that syntax to the configuration.

 

[Viktor Jaep]

Honestly, if I had the possibility to set up a WireGuard server of my own, I would like to test KILLMON. As a regular user, I will follow your and RMerlin's explanation and keep using the default WG client configuration. Or I will add that syntax to the configuration.

In lieu of adding that syntax to the configuration, I would see how killmon behaves in a default WireGuard client scenario. I think it would work! I wasn't even thinking how it would all look if you set up your own WireGuard server on your end.

 

[HarryMuscle]

Honestly, if I had the possibility to set up a WireGuard server of my own, I would like to test KILLMON. As a regular user, I will follow your and RMerlin's explanation and keep using the default WG client configuration. Or I will add that syntax to the configuration.

Unfortunately the WireGuard implementation in the 388.x firmware doesn't support the PostUp and PreDown options in the configuration.

 

[HarryMuscle]

I'm trying to get a better understanding of what the script actually does (ie: the end result). If I'm using the Ranged Mode, am I correct in my understanding that it only adds these three iptables rules (when only using IP4 and assuming your range is 192.168.50.99 to 192.168.50.111):

-N KILLMON
-A FORWARD -i br+ -o eth0 -j KILLMON
-A KILLMON -m iprange --src-range 192.168.50.99-192.168.50.111 -j REJECT --reject-with icmp-port-unreachable

Obviously a lot goes into figuring out all the details involved in creating those three rules, but I just wanna confirm that my understanding is correct that those three rules are the end result of this script when using the Ranged Mode.

Thanks,
Harry

 

[Viktor Jaep]

I'm trying to get a better understanding of what the script actually does (ie: the end result). If I'm using the Ranged Mode, am I correct in my understanding that it only adds these three iptables rules (when only using IP4 and assuming your range is 192.168.50.99 to 192.168.50.111):

-N KILLMON
-A FORWARD -i br+ -o eth0 -j KILLMON
-A KILLMON -m iprange --src-range 192.168.50.99-192.168.50.111 -j REJECT --reject-with icmp-port-unreachable

Obviously a lot goes into figuring out all the details involved in creating those three rules, but I just wanna confirm that my understanding is correct that those three rules are the end result of this script when using the Ranged Mode.

Thanks,
Harry

Pretty close...

iptables -N KILLMON
iptables -I FORWARD -i br+ -o eth0 -j KILLMON
iptables -A KILLMON -m iprange --src-range 192.168.50.99-192.168.50.111 -j REJECT

 

[HarryMuscle]

Just wanted to say that I've tried this script with the 388.x firmware WireGuard VPN and everything seems to be working just fine.

 

[Viktor Jaep]

Just wanted to say that I've tried this script with the 388.x firmware WireGuard VPN and everything seems to be working just fine.

Thanks for validating that @HarryMuscle! I was hoping things would work similarly even with Wireguard.

 

[Caesar the Dictator]

That's good! Then Mr. @Viktor Jaep's script is available to all WireGuard users.