Doesn't seem to work (OS X): blocks everything immediately
JayBrown opened this issue · 7 comments
Just tested it, but it doesn't seem to work: I connected to a VPN, then ran sudo killswitch -e with output:
Interface MAC address IP
en1 xx:xx:xx:xx:xx:xx 192.168.xxx.xx
utun1 10.10.xxx.xxx
Public IP address: 77.xxx.xxx.xxx
PEER IP address: 5.xxx.xxx.xxx
# --------------------------------------------------------------
# Loading rules
# --------------------------------------------------------------
No ALTQ support in kernel
ALTQ related functions disabled
block drop all
pass inet proto udp from any to 224.0.0.0/4 keep state
pass inet proto udp from 224.0.0.0/4 to any keep state
pass inet from any to 255.255.255.255 flags S/SA keep state
pass inet from 255.255.255.255 to any flags S/SA keep state
pass on en1 proto tcp from any port 67:68 to any port 67:68 flags S/SA keep state
pass on en1 proto udp from any port 67:68 to any port 67:68 keep state
pass on en1 inet proto tcp from any to 5.xxx.xxx.xxx flags S/SA keep state
pass on en1 inet proto udp from any to 5.xxx.xxx.xxx keep state
pass on utun1 all flags S/SA keep state
But then killswitch just blocks any connection, so I have to run sudo killswitch -d. Output:
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble
anchor "com.apple/*" all
So it seems that killswitch is not waiting for the VPN to disconnect, but blocks any connection right away. It's nice to see that blocking works, but I'd rather have this happen only when the VPN is disconnected. ;)
So my question is, whether this is a bug, or whether I'm doing something wrong?
Hi @JayBrown please try the option -leak what this will do is to enable ping and DNS requests outside the VPN.
If the option -leak worked for you maybe you could then use cloudflare DNS (1.1.1.1) https://blog.cloudflare.com/announcing-1111/ (so that you don't have to "worry" much about privacy)
The default behavior is just to block absolutely all traffic that doesn't go through the VPN, exept for multicast udp (224.0.0.0/4 used to keep your DHCP up )
Note also that the killswitch has no relation or influence on your VPN client, and this is on purpose, the idea is to secure your traffic directly at OS level so that if your VPN client crashes or you lost connection, the killswitch will not be disabled automatically, in this cases if your VPN goes down, and you where using some P2P app, you will either have to stop your applications before disabling the killswitch to prevent a leak and later once you are sure nothing is up and running that may expose your trafic you then could disable killswitch -d, and then try to reconnect your VPN again, once the VPN is up you could then enable agin the killswitch -e or just restart your equipment.
Could be that you don't need to disable the killswith to re-connect to your VPN provider this will ocure if the IP you connect to is the same was assigned, just give a try.
I tried it with the -leak option, same result, i.e. it blocks everything. I have a little ping script in my menu bar, and even that gets blocked, with or without the -leak option. I'm using 1.1.1.1 as my primary DNS in my VPN settings (Viscosity with OpenVPN), and my setup is to send everything via VPN including DNS, ping, dig etc. (except stuff my system is doing on the local subnet, of course).
But maybe I'm understanding killswitch wrong? In my view you first connect to your VPN, then enable killswitch, preferably without the -leak option, and then only the stuff going through the VPN is allowed by pf: block all. So when the VPN breaks down, is disconnected etc., nothing can connect until you either disable killswitch again, or reconnect to the VPN.
But in my case killswitch blocks everything, even the stuff going through the VPN, which in my setup is everything incl. ping& DNS, including the VPN connection itself.
The killswitch should detect automatically your vpn peer ip check this https://vpn-kill-switch.com/post/pf/
And give a try passing the airport ip:
killswitch -ip x.x.x.x -e
Yes, it does: killswitch always detects and prints the correct VPN peer IP (see stdout in the OP above). So that's not the problem, I assume. But I tried it anyway with the -ip option, i.e. sudo killswitch -ip 5.35.xxx.xxx -e, the IP being my VPN peer IP, but it's the same result: everything is blocked, and I need to run sudo killswitch -d again.
After enabling the killswitch with the option leak ping works? Try before/after
@JayBrown by any chance you don't have 2 vpns up and runing?
I am asking this because from your original post I see utun1, so probably utun0 is already used.
Give a try go killswitch -p option will print the firewall rules that will be used, you should see something like:
# --------------------------------------------------------------
# Sat, 07 Apr 2018 15:59:49 +0200
# sudo pfctl -Fa -f /tmp/killswitch.pf.conf -e
# --------------------------------------------------------------
int_en1 = "en1"
vpn_ipsec0 = "ipsec0"
vpn_ip = "182.154.175.142"
set block-policy drop
set ruleset-optimization basic
set skip on lo0
block all
pass from any to 255.255.255.255 keep state
pass from 255.255.255.255 to any keep state
pass proto udp from any to 224.0.0.0/4 keep state
pass proto udp from 224.0.0.0/4 to any keep state
pass on $int_en1 proto {tcp,udp} from any port 67:68 to any port 67:68 keep state
pass on $int_en1 proto {tcp, udp} from any to $vpn_ip
pass on $vpn_ipsec0 all
Try to modify it and adjust to use your vpn interfaces, probably something like:
vpn_utun0 = "utun0"
Then you could edit/customize the file /tmp/killswitch.pf.conf by using:
sudo pfctl -Fa -f /tmp/killswitch.pf.conf -e
To disable or load the defaults you can do:
sudo pfctl -Fa -f /etc/pf.conf